Dlaczego wartości buforowania klasy Integer mieszczą się w zakresie od -128 do 127?

Jeśli chodzi o moje poprzednie pytanie, dlaczego == porównania z Integer.valueOf (String) dają różne wyniki dla 127 i 128? , wiemy, że Integer classma pamięć podręczną, która przechowuje wartości między -128a 127.

Zastanawiam się tylko, dlaczego między -128 a 127 ?

Dokumentacja Integer.valueOf () stwierdza, że " buforuje często żądane wartości " . Ale czy wartości pomiędzy -128i 127są często wymagane naprawdę? Myślałem, że często wymagane wartości są bardzo subiektywne.
Czy jest jakikolwiek możliwy powód?

W dokumentacji stwierdzono również: „... i może buforować inne wartości spoza tego zakresu. ”
Jak można to osiągnąć?

Zastanawiam się tylko, dlaczego między -128 a 127?

W pamięci podręcznej może być przechowywany większy zakres liczb całkowitych , ale przynajmniej te między -128 a 127 muszą być buforowane, ponieważ jest to wymagane przez specyfikację języka Java (wyróżnienie moje):

Jeśli wartość p w ramce to prawda, fałsz, bajt lub znak w zakresie od \ u0000 do \ u007f lub liczba int lub krótka z zakresu od -128 do 127 (włącznie) , niech r1 i r2 będą wynikiem dowolne dwie konwersje bokserskie p. Zawsze jest tak, że r1 == r2.

Uzasadnienie tego wymogu wyjaśniono w tym samym akapicie:

Idealnie byłoby, gdyby opakowanie danej pierwotnej wartości p zawsze dawało identyczne odniesienie . W praktyce może to być niewykonalne przy użyciu istniejących technik wdrożeniowych. Powyższe zasady to pragmatyczny kompromis. Ostatnia klauzula powyżej wymaga, aby pewne wspólne wartości były zawsze opakowane w nierozróżnialne obiekty. […]

Zapewnia to, że w większości przypadków zachowanie będzie pożądane, bez narzucania nadmiernej utraty wydajności, szczególnie na małych urządzeniach . Implementacje z mniejszą ilością pamięci mogą na przykład buforować wszystkie wartości char i short, a także wartości int i long w zakresie od -32K do + 32K.

Jak mogę buforować inne wartości spoza tego zakresu.?

Możesz użyć -XX:AutoBoxCacheMaxopcji JVM, która nie jest tak naprawdę udokumentowana na liście dostępnych opcji JVM Hotspot . Jest to jednak wspomniane w komentarzach wewnątrz Integerklasy wokół wiersza 590 :

Rozmiar pamięci podręcznej można kontrolować za pomocą -XX:AutoBoxCacheMax=<size>opcji.

Należy pamiętać, że jest to specyficzne dla implementacji i może, ale nie musi być dostępne w innych maszynach JVM.

-128 do 127 to rozmiar domyślny. Ale javadoc mówi również, że rozmiar pamięci podręcznej Integer może być kontrolowany przez -XX:AutoBoxCacheMax=<size>opcję. Zauważ, że ustawia tylko wysoką wartość, niska wartość to zawsze -128. Ta funkcja została wprowadzona w wersji 1.6.

Co do tego, dlaczego od -128 do 127 - jest to zakres wartości bajtów i naturalne jest użycie go dla bardzo małej pamięci podręcznej.

Powodem buforowania małych liczb całkowitych, jeśli o to pytasz, jest to, że wiele algorytmów używa małych liczb całkowitych w swoich obliczeniach, więc unikanie narzutu tworzenia obiektów dla tych wartości wydaje się być opłacalne.

Powstaje wtedy pytanie, które liczby całkowite mają być buforowane. Ponownie, mówiąc ogólnie, częstotliwość, z jaką używane są wartości stałe, ma tendencję do zmniejszania się wraz ze wzrostem wartości bezwzględnej stałej - wszyscy spędzają dużo czasu na wartościach 1, 2 lub 10, stosunkowo niewielu bardzo używa wartości 109 intensywnie; mniej będzie miało wydajność zależną od tego, jak szybko można uzyskać liczbę całkowitą dla 722. Java zdecydowała się przydzielić 256 przedziałów obejmujących zakres wartości bajtu ze znakiem. Decyzja ta mogła zostać oparta na analizie programów istniejących w tamtym czasie, ale równie prawdopodobne jest, że była to decyzja czysto arbitralna. Jest to rozsądna ilość miejsca do zainwestowania, można uzyskać do niej szybki dostęp (maska, aby dowiedzieć się, czy wartość mieści się w zakresie pamięci podręcznej, a następnie szybkie wyszukiwanie w tabeli, aby uzyskać dostęp do pamięci podręcznej) i na pewno obejmie najczęstsze przypadki.

Innymi słowy, myślę, że odpowiedź na twoje pytanie brzmi: „nie jest tak subiektywne, jak myślałeś, ale dokładne granice są w dużej mierze decyzją opartą na regułach ... a eksperymentalne dowody wskazują, że było wystarczająco dobre. "

Maksymalną wartość całkowitą, która może być buforowana, można skonfigurować za pomocą właściwości systemowej, tj. java.lang.Integer.IntegerCache.high( -XX:AutoBoxCacheMax). Pamięć podręczna jest implementowana przy użyciu tablicy.

    private static class IntegerCache {
    static final int high;
    static final Integer cache[];

    static {
        final int low = -128;

        // high value may be configured by property
        int h = 127;
        if (integerCacheHighPropValue != null) {
            // Use Long.decode here to avoid invoking methods that
            // require Integer's autoboxing cache to be initialized
            int i = Long.decode(integerCacheHighPropValue).intValue();
            i = Math.max(i, 127);
            // Maximum array size is Integer.MAX_VALUE
            h = Math.min(i, Integer.MAX_VALUE - -low);
        }
        high = h;

        cache = new Integer[(high - low) + 1];
        int j = low;
        for(int k = 0; k < cache.length; k++)
            cache[k] = new Integer(j++);
    }

    private IntegerCache() {}
}

Kiedy napotkasz klasę Integer i zawsze masz ramkę w zakresie od -128 do 127, zawsze lepiej jest przekonwertować obiekt Integer na wartość int, jak poniżej.

<Your Integer Object>.intValue()