Почему в Java до сих пор используются примитивные типы?

Автоунбоксинг может привести к трудно обнаруживаемым НПЭ

Integer in = null;
...
...
int i = in; // NPE at runtime

В большинстве случаев нулевое присвоение in намного менее очевидно, чем указано выше.

Типы в штучной упаковке имеют более низкую производительность и требуют больше памяти.

Примитивные типы:

int x = 1000;
int y = 1000;

Теперь оцените:

x == y

Это true. Вряд ли удивительно. Теперь попробуйте коробочные типы:

Integer x = 1000;
Integer y = 1000;

Теперь оцените:

x == y

Это false. Наверное. Зависит от времени выполнения. Достаточно ли этой причины?

Помимо проблем с производительностью и памятью, я хотел бы затронуть еще одну проблему: _ 1_ интерфейс будет нарушен без int.
Проблема заключается в перегруженном remove() методе (_ 4_ по сравнению с _ 5_). remove(Integer) всегда разрешает вызов последнего, поэтому вы не можете удалить элемент по индексу.

С другой стороны, при попытке добавить и удалить int есть ловушка:

final int i = 42;
final List<Integer> list = new ArrayList<Integer>();
list.add(i); // add(Object)
list.remove(i); // remove(int) - Ouch!

Вы действительно можете представить

  for (int i=0; i<10000; i++) {
      do something
  }

цикл с java.lang.Integer вместо этого? Java.lang.Integer является неизменяемым, поэтому каждое приращение цикла будет создавать новый объект java в куче, а не просто увеличивать int в стеке с помощью одной инструкции JVM. Спектакль был бы дьявольским.

Я действительно не согласен с тем, что гораздо удобнее использовать java.lang.Integer, чем int. Напротив. Autoboxing означает, что вы можете использовать int там, где в противном случае вы были бы вынуждены использовать Integer, а компилятор java позаботится о вставке кода для создания нового объекта Integer для вас. Autoboxing позволяет вам использовать int там, где ожидается Integer, а компилятор вставляет соответствующую конструкцию объекта. Это никоим образом не устраняет и не уменьшает потребность в int в первую очередь. С автобоксом вы получаете лучшее из обоих миров. Вы получаете целое число, созданное для вас автоматически, когда вам нужен java-объект на основе кучи, и вы получаете скорость и эффективность int, когда вы просто выполняете арифметические и локальные вычисления.

Примитивные типы намного быстрее:

int i;
i++;

Целое число (все числа, а также строка) - это неизменяемый тип: однажды созданный, его нельзя изменить. Если i был целым числом, то i++ создал бы новый объект типа Integer - намного дороже с точки зрения памяти и процессора.

В первую очередь, привычка. Если вы восемь лет программировали на Java, у вас накопится значительная инерция. Зачем меняться, если для этого нет веских причин? Это не значит, что использование примитивов в штучной упаковке дает какие-либо дополнительные преимущества.

Другая причина состоит в том, чтобы утверждать, что null не является допустимым вариантом. Было бы бессмысленно и вводить в заблуждение объявлять сумму двух чисел или переменную цикла как Integer.

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

Между прочим, в Smalltalk есть только объекты (без примитивов), и все же они оптимизировали свои маленькие целые числа (используя не все 32 бита, только 27 или что-то подобное), чтобы не выделять какое-либо пространство кучи, а просто использовать специальный битовый шаблон. Также другие общие объекты (true, false, null) имеют здесь специальные битовые шаблоны.

Итак, по крайней мере, на 64-битных JVM (с 64-битным пространством имен указателей) должна быть возможность вообще не иметь никаких объектов типа Integer, Character, Byte, Short, Boolean, Float (и small Long) (кроме созданных явным new ...()), только специальные битовые комбинации, с которыми можно довольно эффективно манипулировать обычными операторами.

