wrappers primitives de comparaison

Question

Possible en double:
Using == operator in Java to compare wrapper objects

version java 1.6.0_26

d'un livre pour la préparation de l'examen SCJP:

Afin d'économiser de la mémoire, deux instances des objets encapsuleurs [courts et entiers à partir de -128 et 127, et d'autres, mais sans importance] (créés par boixng), seront toujours == lorsque leur primitive les valeurs sont les mêmes.

Ce que je l'ai fait:

Si nous comparons deux entier -128 à 127 comme ceci:

1. Integer i1 = 10; 
2. Integer i2 = 10; 
3. System.out.println(i1 == i2); // true 

Mais pourquoi même nous donner « faux » ou peut-être ce n'est pas les mêmes choses:

4. Integer i3 = new Integer(10); 
5. Integer i4 = new Integer(10); 
6. System.out.println(i3 == i4); // false 

Mes questions:

1) Est-ce que sur la 1ère ligne de code on fait de la boxe implicite?

2) Pourquoi les 3e et 6e lignes de code nous donnent des résultats différents?

Answer 1

Est-ce que sur la 1ère ligne de code on fait de la boxe implicite?

Yes 

2) Pourquoi les 3e et 6e lignes de code nous donnent-elles des résultats différents?

Integer.valueOf(int) piscines toutes les valeurs de -128 à 127.

La raison est que les petites valeurs entières sont utilisées fréquemment et il n'y a pas de point dans la création d'un nouvel objet pour toutes ces valeurs chaque fois que nous avons besoin d'un objet. Par conséquent, ceux-ci sont créés comme objets "internés" et toutes les références à ces valeurs entières pointent vers la même adresse de mémoire.

extrait de code de Integer.java:

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

Au lieu de cela, lorsque vous appelez new Integer(10);, il fait tout un nouvel objet donc deux objets différents avec les mêmes valeurs entières pointera à la mémoire des adresses

Answer 2

Dans votre premier exemple, le compilateur utilise la boxe pour affecter les variables. Dans ce cas, i1/i2 sont des constantes (un peu comme des objets finaux statiques).

Dans le second exemple, vous créez deux instances d'un entier, elles ne sont donc jamais identiques.

Answer 3

1) Does on the 1st line of code we make implicit boxing? 

Oui. Son appelé Auto-Boxing

2) Why the 3rd and 6th lines of code give us different results? 

Le == vérifie effectivement si deux variables sont exactement les mêmes ayant une valeur. Notez qu'une variable primitive contient ce que vous voyez, mais une variable de référence contient l'adresse de l'objet qu'elle contient. Lorsque == est utilisé pour comparer une primitive à un wrapper, l'enveloppe sera déroulée et la comparaison sera primitive à primitive, et donc elle sera toujours vraie car il s'agit d'une comparaison de primitive et non de comparaison d'objet. Voilà pourquoi

System.out.println(i1 == i2); 

Sera vrai.

Mais dans la ligne 6.

System.out.println(i3 == i4); 

Vous comparez deux objets à moins que les objets ont la même référence, il ne sera pas vrai. Si tu utilises .est égale à la méthode que vous pouvez obtenir. Essayez

System.out.println(i3.equals(i4)); 

Answer 4

La ligne 6 est montrant faux parce qu'il compare pour voir si les références i3 et i4 pointent vers le même objet! Dans ce cas, ce n'est pas le cas. d'où le false.

L'Autoboxing et le UnBoxing apparaissent en image si des enveloppes et des primitives sont concernés. Ici, les deux i3 et i4 sont des objets wrapper, d'où il sera traité comme tout autre POJO

Autoboxing ne se produit que s'il y a des objets wrapper et un primitives impliqué,

par exemple

int primitive = 10; 
Integer wrapper = new Integer(10); 
System.out.println(primitive == wrapper); //true 

impressions True dans la comparaison ci-dessus == la valeur de la primitive est comparée à l'état de l'emballage.