Java: Integer jest równy vs. ==

Question

Od wersji Java 1.5 w wielu sytuacjach można w dużym stopniu wymieniać Integer z int.

Jednak znalazłem potencjalną wadę w moim kodzie, która mnie trochę zaskoczyła.

Poniższy kod:

Integer cdiCt = ...; 
Integer cdsCt = ...; 
... 
if (cdiCt != null && cdsCt != null && cdiCt != cdsCt) 
    mismatch = true; 

wydawało się być nieprawidłowo ustalone niedopasowanie, gdy wartości były równe, chociaż nie mogę określić, w jakich okolicznościach. Ustawiłem punkt przerwania w Eclipse i zauważyłem, że wartości Integer są zarówno 137, jak i sprawdziłem wyrażenie boolowskie i powiedziałem, że jest to fałsz, ale kiedy przekroczyłem to ustawienie było niezgodne z ustawieniem true.

Zmiana warunkowy do:

if (cdiCt != null && cdsCt != null && !cdiCt.equals(cdsCt)) 

rozwiązaniu problemu.

Czy ktoś może rzucić trochę światła na to, dlaczego tak się stało? Do tej pory widziałem tylko zachowanie na moim localhost na moim własnym komputerze. W tym konkretnym przypadku kod zakończył pomyślnie około 20 porównań, ale zakończył się niepowodzeniem. Problem był powtarzalny.

Jeśli jest to powszechny problem, powinien powodować błędy w innych naszych środowiskach (dev i test), ale jak dotąd nikt nie zgłosił problemu po setkach testów wykonujących ten fragment kodu.

Czy nadal nie jest uzasadnione korzystanie z == do porównywania dwóch wartości Integer?

Oprócz wszystkich dokładnych odpowiedzi poniżej, poniższy link Stackoverflow ma sporo dodatkowych informacji. To rzeczywiście byłby odpowiedział na moje pierwotne pytanie, ale ponieważ nie wspominając autoboxing na moje pytanie, to nie pojawi się w wybranych sugestii:

Why can't the compiler/JVM just make autoboxing “just work”?

Answer 1

JVM buforuje wartości całkowite. == działa tylko dla liczb pomiędzy -128 i 127 http://www.owasp.org/index.php/Java_gotchas#Immutable_Objects_.2F_Wrapper_Class_Caching

Answer 2

Problem jest to, że dwa obiekty są Integer tylko to, obiekty. Nie pasują, ponieważ porównujesz dwa odniesienia do obiektów, a nie wartości wewnątrz. Oczywiście .equals jest przesłonięte, aby zapewnić porównanie wartości w przeciwieństwie do porównania odniesień do obiektu.

Answer 3

Integer odnosi się do odniesienia, to znaczy porównując odniesienia, które porównujesz, jeśli wskazują na ten sam obiekt, a nie wartość. Stąd pojawia się problem. Powodem, dla którego działa tak dobrze ze zwykłymi typami int jest to, że rozpakowuje wartość zawartą w Integer.

Czy mogę dodać, że jeśli robisz to, co robisz, dlaczego na początek ma się wypowiedzieć if?

mismatch = (cdiCt != null && cdsCt != null && !cdiCt.equals(cdsCt)); 

Answer 4

Nie można porównać dwa Integer z prostym == że jesteśmy przedmiotów więc większość odniesień czasowych nie będą takie same.

Istnieje sztuczka, z Integer między -128 a 127, odniesienia będą takie same, jak autoboxing używa Integer.valueOf(), który buforuje małe liczby całkowite.

Jeśli wartość p jest zapakowane jest prawdziwe, fałszywe, bajt, char w zakres \ u0000 do \ u007f lub int lub krótki numer pomiędzy -128 i 127, pozwól R1 i R2 być wyniki dowolnych dwóch konwersji bokserskich na s. Zawsze jest tak, że r1 == r2.

---

Zasoby:

• JLS - Boxing

na ten sam temat:

• autoboxing vs manual boxing java

Answer 5

"==" zawsze porównuj lokalizację pamięci lub odniesienia do obiektu wartości. metoda równości zawsze porównuj wartości. Ale równa się również pośrednio używa operatora "==" do porównywania wartości.

Integer używa pamięci podręcznej Integer do przechowywania wartości od -128 do +127. Jeśli do sprawdzenia wartości od -128 do 127 używany jest operator ==, to zwraca on wartość true. dla wartości innych niż te zwraca wartość false.

Skierować link jakiegoś dodatkowego informacji