Размеры типов данных в Java

#переменные #java #книги

В книге П. Ноутона, Г. Шилдта "Java 2. Наиболее полное руководство" сказано следующее
о размерах типов данных:

О ширине (или количестве бит, отводимых для хранения значения) целочисленного типа
нельзя думать как о количестве памяти, которую он занимает, а скорее, как о поведении,
которое она определяет для переменных и выражений этого типа. Исполнительная среда
Java вольна использовать любой размер, какой она хочет, тогда как типы ведут себя согласно
их объявлению. Существует по крайней мере одна реализация исполнительной среды, которая
хранит числа byte и short как 32-разрядные (а не 8- и 16-разрядные) значения, чтобы
улучшить эффективность, потому что этим значением выражается размер слова большинства
используемых в настоящее время компьютеров.

В другом месте этой книги сказано:

Может показаться, что использование short или byte экономит память, но нет никакой
гарантии, что Java не будет внутренне так или иначе расширять эти типы до int. Помните,
что тип определяет поведение, а не размер. (Единственное исключение - массивы, где
тип byte гарантирует использование только одного байта на элемент массива, в то время
как short будет забирать два байта, а int - четыре байта).

В связи с вышеприведенным у меня возник вопрос: что подразумевается под словом поведение
переменных целочисленного типа и действительно ли, что для переменных, не объявленных
как массивы, размер не определен?
    

Ответы

Ответ 1

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

Например, во времена Си, по стандарту существовали только отношения типа short int
<= int <= long int, все остальное являлось спецификой конкретной платформы. Это весьма
шаткое положение вещей, которое было учтено в дизайне Java.

Стандартом Java Language Specification четко заданы крайние значения для типов, то
есть минимальная битность на физическом уровне. Например, long должен оперировать с
64-битными значениями, даже если нижележащая аппаратная платформа так не умеет. 

Кто угодно может написать свою "реализацию" JVM или языка Java, но если результат
не будет удовлетворять спецификации назвать это "Java" уже нельзя, в спецификации вся
суть технологии. Рассматривать проблемы с такими "реализациями" можно, но важно дистанцироваться
от них, ведь это уже не проблемы Java-платформы, а проблемы какого-то стороннего решения.

Можно ли это использовать как-то для определения реального железного перфоманса?
Например, на 32-битной машине long, условно говоря, физически будет представлен двумя
интами, то есть код работы с лонгами будет более медленный. С другой стороны, при переходе
на 64-битную систему программа сама начинает работать медленней (до 20% на SPARC, 0-15%
на AMD64 и EM64T) хотя бы из-за размера указателя увеличившегося с 4 до 8 байт. Иначе
говоря, все сложно.

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


Ответ 2

Судя по всему под поведением авторы понимают то, как можно работать с этой этим типом
данных, какие у неё границы, как можно конвертировать и т.п.
По поводу второго вопроса: вам необходимо знать, что существуют несколько реализаций
виртуальной машины (она называется сокращенно JVM) от разных компаний. Так вот в разных
JVM при выполнении кода:
int  i = 1;

переменная i может быть, либо 4, либо 8 байт. И это зависит от реализации JVM.
Моё имхо и опыт подсказывают - пока вы не пишете программы, которые работают с миллионами
записей, не стоит сильно на этом заморачиваться. Лучше осваивать программирование на
java в целом. Когда подойдете к черте, где программы будут большими, вы уже будете
знать, что с этим делать и как профайлить код.