Пул Java Integer. Зачем?

Вопрос:Я читал везде, что, когда вы определяете Integer между -128 и 127 в Java, вместо создания нового объекта он возвращает уже созданный объект. Я не вижу смысла делать это иначе, чем позволить программистам-новичкам сравнивать объекты Integer с ==, чтобы узнать, являются ли они одинаковым числом, но я думаю, что это плохо, потому что они уверены,

Вопрос:

Я читал везде, что, когда вы определяете Integer между -128 и 127 в Java, вместо создания нового объекта он возвращает уже созданный объект.

Я не вижу смысла делать это иначе, чем позволить программистам-новичкам сравнивать объекты Integer с ==, чтобы узнать, являются ли они одинаковым числом, но я думаю, что это плохо, потому что они уверены, что могут сравнить любое целое число с ==, а также учит плохой практике на любом языке программирования: сравнивая содержимое двух “разных” объектов с ==.

Есть ли другая причина, почему это делается? Или это просто плохое решение при разработке языка (с моей точки зрения), как необязательная точка с запятой в JavaScript?

EDIT: я вижу здесь, что они объясняют поведение: Почему поведение пула констант Integer изменяется на 127?

Я спрашиваю, почему они спроектировали его таким образом, а не почему такое поведение происходит.

Лучший ответ:

Он называется Весовой рисунок и используется для минимизации использования памяти.

Эти числа, скорее всего, будут использоваться повторно, а типы autobox, такие как Integer, неизменяемы (обратите внимание, что это делается не только для Integer). Кэширование их делает так, что не так много примеров и уменьшает работу GC (Garbage Collection).

JLS охватывает это в 5.1.7. Бокс Конверсия, в частности, говоря:

Если значение p в боксе равно true, false, байту или char в диапазоне от u0000 доu007f или int или коротком числе между -128 и 127 (включительно), тогда пусть r1 и r2 – результаты любых двух бокс-преобразований p. Всегда бывает, что r1 == r2.

В идеале, бокс данного примитивного значения p всегда будет давать идентичную ссылку. На практике это может оказаться невозможным с использованием существующих методов внедрения. Правила выше – прагматичный компромисс. Последнее заключительное предложение требует, чтобы определенные общие значения всегда помещались в неразличимые объекты. Реализация может кэшировать эти, лениво или нетерпеливо. Для других значений эта формулировка запрещает любые предположения о идентичности вложенных значений в части программиста. Это позволило бы (но не требовать) совместного использования некоторых или всех этих ссылок.

Это гарантирует, что в большинстве распространенных случаев поведение будет желательным, не налагая чрезмерного штрафа за производительность, особенно на небольшие устройства. Менее ограниченные памятью реализации могут, например, кэшировать все char и короткие значения, а также значения int и long в диапазоне от -32K до + 32K.

Ответ №1

Я думаю, что для создания любого объекта требуется больше времени, чем взятие его из таблицы символов. Более того, если я не ошибаюсь, каждый объект в куче занимает 24 байта дополнительного пространства для заголовка. Теперь, если программист пишет свою программу, большая часть операций выполняется на небольших ints (в данном случае, на маленьких целых числах). Таким образом, это позволяет экономить много места и немного улучшать производительность.

Оцените статью
Добавить комментарий