Не могу поверить, что никто не упомянул, что я считаю самой важной причиной: «int» намного проще набирать, чем «Integer». Я думаю, что люди недооценивают важность краткого синтаксиса. Производительность на самом деле не причина избегать их, потому что большую часть времени, когда используются числа, находятся в индексах цикла, а увеличение и сравнение этих значений ничего не стоит в любом нетривиальном цикле (независимо от того, используете ли вы int или Integer).

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

Другая причина заключалась в том, что (new Long (1000)) == (new Long (1000)) ложно, но это просто еще один способ сказать, что «.equals» не имеет синтаксической поддержки для упакованных типов (в отличие от операторов ‹,> , = и т.д.), поэтому мы возвращаемся к причине "более простого синтаксиса".

Я думаю, что пример непримитивного цикла Стива Йегге очень хорошо иллюстрирует мою точку зрения: http://sites.google.com/site/steveyegge2/language-trickery-and-ejb.

Подумайте об этом: как часто вы используете типы функций на языках, которые имеют для них хороший синтаксис (например, любой функциональный язык, python, ruby ​​и даже C) по сравнению с java, где вы должны моделировать их с помощью таких интерфейсов, как Runnable и Callable и безымянные классы.

Пара причин не избавляться от примитивов:

• Обратная совместимость.

Если его исключить, никакие старые программы даже не запустятся.

• Перезапись JVM.

Всю JVM пришлось бы переписать, чтобы поддерживать эту новую вещь.

• Больший объем памяти.

Вам нужно будет сохранить значение и ссылку, которая использует больше памяти. Если у вас огромный массив байтов, использование byte значительно меньше, чем использование Byte.

• Проблемы с нулевым указателем.

Объявление int i и выполнение чего-либо с i не вызовет проблем, но объявление Integer i и последующее выполнение того же результата приведет к NPE.

• Вопросы равенства.

Рассмотрим этот код:

Integer i1 = 5;
Integer i2 = 5;

i1 == i2; // Currently would be false.

Было бы ложью. Операторы должны быть перегружены, и это приведет к серьезному переписыванию материала.

• Медленный

Обертки объектов значительно медленнее своих примитивных аналогов.

Объекты намного тяжелее, чем примитивные типы, поэтому примитивные типы намного эффективнее, чем экземпляры классов-оболочек.

Примитивные типы очень просты: например, int имеет размер 32 бита, занимает ровно 32 бита в памяти и может управляться напрямую. Целочисленный объект - это законченный объект, который (как и любой объект) должен храниться в куче, и к нему можно получить доступ только через ссылку (указатель) на него. Скорее всего, он также занимает более 32 бит (4 байта) памяти.

Тем не менее, тот факт, что в Java есть различие между примитивными и непримитивными типами, также является признаком возраста языка программирования Java. В новых языках программирования такого различия нет; компилятор такого языка достаточно умен, чтобы самостоятельно определить, используете ли вы простые значения или более сложные объекты.

Например, в Scala нет примитивных типов; существует класс Int для целых чисел, а Int - это реальный объект (для которого вы можете использовать методы и т. д.). Когда компилятор компилирует ваш код, он за кулисами использует примитивные int, поэтому использование Int столь же эффективно, как использование примитивного int в Java.

В дополнение к тому, что говорили другие, примитивные локальные переменные выделяются не из кучи, а вместо этого в стеке. Но объекты выделяются из кучи и, следовательно, должны быть собраны в мусор.

У примитивных типов есть много преимуществ:

• Более простой код для написания
• Производительность лучше, поскольку вы не создаете экземпляр объекта для переменной.
• Поскольку они не представляют собой ссылку на объект, нет необходимости проверять нули.
• Используйте примитивные типы, если вам не нужно использовать преимущества бокса.

Трудно понять, какие именно оптимизации происходят под прикрытием.

Для локального использования, когда компилятор имеет достаточно информации для оптимизации, исключающей возможность нулевого значения, я ожидаю, что производительность будет такой же или аналогичной.

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

