Краткий ответ

Оператор == для двух ссылок типа Integer сравнивает не числовые значения, а идентичность объектов. Поэтому результат может зависеть от значения: небольшие числа часто представлены общими кэшированными объектами, а для остальных чисел объекты могут быть разными.

Для сравнения числовых значений используйте equals, если гарантировано отсутствие null, либо явно выполняйте распаковку с учетом возможного null. Полагаться на совпадение ссылок нельзя.

Исторический контекст

Примитивные типы Java не являются объектами, но многие API работают именно с объектными значениями: например, обобщенные коллекции не могут хранить int напрямую. Для этого существуют классы-обертки, включая Integer, а автоматическая упаковка и распаковка упрощают переход между примитивами и объектами.

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

Постановка проблемы

Разработчик видит одинаковые числовые значения и ожидает, что == даст true. Для объектов это неверно: два экземпляра могут содержать одинаковое значение, но иметь разные ссылки.

Особенно опасно то, что поведение иногда выглядит правильным для малых чисел из-за кэширования. После изменения входных данных на большее значение условие может начать работать иначе без каких-либо изменений в логике сравнения.

Подробное решение

Если оба операнда имеют тип Integer, == проверяет, указывают ли ссылки на один и тот же объект. При упаковке значения из обязательного диапазона малых целых чисел Java гарантирует определенное совместное использование экземпляров; для значений вне этого диапазона идентичность не гарантируется. Реализация может кэшировать и дополнительные значения, поэтому полагаться даже на наблюдаемое расширенное кэширование нельзя.

Метод equals сравнивает числовое значение двух объектов Integer, но вызов на null приведет к NullPointerException. Оператор == между Integer и примитивом, напротив, вызывает автоматическую распаковку; если ссылка равна null, исключение возникнет во время распаковки.

Минимальный пример:

Integer a = 100;
Integer b = 100;
Integer c = 1000;
Integer d = 1000;

System.out.println(a == b);      // обычно true
System.out.println(c == d);      // не следует считать true
System.out.println(c.equals(d)); // true

В первых двух сравнениях проверяется идентичность объектов, поэтому комментарий про 1000 означает не обязательное значение результата, а отсутствие гарантии. Надежный выбор зависит от требований: equals подходит для сравнения объектов-оберток, а сравнение после контролируемой распаковки — для арифметической логики.

Ситуация из практики

В сервисе лимит пользователя хранился как Integer, а проверка совпадения выполнялась через ==. Тесты с малыми лимитами проходили благодаря кэшированию, но для более крупных значений часть запросов ошибочно считалась несоответствующей.

Рассматривались два варианта. Явная распаковка хорошо отражает числовую семантику, но требует отдельно определить поведение при null; equals безопаснее с точки зрения сравнения объектов, однако вызов метода на потенциально null-ссылке опасен. Был выбран null-безопасный вариант сравнения значений через стандартную проверку равенства объектов.

После замены сравнения логика перестала зависеть от диапазона числа и от конкретной реализации кэширования. Дополнительно для полей, которые не могут отсутствовать, был выбран примитивный тип int, что исключило ненужную упаковку.

Что кандидаты часто упускают

Гарантирует ли Java одинаковую идентичность для любых двух одинаковых Integer?

Нет. Гарантируется только ограниченное совместное использование экземпляров для части малых целых значений. Для остальных значений одинаковое числовое содержимое не означает одинаковый объект, а конкретная реализация может кэшировать больше значений без обещания сохранять это поведение во всех условиях.

Изменится ли смысл сравнения, если один операнд имеет тип int?

Да. Если один операнд — примитив int, а другой — Integer, объект распаковывается в int, после чего сравниваются числовые значения. Но если Integer равен null, автоматическая распаковка выбросит NullPointerException.

Почему equals предпочтительнее ==, но тоже требует осторожности?

equals сравнивает содержимое Integer, поэтому не зависит от идентичности и кэширования объектов. Однако вызов вида «метод на переменной Integer» небезопасен при null; если отсутствие значения допустимо, нужно использовать null-безопасную форму сравнения или заранее определить политику обработки null.