Типы, обёртки и String в Java

Примитивы, обёртки и граница кэша

int - голое значение в памяти. Integer - объект-обёртка вокруг него, а значит может быть null, и оператор == сравнивает ссылки, а не числа. Автобоксинг переводит одно в другое молча: удобно, но в цикле это создание объекта на каждой итерации, а рядом с null - мина.

Границу кэша я нашёл замером: Integer.valueOf(127) == Integer.valueOf(127) даёт true, а для 128 - уже false. Обёртки в диапазоне от минус 128 до 127 берутся из общего пула, поэтому маленькие числа сравниваются «правильно» по чистой случайности. Код, прошедший тесты на сотне, падает на тысяче.

Распаковка null даёт NPE (NullPointerException). Самый коварный вариант - тернарный оператор со смешанными ветками. Я проверил: выражение flag ? 1 : nullInteger роняет NPE, даже когда результат присваивается в Object - тип всего выражения стал int из-за ветки с единицей, поэтому вторая ветка распаковывается. Сделай обе ветки Integer, и NPE исчезает.

Integer a = 100, b = 100, c = 200, d = 200;
a == b   // true  - оба из кэша -128..127
c == d   // false - уже разные объекты
Object o = flag ? 1 : nullInteger; // NPE при flag == false

автобоксинг

неявный перевод примитива в обёртку и обратно

кэш обёрток

от минус 128 до 127 объекты общие, дальше новые

String: неизменяемость, пул и методы-обманки

Проверил на живом коде: строка «hello», вызов s.replace без присваивания результата - и печать снова выдаёт «hello». String неизменяем, любая «модификация» возвращает новый объект, а старый остаётся как был.

Второе следствие неизменяемости дороже. Замерил сборку строки из 40 000 символов: через оператор += вышло 141,9 мс, через StringBuilder - 5,1 мс. Разница в 28 раз, и она растёт с длиной, потому что каждая конкатенация копирует всю строку целиком.

Пул строк объясняет, почему == со строками «иногда работает»: одинаковые литералы интернируются и указывают на один объект, поэтому сравнение даёт true. А new String("hi") создаёт отдельный объект, и то же сравнение даёт false. Вывод один - строки сравниваем только через equals.

// Метод-обманка: split принимает регулярное выражение. Я замерил, "a.b.c".split(".") возвращает массив из НУЛЯ элементов, потому что точка в регулярке значит «любой символ». Нужно split("\\.") - тогда три.

пул строк

общее хранилище интернированных литералов

StringBuilder

изменяемая сборка строки без копирования на каждом шаге

Пробелы, дробные числа и молчаливые переполнения

Про пробелы отдельно, потому что тут все ошибаются. Замерил четыре случая на строке вида «пробел-икс-пробел»: обычный пробел и табуляцию убирают и trim, и strip. Длинный пробел U+2003 убирает только strip - вот ради этого он и появился. А неразрывный пробел U+00A0 не убирает НИ ОДИН из двух, потому что Character.isWhitespace считает его непробельным. Именно он приезжает из копипаста, и именно он переживает любую чистку.

Дробные числа: 0.1 + 0.2 в Java равно 0.30000000000000004, сравнение с 0.3 даёт false. Двоичная плавающая точка не представляет десятичные дроби точно. Для физики и машинного обучения это нормально, для денег - недостача на проде.

Деньги считают через BigDecimal, и обязательно со строковым конструктором. Я напечатал оба: new BigDecimal(0.1) даёт 0.1000000000000000055511151231257827021181583404541015625, то есть весь двоичный мусор из double, а new BigDecimal("0.1") даёт ровно одну десятую.

// Целые переполняются молча. Integer.MAX_VALUE + 1 равно минус 2147483648, без всякого исключения. Приведение long к int просто обрезает старшие биты: 4294967303 превратилось в 7. А деление 7 / 2 даёт 3, потому что дробная часть отбрасывается.

BigDecimal

точная десятичная арифметика, для денег обязательна

неразрывный пробел

U+00A0: его не убирают ни trim, ни strip

Как отвечать: «Integer a = 100, b = 100; a == b - что вернёт и почему?»

Вернёт true, но это ловушка. Integer это объект, и оператор == сравнивает ссылки, а не числа. Работает оно здесь только потому, что виртуальная машина кэширует обёртки в диапазоне от минус 128 до 127, и оба боксинга вернули один и тот же объект из пула. Я проверял границу: для 127 сравнение даёт true, для 128 уже false. Поэтому если написать те же две строки со значением 200, результат перевернётся, и это классический продовый инцидент - код прошёл тесты на маленьких идентификаторах и сломался на боевых. Обёртки я сравниваю только через equals либо распаковываю до примитивов. И рядом держу в голове второй риск: распаковка null даёт NullPointerException, причём самый неочевидный случай - тернарный оператор, где одна ветка int, а другая Integer. Тогда тип всего выражения становится int, и null-ветка распаковывается, даже если результат уходит в Object.

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

На чём валят

• −Сравнивают обёртки через ==. Работает до 127, ломается со 128 - сравнение только через equals.
• −Зовут s.replace или s.substring и не присваивают результат. Строка неизменяема, ничего не произошло.
• −Собирают строку в цикле через +=. На 40 000 итераций у меня вышло 142 мс против 5 мс у StringBuilder.
• −Пишут split(".") или split("|") без экранирования. Это регулярное выражение, результат пустой или посимвольный.
• −Ждут, что trim или strip уберут неразрывный пробел. Ни один из них его не трогает.