Bizarre Entier de boxe en Java

public class Scratch
{
   public static void main(String[] args)
    {
        Integer a = 1000, b = 1000;  //1
        System.out.println(a == b);

        Integer c = 100, d = 100;  //2
        System.out.println(c == d);
   }
}

De sortie:

false
true

Yep la première sortie est produit pour la comparaison de référence; 'a' et 'b', ce sont deux différents de référence. Au point 1, en fait deux références sont créés, qui est la même -

Integer a = new Integer(1000);
Integer b = new Integer(1000);

La deuxième sortie est produite parce que le JVM essaie d'économiser de la mémoire, lorsque le Integer s'inscrit dans une fourchette (de -128 à 127). Au point 2 pas de la nouvelle référence de type Entier est créé pour "d". Au lieu de créer un nouvel objet pour le type Entier de référence de la variable "d", il ne attribué précédemment créé objet référencé par un "c". Tous ces éléments sont fait par JVM.

La mémoire de ces règles ne sont pas seulement pour Entier. pour mémoire sauver, les deux instances de l'wrapper suivant les objets (tout en créé par le biais de la boxe), sera toujours == d'où leurs valeurs primitives sont les mêmes -

• Boolean
• Octet
• Caractère de \u0000 à \u007f (7f est de 127 en décimal)
• Court et Entier de -128 à 127

Oui, il ya une étrange l'autoboxing règle qui entre en jeu lorsque les valeurs sont dans une certaine plage. Lorsque vous affectez une constante à une variable Objet, rien dans la définition du langage dit d'un nouvel objet doit être créé. Il peut réutiliser un objet existant à partir du cache.

En fait, la JVM conserve un cache de petits nombres à cette fin, ainsi que des valeurs telles que la valeur de type Boolean.VRAI et Boolean.FAUX.

Ma conjecture est que Java conserve un cache de petits nombres qui sont déjà "en boîte", parce qu'ils sont très communes et il permet d'économiser un diable de beaucoup de temps pour ré-utiliser un objet existant que d'en créer un nouveau.

Affectation directe d'un int littérale d'un nombre Entier de référence est un exemple de l'auto-boxing, où la valeur littérale de l'objet de la conversion de code est géré par le compilateur.

Donc pendant la phase de compilation du compilateur convertit Integer a = 1000, b = 1000; à Integer a = Integer.valueOf(1000), b = Integer.valueOf(1000);.

De sorte qu'il est Integer.valueOf() méthode qui, en fait, nous donne l'entier des objets, et si l'on regarde le code source de Integer.valueOf() méthode, nous pouvons voir clairement la méthode caches entier des objets dans la gamme de -128 à 127 (inclus).

/**
 *
 * This method will always cache values in the range -128 to 127,
 * inclusive, and may cache other values outside of this range.
 *
 * @param  i an {@code int} value.
 * @return an {@code Integer} instance representing {@code i}.
 * @since  1.5
 */
 public static Integer valueOf(int i) {
     if (i >= IntegerCache.low && i <= IntegerCache.high)
         return IntegerCache.cache[i + (-IntegerCache.low)];
     return new Integer(i);
 }

Donc au lieu de créer et de retour de new integer objets, Integer.valueOf() la méthode retourne un nombre Entier d'objets provenant de l'interne IntegerCache si le passé int littérale est supérieure à -128 et moins de 127.

Java caches entier ces objets, car cette plage d'entiers obtient beaucoup utilisé au jour le jour de la programmation qui, indirectement, permet d'économiser de la mémoire.

Le cache est initialisé sur la première utilisation, lorsque la classe est chargée dans la mémoire à cause de la statique bloc. La portée maximale de la mémoire cache peut être contrôlé par la -XX:AutoBoxCacheMax option JVM.

Cette mise en cache de comportement n'est pas applicable pour l'Entier des objets, de la même Entier.IntegerCache nous avons également ByteCache, ShortCache, LongCache, CharacterCache pour Byte, Short, Long, Character respectivement.

Vous pouvez en lire plus sur mon article Java Entier De Cache - Pourquoi Entier.valueOf(127) == Integer.valueOf(127) Est Vrai.

Si nous vérifions le code source de Integer obeject, nous allons trouver la source de valueOf méthode comme ceci:

public static Integer valueOf(int i) {
    if (i >= IntegerCache.low && i <= IntegerCache.high)
        return IntegerCache.cache[i + (-IntegerCache.low)];
    return new Integer(i);
}

qui peut expliquer pourquoi Integer des objets qui dans la plage allant de -128 (Integer.low) à 127 (Integer.high), ce sont les objets référencés au cours de la l'autoboxing. Et nous pouvons voir qu'il ya une classe IntegerCache prend soin de la Integer cache de tableau, qui est une private static intérieur de la classe de Integer classe.

Il y a un autre exemple intéressant peut nous aider à comprendre cette situation bizarre:

public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException {

      Class cache = Integer.class.getDeclaredClasses()[0]; 
      Field myCache = cache.getDeclaredField("cache"); 
      myCache.setAccessible(true);

      Integer[] newCache = (Integer[]) myCache.get(cache); 
      newCache[132] = newCache[133]; 

      Integer a = 2;
      Integer b = a + a;
      System.out.printf("%d + %d = %d", a, a, b); //The output is: 2 + 2 = 5    

}