Почему внутренние вспомогательные переменные HashMap имеют тип int, который может быть байтовым типом данных - PullRequest
Новая
       6

Почему внутренние вспомогательные переменные HashMap имеют тип int, который может быть байтовым типом данных

1 голос
/ 27 марта 2012

HashMap внутренне имеет свои статические конечные переменные для своей работы. 

        static final int DEFAULT_INITIAL_CAPACITY = 16;

Почему они не могут использовать byte тип данных вместо int, так как значение слишком мало.

Ответы [ 6 ]

5 голосов
/ 27 марта 2012

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

Это статический финалпеременная, поэтому она выделяется только один раз для загрузчика классов.Я бы сказал, что мы можем сэкономить эти 3 (думаю, здесь) байта.

4 голосов
/ 27 марта 2012

Я думаю, что это потому, что емкость для Map выражается через int. Когда вы пытаетесь работать с byte и int, из-за правил продвижения, байт в любом случае будет преобразован в int. Емкость по умолчанию выражается в int, чтобы, возможно, избежать этих ненужных повышений.

3 голосов
/ 27 марта 2012

Использование byte или short для переменных и констант вместо int является преждевременной оптимизацией, которая почти не имеет никакого эффекта.

Большинство арифметических и логических инструкций JVM работают только с int, long, float и double, другие типы данных должны приводиться к (обычно) int с в порядкедля выполнения этих инструкций над ними.

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

Небольшой пример из книги Java Puzzlers : 

public static void main(String[] args) {
    for (byte b = Byte.MIN_VALUE; b < Byte.MAX_VALUE; b++) {
        if (b == 0x90)
            System.out.print("Joy!");
    }
}

Эта программа не печатает Joy!, поскольку шестнадцатеричное значение 0x90 неявно преобразуется в int со значением 144.Поскольку byte в Java подписаны (что само по себе очень неудобно), переменной b никогда не присваивается это значение (Byte.MAX_VALUE = 127), и, следовательно, условие никогда не выполняется.

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

2 голосов
/ 28 марта 2012

Преобразование из byte в int * (1002 * int` в любом случае) приведет к замедлению кода, если что-либо. Стоимость памяти довольно тривиальна в общей схеме вещей.

Учитывая, что по умолчанию может быть любое значение int, я думаю, int имеет смысл.

2 голосов
/ 27 марта 2012

Значения байтов по-прежнему занимают одно и то же пространство в JVM, и его также необходимо явно или неявно преобразовывать в int для практических целей, включая размеры массивов, индексы и т. Д.

1 голос
/ 27 марта 2012

Большая часть данных может быть представлена ​​в виде серии байтов.

Int - это тип данных по умолчанию, который большинство пользователей будет использовать при подсчете или работе с целыми числами.

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

каждый раз, когда вы пытаетесь 

int variablename = bytevariable;

, назначение не будет выполнено, однако 

double variablename = intVariable;

будет работать.

...