Java pregunta sobre autoboxing y la igualdad de objeto/identidad

Question

public class Main { 
    /** 
     * @param args the command line arguments */ 
    public static void main(String[] args) { 
     // TODO code application logic here 
     int a1 = 1000, a2 = 1000; 
     System.out.println(a1==a2);//=>true 
     Integer b1 = 1000, b2 = 1000; 
     System.out.println(b1 == b2);//=>false 
     Integer c1 = 100, c2 = 100; 
     System.out.println(c1 == c2);//=>true 
    } 

} 

¿Por qué es falso y b1 == b2c1 == c2 verdad?

Answer 1

La respuesta que desea es here

Answer 2

Puede encontrar la respuesta aquí:

Strangest language feature en el sexto respuesta.

Edit: lo siento, no exatly la respuesta. El punto es que == compara referencias, no valores cuando lo usa con Entero. Pero con int "==" significa igual.

Answer 3

Lea this.

Java utiliza una piscinapara Integer s en el rango de -128 a 127.

Eso significa que si se crea un Integer con Integer i = 42; y su valor está comprendido entre -128 y 128, ningún nuevo objeto se crea pero se devuelve el correspondiente del grupo. Es por eso que c1 es de hecho idéntico a c2.

() Supongo que sabe que == compara referencias, no valores, cuando se aplica a los objetos).

Answer 4

Porque Integer es para unos pocos números bajos como la enumeración por lo que siempre hay la misma instancia. Pero los números más altos crean nuevas instancias de Integer y el operador == compara sus referencias

Answer 5

Las respuestas correctas ya han sido dadas. Pero solo para agregar mis dos centavos:

Integer b1 = 1000, b2 = 1000; 

Este es un código horrible. Los objetos se deben inicializar como objetos a través de constructores o métodos de fábrica. P.ej.

// let java decide if a new object must be created or one is taken from the pool 
Integer b1 = Integer.valueOf(1000); 

o

// always use a new object 
Integer b2 = new Integer(1000); 

Este código

Integer b1 = 1000, b2 = 1000; 

por el contrario, implica que entero era una primitiva, que no lo es. En realidad lo que está viendo es un atajo para

Integer b1 = Integer.valueOf(1000), b2 = Integer.valueOf(1000); 

e Integer piscinas sólo para objetos de -127 y 127, por lo que creará dos nuevos objetos en este caso. Entonces, aunque 1000 = 1000, b1! = B2. Esta es la razón principal por la que odio el auto-boxeo.

Answer 6

public static Integer valueOf(int i) { 
     final int offset = 128; 
     if (i >= -128 && i <= 127) { // must cache 
      return IntegerCache.cache[i + offset]; 
     } 
     return new Integer(i); 
    } 

¡Debido a esto usted es cierto en un caso y falso en el otro!

Answer 7

Si autounboxing había trabajado también cuando se hace la comprobación de igualdad con el operador '==' se podría escribir:

Long notNullSafeLong1 = new Long(11L) 
    Long notNullSafeLong2 = new Long(22L) 
    if (notNullSafeLong1 == notNullSafeLong2) { 
     do suff 

Para ello sería necesario implementar un reemplazo para == == nula de manera que someLong es falso y lo caso especial nulo == nulo es verdadero. En lugar de ello tenemos que utilizar igual y test() para nula

Long notNullSafeLong1 = new Long(11L) 
    Long notNullSafeLong2 = new Long(22L) 
    if ((notNullSafeLong1 == null && notNullSafeLong2 == null) || 
     (notNullSafeLong1 != null && notNullSafeLong2 != null & 
     notNullSafeLong1.equals(notNullSafeLong2)) { 
     do suff  

Esto es un poco más detallado que el primer ejemplo - si autounboxing había trabajado para el operador '=='.