Перейти на PRO

С каким примитивным типом JVM работает эффективнее: int или short?

Тип вопроса: Java Core Вероятность: 10% Категория: Java Разработчик

Ответ

JVM оптимизирована для более эффективной работы с типом int (32 бита), чем с short (16 бит).

Причины:

  1. Нативные инструкции JVM: Базовый набор инструкций виртуальной машины (например, iload, iadd, istore) предназначен для операций с 32-битными int значениями. Для short используются те же инструкции, но с дополнительными преобразованиями.
  2. Автоматическое расширение (promotion): В арифметических и побитовых операциях short (и byte, char) неявно расширяется до int. Это требует явного приведения обратно к short, что добавляет накладные расходы. 
    short a = 1000;
short b = 2000;
// Результат a + b имеет тип int, требуется приведение
short c = (short) (a + b); // Риск переполнения!
  3. Выравнивание и производительность: Современные процессоры и системы памяти эффективнее работают с 32- и 64-битными словами. Использование short в локальных переменных или вычислениях часто не дает выигрыша в скорости, а иногда даже замедляет выполнение из-за необходимости маскирования и приведения типов.
  4. Экономия памяти актуальна только для массивов.
    • short[] действительно использует примерно в два раза меньше памяти, чем int[].
    • Для отдельных переменных экономия незначительна из-за выравнивания.

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

Ответ 18+ 🔞

Да ты послушай, какой прикол-то, с этими типами данных в Java! Ну вот сидит человек, думает: "Ага, short — 16 бит, меньше памяти жрёт, значит, быстрее будет! Щас я всюду short натыкаю, и программа взлетит!" Ага, щас, держи карман шире.

Вот смотри, JVM-то эта, она, блядь, заточена под int — под эти самые 32 бита. Как будто это её родной, ебаный, размер слова. Вся её внутренняя кухня — инструкции iload, iadd — они все на int работают. А когда ты ей short подсовываешь, она его сначала в int расширяет, потом с ним работает, а потом, если тебе назад short надо, ещё и обратно пихает с приведением типа. Это ж, блядь, лишние телодвижения, нахуй! Ебушки-воробушки, ну зачем так жить?

Вот реальный пример, чтобы не быть голословным:

short a = 1000;
short b = 2000;
// Смотри сюда, умник! a + b — результат уже int, ёпта!
// Хочешь обратно в short? Получай явное приведение и рискуй переполнением!
short c = (short) (a + b); // А тут может такое вылезти, что мало не покажется!

И самое, блядь, смешное — в производительности ты нихуя не выигрываешь, а часто даже проигрываешь! Процессоры современные заточены под 32/64 бита, им проще с такими словами работать. А твой short они внутри всё равно в int развернут, да ещё и маскировать будут, чтобы лишние биты обрезать. Пиздец, а не оптимизация.

Так когда же этот short вообще нужен, спросишь ты? А вот когда, хитрая жопа: только в больших массивах! short[] — да, реально памяти в два раза меньше, чем int[], съест. Если у тебя там гигабайты данных, вот это уже повод подумать. А для отдельной переменной-счётчика в цикле? Да похуй! Разница — пыль! Из-за выравнивания памяти она всё равно место может занимать как int. Не морочь людям голову.

Короче, вывод, блядь, простой, как три копейки:
По умолчанию везде int. Не выёбывайся. short — это специнструмент для особых случаев с огромными массивами, когда каждый байт на счету. Всё остальное — преждевременная оптимизация и мартышлюшка.

© ХакСобесов, 2026
support@hacksobesov.com