В Java должен ли объект Integer быть предпочтительнее примитива int (то же самое для других числовых типов)?

Хорошо, поэтому я понимаю, что Integer - это просто класс-оболочка. однако меня беспокоит то, что, избегая использования «оболочки», может возникнуть микрооптимизация времени выполнения при использовании примитивных переменных типа int.

Мой вопрос касается того, действительно ли объект Integer тот, который мы должны предпочесть использовать, особенно в программах, которые должны иметь высокую производительность (с большими, я имею в виду, тяжелыми, O (N ^ n) алгоритмами, которые занимают дни) .

Также такой же случай для double vs Double, float vs Float и т. Д.


java performance micro-optimization
person Jorch914    schedule 11.05.2015    source источник
comment
Нет, в большинстве случаев int проще в использовании, чем Integer. Что заставляет вас думать, что вы должны использовать Integer все время?   -  person Jon Skeet    schedule 11.05.2015
comment
На этот вопрос уже был дан ответ здесь и здесь и здесь и здесь.   -  person Kevin Workman    schedule 11.05.2015
comment
На самом деле я предпочитаю примитивные типы, просто я начал видеть людей, использующих объекты Integer, и тот факт, что эти объекты Integer существуют, некоторое время беспокоил меня. Я подумал, что может быть какое-то объяснение того, как на самом деле работает jvm или что-то в этом роде.   -  person Jorch914    schedule 11.05.2015
comment
Следует отметить одно: вся суть O (f (n)) заключается в том, что такие вещи, как производительность конкретного объекта, незначительны по сравнению с самим алгоритмом для больших входных данных. Подобные оптимизации ничего не значат, если сам алгоритм настолько плох.   -  person RealSkeptic    schedule 11.05.2015

Ответы (3)


arrow_upward
10
arrow_downward

По возможности лучше использовать примитивы. Иначе бы их не было. Разработчики Java даже приложили дополнительные усилия для разработки (для Java 8) Streams, которые поддерживают примитивные типы (IntStream, LongStream, DoubleStream), поэтому вам не придется платить за производительность нескольких упаковок и распаковок, которые вы платите при использовании Streams. ссылочных типов для классов-оболочек.

Обертки предназначены только для случаев, когда у вас нет выбора (например, вы не можете помещать примитивные типы непосредственно в коллекцию).

person Eran    schedule 11.05.2015
comment
нельзя ставить примитивы * - person Dici; 11.05.2015
comment
@Dici, спасибо, что поймали мою опечатку. Со мной довольно часто случается, что когда я быстро печатаю, я пишу «могу» или «могу», а не «не могу» или «нет». :) - person Eran; 11.05.2015
comment
Нп, это опечатка :) - person Dici; 11.05.2015

arrow_upward
3
arrow_downward

Экземпляр класса оболочки занимает больше памяти (обернутое значение + ссылка) и генерирует вызовы некоторых методов, в которых примитивные типы выполняют только базовые операции. Однако некоторые механизмы имеют тенденцию уменьшать эти накладные расходы (например, экземпляры Integer между -128 и 127 хранятся в пуле, если не объявлены с использованием new). Разница, вероятно, небольшая, но там, где вы можете использовать примитивы, делайте это просто по принципу: не используйте классы, которые предоставляют больше функций, которые вам нужны.

person Dici    schedule 11.05.2015

arrow_upward
1
arrow_downward

Предпочитайте int Integer, если null не является допустимым значением или оно не будет помещено в коллекцию.

person Steve Kuo    schedule 11.05.2015
comment
В старой Java - да, в остальном я думаю, что Optional<Integer> более выразителен ... и надежен. - person Dici; 11.05.2015
comment
С примитивом вы получите гарантию времени компиляции, что он не равен нулю. Похоже (поправьте меня, если я ошибаюсь), Optional - это только проверка во время выполнения. - person Steve Kuo; 12.05.2015
comment
Я думал, что вы предлагали использовать Integer, когда вы хотите, чтобы ваше целочисленное значение, возможно, отсутствовало (null), тогда как Optional лучше всего подходит для обработки отсутствия какого-либо значения. - person Dici; 12.05.2015
comment
@Dici Optional<Integer> извращен вдвойне, потому что у вас два объекта вместо одного. В качестве бонуса тоже может быть null. - person maaartinus; 12.05.2015
comment
@maaartinus, ваш первый аргумент весьма надуман. Является ли Pair злом, потому что это три объекта вместо двух? Важна семантика программы, а не количество объектов во время выполнения, пока она остается разумной. Да, Optional может быть null, но, по крайней мере, вы знаете, что это не предназначено, тогда как намеренное использование типа оболочки для использования null для выражения отсутствия значения означает, что null является приемлемым значением. Это очень плохая семантика, где Optional сразу сообщает, что они не могут иметь значения даже при нормальном выполнении. - person Dici; 13.05.2015
comment
@maaartinus В качестве примера я видел такие ошибки, как if (myBooleanInstance) нарушение, когда Boolean где null, потому что разработчик не знал достаточно контекста о кодовой базе, чтобы предположить, что null следует рассматривать как случай, не связанный с ошибкой. С Optional он должен был написать что-то вроде if (myOptional.orElse(false)). Optional заставляет во время компиляции позаботиться о конкретном случае отсутствия значения. Это никак нельзя назвать извращенным - person Dici; 13.05.2015
comment
Нет, Pair зло только потому, что не передает семантики, но в отличие от Optional, это имеет дополнительную ценность. Что касается этого, я полностью согласен с этой красивой тирадой . Более того, его введение заблокировало путь к разумному null обращению (например, так, как это делает Kotlin). С некоторым синтаксическим сахаром все, что дает Optional, может быть достигнуто, и даже больше. С синтаксисом, подобным Kotlin, Boolean? myBooleanInstance является типом, допускающим значение NULL, и не может использоваться в качестве условия. Так просто. - person maaartinus; 13.05.2015