Java: liczba całkowita równa się vs. ==

Począwszy od Javy 1.5, można Integerz niej korzystać intw wielu sytuacjach.

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

Poniższy kod:

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

wydawało się, że ustawienie niezgodności jest nieprawidłowe, gdy wartości były równe, chociaż nie mogę określić, w jakich okolicznościach. Ustawiłem punkt przerwania w Eclipse i zobaczyłem, że Integerwartości były równe 137, i sprawdziłem wyrażenie logiczne i stwierdziłem, że jest fałszywe, ale kiedy go przekroczyłem, ustawiało niezgodność na true.

Zmiana warunku na:

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

naprawiono problem.

Czy ktoś może rzucić trochę światła na to, dlaczego tak się stało? Jak dotąd widziałem zachowanie tylko na moim hoście lokalnym na moim własnym komputerze. W tym konkretnym przypadku kod z powodzeniem pokonał około 20 porównań, ale zawiódł na 2. Problem był powtarzalny.

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

Czy nadal nie jest to zgodne z prawem == porównywanie dwóch Integerwartości?

Oprócz wszystkich dobrych odpowiedzi poniżej, poniższy link stackoverflow zawiera sporo dodatkowych informacji. Właściwie odpowiedziałby na moje pierwotne pytanie, ale ponieważ nie wspomniałem w moim pytaniu o autoboxingu, nie pojawił się w wybranych sugestiach:

Dlaczego kompilator / JVM nie może po prostu sprawić, by autoboxing „po prostu działał”?

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

Nie możesz porównać dwóch Integerz prostymi ==obiektami to, więc przez większość czasu odniesienia nie będą takie same.

Istnieje sztuczka, Integermiędzy -128 a 127 referencje będą takie same, jak w przypadku autoboxingu, Integer.valueOf()który buforuje małe liczby całkowite.

Jeśli wartość p w ramce to prawda, fałsz, bajt, znak w zakresie od \ u0000 do \ u007f lub liczba int lub krótka między -128 a 127, to niech r1 i r2 będą wynikiem dowolnych dwóch konwersji typu box z str. Zawsze jest tak, że r1 == r2.

Zasoby :

• JLS - Boks

Na ten sam temat:

• autoboxing vs boks ręczny java

Problem polega na tym, że twoje dwa obiekty typu Integer są po prostu obiektami. Nie pasują, ponieważ porównujesz dwa odwołania do obiektów, a nie wartości w nich zawarte. Oczywiście .equalsjest zastępowany, aby zapewnić porównanie wartości, a nie porównanie odniesień do obiektów.

Integerodnosi się do odniesienia, to znaczy podczas porównywania odniesień, które porównujesz, jeśli wskazują na ten sam obiekt, a nie wartość. Stąd problem, który widzisz. Powodem, dla którego działa tak dobrze z inttypami zwykłymi, jest to, że rozpakowuje wartość zawartą w Integer.

Mogę dodać, że jeśli robisz to, co robisz, to po co miałbyś ifzacząć od stwierdzenia?

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

„==” zawsze porównuje lokalizację pamięci lub odniesienia do obiektów wartości. equals zawsze porównuje wartości. Ale equals 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 operator == jest używany do sprawdzania wartości od -128 do 127, zwraca prawdę. dla innych niż te wartości zwraca false.

Skorzystaj z łącza, aby uzyskać dodatkowe informacje

Aby uzyskać poprawność użycia ==, możesz po prostu rozpakować jedną z porównywanych Integerwartości przed wykonaniem ==porównania, na przykład:

if ( firstInteger.intValue() == secondInteger ) {..

Drugi zostanie automatycznie rozpakowany (oczywiście musisz nullnajpierw sprawdzić ).

Oprócz tych wspaniałych odpowiedzi, dowiedziałem się, że:

NIGDY nie porównuj obiektów za pomocą ==, chyba że zamierzasz porównywać je przez odniesienia.