Целые числа, кэширующиеся в Java [дубликат]
Возможный дубликат:
Странная упаковка JavaНедавно я видел презентацию, где был следующий образец кода Java:
Integer a = 1000, b = 1000; System.out.println(a == b); // false Integer c = 100, d = 100; System.out.println(c == d); // trueТеперь я немного смущен. Я понимаю, почему в первом случае результатом является "ложь" - это - потому что Целое число является ссылочным типом и ссылками "a", и "b" отличается.
Но почему во втором случае результат "верен"?
Я услышал мнение, которому кэширование JVM возражает для международных значений от-128 до 127 в некоторых целях оптимизации. Таким образом ссылки "c" и "d" являются тем же.
Кто-либо может дать мне больше информации об этом поведении? Я хочу понять цели этой оптимизации. В том, какая производительность случаев увеличена и т.д. Ссылка на некоторое исследование этой проблемы будет большой.
2 ответа
Я хочу понять цели этого оптимизация. В каких случаях повышена производительность и т. д. Ссылка на некоторые исследования этого проблема будет большой.
Основная цель состоит в том, чтобы сэкономить память, что также приводит к ускорению кода за счет большей эффективности кеширования.
По сути, класс Integer хранит кэш экземпляров Integer в диапазоне от -128 до 127, а также все автобоксы, литералы и варианты использования Integer.valueOf ( ) вернет экземпляры из этого кеша для охваченного диапазона.
Это основано на предположении, что эти небольшие значения встречаются гораздо чаще, чем другие целые числа, и поэтому имеет смысл избегать накладных расходов, связанных с наличием разных объектов для каждого экземпляра (объект Integer занимает что-то вроде 12 байт).
Посмотрите на реализацию Integer.valueOf (int) . Он вернет тот же объект Integer для входных данных меньше 256 .
РЕДАКТИРОВАТЬ:
На самом деле это от -128 до +127 по умолчанию, как указано ниже.