comportamiento incoherente en == de java

Question

Considere este código:

class test {
   public static void main(String[] args) {
      test inst_test = new test();
      int i1 = 2000;
      int i2 = 2000;
      int i3 = 2;
      int i4 = 2;
      Integer Ithree = new Integer(2); // 1
      Integer Ifour = new Integer(2); // 2
      System.out.println( Ithree == Ifour );
      inst_test.method( i3 , i4 );
      inst_test.method( i1 , i2 );
   }
   public void method( Integer i , Integer eye ) {
      System.out.println(i == eye );
   }
}

Imprime:

false
true
false

entiendo la primera false, el operador == sólo comprueba si dos referencias están trabajando en el mismo objeto, que en este caso no lo son.

La siguiente true y false me tienen rascándome la cabeza. ¿Por qué Java considerar i3 y i4 iguales pero i1 y i2 diferente? Ambos han sido envueltos en entero, no debe ambos a evaluar falsa? ¿Hay una razón práctica para esta inconsistencia?

Answer 1

Autoboxing de primitivas en objetos (como se usa en sus llamadas a method utiliza una caché de valores pequeños. Desde el sección Especificación del lenguaje Java 5.1.7 :

  

Si el valor p de ser en caja es cierto,   falso, un byte, un char en el rango   \ U0000 a \ u007f, o un int o corto   número entre -128 y 127, y luego dejar   R1 y R2 sean los resultados de cualquiera de dos   conversiones de boxeo de p. Es siempre   el caso de que r1 r2 ==.

La parte de discusión de la especificación inmediatamente después de que es interesante también. Cabe destacar que una JVM puede almacenar en caché más los valores si se quiere - no se puede estar seguro de los resultados de hacer:

Integer i1 = 129;
Integer i2 = 129;
boolean b = (i1 == i2);

Answer 2

Cuando autoboxing, Números enteros entre -128 y 127 se almacenan en caché, y se devuelve el mismo objeto envoltura. Lo mismo con valores booleanos y valores CHAR entre \ u0000 y \ u007F

Esto es lo que se obtiene la mayor parte del tiempo, sin embargo, depende de la implementación de la JVM.

Answer 3

Esto es porque el boxeo hace enteros por debajo de un valor determinado (128, creo) se refieren a un objeto preconstruidos, y valores superiores a nuevos objetos.

Answer 4

usos autoboxing Integer.valueOf (i) , no new Integer (i), para la construcción de un objeto de clase Integer.

Como los otros han dicho, valueOf () utiliza un caché, sobre todo para la eficiencia del espacio.

No utilizar == sobre los tipos de referencia, es casi siempre un error.

Answer 5

Entero clase contiene un caché de algunos casos de uso frecuente. El rango de valores varía generalmente de JVM para JVM (a veces también es configurable) pero en general el código en cuestión es algo como:

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

(código de Sun JDK 1.6)

esto es como cadena de internar, ya que tanto ahorra memoria y permite la igualdad de prueba utilizando una referencia (por ejemplo, == en lugar de es igual a )

Answer 6

Me imagino que la envoltura trata de minimizar el número de objetos enteros y crea un único objeto que representa 2 también ahorrar memoria.

Sólo recuerde que nunca use == sobre objetos nunca se sabe lo que pasa.

Answer 7

Autoboxing usar algún mecanismo de almacenamiento en caché. Por lo general, no debe confiar en ==, utilice siempre equals para comprobar la igualdad.