Вывод фрагмента:
System.out.println(a==b); // false
System.out.println(a.equals(b)); // true
Краткое объяснение (шаги и причины):
1) Автоупаковка (autoboxing)
- Выражение `Integer a = 128;` компилируется примерно в вызов `Integer.valueOf(128)`. То же для `b`.
- То есть оба присваивания используют `Integer.valueOf($128$)`.
2) Пул (кеш) малых целых
- В стандартной реализации JDK метод `Integer.valueOf` возвращает закешированный объект для значений в диапазоне $-128$ до $127$ включительно ($-128$ … $127$).
- Для значений вне этого диапазона (например $128$) для каждого вызова возвращается отдельный объект (если кеш не расширён).
3) Поведение `==` и `equals`
- Оператор `==` для ссылочных типов сравнивает ссылки (identity), т.е. проверяет, указывают ли `a` и `b` на один и тот же объект. Поскольку `Integer.valueOf($128$)` вернул два разных объекта, `a==b` даёт `false`.
- Метод `equals` у `Integer` сравнивает внутренние примитивные значения `int`, поэтому `a.equals(b)` сравнивает $128==128$ и возвращает `true`.
Доп. замечания:
- Если бы использовалось `Integer a = 127; Integer b = 127;`, то `a==b` был бы `true` из‑за кеша.
- При сравнении со примитивом (например `a == 128` или `a == c`, где `c` — `int`) происходит автораспаковка (`a.intValue()`), и сравниваются примитивы, поэтому `a == 128` даёт `true`.
- Диапазон кеша можно изменить в HotSpot через JVM-опцию (например `-XX:AutoBoxCacheMax=...`), но по умолчанию это $-128$ … $127$.