Кроме того, Integer имеет гораздо более высокие логические издержки по сравнению с int: теперь вам нужно беспокоиться о том, вызывает ли int a = b + c; исключение.

Я бы использовал примитивы в максимально возможной степени и полагался бы на фабричные методы и автобоксинг, чтобы получить более семантически мощные упакованные типы, когда они необходимы.

int loops = 100000000;

long start = System.currentTimeMillis();
for (Long l = new Long(0); l<loops;l++) {
    //System.out.println("Long: "+l);
}
System.out.println("Milliseconds taken to loop '"+loops+"' times around Long: "+ (System.currentTimeMillis()- start));

start = System.currentTimeMillis();
for (long l = 0; l<loops;l++) {
    //System.out.println("long: "+l);
}
System.out.println("Milliseconds taken to loop '"+loops+"' times around long: "+ (System.currentTimeMillis()- start));

Миллисекунды, затраченные на цикл 100000000 раз вокруг Long: 468

Миллисекунды, затраченные на цикл 100000000 раз вокруг long: 31

Кстати, я бы не прочь увидеть что-то подобное в Java.

Integer loop1 = new Integer(0);
for (loop1.lessThan(1000)) {
   ...
}

Где цикл for автоматически увеличивает loop1 от 0 до 1000 или

Integer loop1 = new Integer(1000);
for (loop1.greaterThan(0)) {
   ...
}

Где цикл for автоматически уменьшает loop1 1000 до 0.

1. Вам нужны примитивы для выполнения математических операций
2. Примитивы занимают меньше памяти, как указано выше, и лучше работают

Вы должны спросить, зачем нужен тип класса / объекта

Причина наличия типа объекта в том, чтобы облегчить нашу жизнь, когда мы имеем дело с коллекциями. Примитивы нельзя добавлять напрямую в список / карту, вам нужно написать класс-оболочку. Здесь вам помогут классы Readymade Integer, плюс у него есть много служебных методов, таких как Integer.pareseInt (str)

Я согласен с предыдущими ответами, использование объектов-оберток примитивов может быть дорогостоящим. Но если производительность вашего приложения не критична, вы избегаете переполнения при использовании объектов. Например:

long bigNumber = Integer.MAX_VALUE + 2;

Значение bigNumber - -2147483647, и вы ожидаете, что это будет 2147483649. Это ошибка в коде, которую можно исправить, выполнив следующие действия:

long bigNumber = Integer.MAX_VALUE + 2l; // note that '2' is a long now (it is '2L').

И bigNumber будет 2147483649. Иногда такие ошибки легко пропустить и они могут привести к неизвестному поведению или уязвимостям (см. CWE-190).

Если вы используете объекты-оболочки, эквивалентный код не будет компилироваться.

Long bigNumber = Integer.MAX_VALUE + 2; // Not compiling

Так что такие проблемы легче решить, используя объекты-оболочки примитивов.

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

Потому что JAVA выполняет все математические операции с примитивными типами. Рассмотрим этот пример:

public static int sumEven(List<Integer> li) {
    int sum = 0;
    for (Integer i: li)
        if (i % 2 == 0)
            sum += i;
        return sum;
}

Здесь операции напоминания и унарного плюса не могут применяться к типу Integer (Reference), компилятор выполняет распаковку и выполняет операции.

Итак, убедитесь, сколько операций автобокса и распаковки происходит в java-программе. Поскольку для выполнения этой операции требуется время.

Как правило, лучше сохранять аргументы типа Ссылка и результат примитивного типа.

Примитивные типы намного быстрее и требуют гораздо меньше памяти. Следовательно, мы можем предпочесть их использование.

С другой стороны, текущая спецификация языка Java не допускает использования примитивных типов в параметризованных типах (обобщенных типах), в коллекциях Java или API Reflection.

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

* Подробную информацию см. В источнике: https://www.baeldung.com/java-primitives-vs-objects

Чтобы быть кратким: примитивные типы быстрее и требуют меньше памяти, чем коробочные.