Java Integer pool. Зачем?
Я везде читал, что когда вы определяете Integer в Java от -128 до 127, вместо создания нового объекта он возвращает уже созданный объект.
Я не вижу смысла делать это, кроме как позволить начинающим программистам сравнивать объекты Integer с == чтобы узнать, совпадают ли они с одним числом, но я думаю, что это плохо, потому что они уверены, что могут сравнить любое целое число с ==, а также учит плохой практике на любом языке программирования: сравнивая содержание двух "разных" объектов с ==,
Есть ли другая причина, почему это сделано? Или это просто плохое решение при разработке языка (на мой взгляд), как необязательная точка с запятой в JavaScript?
РЕДАКТИРОВАТЬ: я вижу здесь, что они объясняют поведение: почему поведение пула констант Integer изменяется на 127?
Я спрашиваю, почему они спроектировали это так, а не почему это происходит.
2 ответа
Он называется шаблоном Flyweight и используется для минимизации использования памяти.
Скорее всего, эти цифры будут использоваться повторно, а такие типы автозапчастей, как Integer неизменны (обратите внимание, это сделано не только для Integer). Кэширование их делает это таким образом, чтобы не было большого количества экземпляров, а также уменьшает работу GC (Сборка мусора).
JLS покрывает это в 5.1.7. Конвертация бокса конкретно, сказав:
Если значение p в штучной упаковке является истинным, ложным, байтом или символом в диапазоне от \u0000 до \u007f, или целым или коротким числом от -128 до 127 (включительно), то пусть r1 и r2 будут результатами любые два преобразования бокса р. Это всегда тот случай, когда r1 == r2.
В идеале, бокс заданного примитивного значения p всегда будет давать одинаковую ссылку. На практике это может оказаться невозможным при использовании существующих методов реализации. Приведенные выше правила являются прагматическим компромиссом. Последнее предложение выше требует, чтобы определенные общие значения всегда помещались в неразличимые объекты. Реализация может кэшировать их, лениво или охотно. Для других значений эта формулировка не допускает никаких предположений об идентичности значений в штучной упаковке со стороны программиста. Это позволит (но не требует) совместного использования некоторых или всех этих ссылок.
Это гарантирует, что в большинстве распространенных случаев поведение будет желательным без наложения чрезмерного снижения производительности, особенно на небольших устройствах. Реализации с меньшим объемом памяти могут, например, кэшировать все значения типа char и short, а также значения типа int и long в диапазоне от -32K до +32K.
Я думаю, что создание любого объекта занимает больше времени, чем получение его из таблицы символов. Более того, если я не ошибаюсь, каждый объект в куче занимает 24 байта дополнительного пространства для заголовка. Теперь, если программист пишет свою программу, большая часть операций выполняется для маленьких целых чисел (в данном случае маленьких целых чисел). Так что это позволяет сэкономить много места и немного улучшить производительность.