Java: Целое число равно ==

Question

С точки зрения Java 1.5 вы можете в значительной степени обменивать Integer с int во многих ситуациях.

Однако, я нашел потенциальный дефект в моем коде, который немного меня удивил.

Следующий код:

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

, как представляется, неправильно установив несоответствие, когда значения были равны, хотя я не могу определить, при каких обстоятельствах. Я установил точку останова в Eclipse и увидел, что значения Integer были равны 137, и я проверил логическое выражение, и он сказал, что он был ложным, но когда я перешагнул его, он установил несоответствие true.

Изменение условной к:

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

зафиксировал проблему.

Может ли кто-нибудь пролить свет на то, почему это произошло? До сих пор я видел поведение на своем локальном хосте на своем собственном компьютере. В этом конкретном случае код успешно завершил около 20 сравнений, но не смог выполнить 2. Проблема была последовательно воспроизводимой.

Если это распространенная проблема, она должна вызывать ошибки в наших других средах (dev и test), но до сих пор никто не сообщал о проблеме после того, как сотни тестов выполняли этот фрагмент кода.

Нельзя ли использовать == для сравнения двух значений Integer?

В дополнение ко всем тонким ответам ниже, следующая ссылка stackoverflow содержит довольно немного дополнительной информации. Это на самом деле был бы ответил на мой оригинальный вопрос, а потому, что я не упомянул Autoboxing в моем вопросе, он не появлялся в выбранных предложений:

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

Answer 1

JVM - это кеширование Целочисленных значений. == работает только для чисел между -128 и 127 http://www.owasp.org/index.php/Java_gotchas#Immutable_Objects_.2F_Wrapper_Class_Caching

Answer 2

Вопрос заключается в том, что ваши два объекта Integer являются просто это, объекты. Они не совпадают, потому что вы сравниваете свои две ссылки на объекты, а не значения внутри. Очевидно, что .equals переопределяется, чтобы обеспечить сравнение значений, а не сравнение ссылок на объекты.

Answer 3

Integer ссылается на ссылку, то есть при сравнении ссылок, которые вы сравниваете, если они указывают на один и тот же объект, а не на значение. Следовательно, проблема, которую вы видите. Причина, по которой он так хорошо работает с обычными типами int, заключается в том, что он освобождает значение, содержащее Integer.

Могу ли я добавить, что если вы делаете то, что вы делаете, для чего следует утверждение if?

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

Answer 4

Вы не можете сравнить два Integer с простым == они объекты так, большинство ссылок времени не будет то же самое.

Существует трюк с Integer между -128 и 127, ссылки будут такими же, как и использование autoboxing, использует Integer.valueOf(), который кэширует маленькие целые числа.

Если значение р будучи в штучной упаковке является истинным, ложным, байты, полукокс в диапазоне \ u0000 к \ u007f, или INT или короткое число в диапазоне от -128 до 127, то пусть r1 и r2 быть результаты любых двух бокс-конверсий на стр. Всегда бывает, что r1 == r2.

---

Ресурсы:

• JLS - Boxing

На эту же тему:

• autoboxing vs manual boxing java

Answer 5

«==» всегда сравнивает расположение памяти или ссылки на объекты значений. метод equals всегда сравнивает значения. Но equals также косвенно использует оператор «==» для сравнения значений.

Integer использует кеш Integer для хранения значений от -128 до +127. Если оператор == используется для проверки любых значений от -128 до 127, тогда он возвращает true. иначе, чем эти значения, он возвращает false.

Направить link для некоторой дополнительной информации