Dlaczego funkcja Object.hashCode() zwraca tę samą wartość w różnych przebiegach

Question

Domyślna implementacja hashCode() na HotSpot zwraca wartość random value i zapisuje ją w nagłówku obiektu. To wydaje się nie zmieniły w Java 8 gdzie wartość hash oblicza się poprzez wywołanie os::random():

static inline intptr_t get_next_hash(Thread * Self, oop obj) { 
    intptr_t value = 0 ; 
    if (hashCode == 0) { 
    // This form uses an unguarded global Park-Miller RNG, 
    // so it's possible for two threads to race and generate the same RNG. 
    // On MP system we'll have lots of RW access to a global, so the 
    // mechanism induces lots of coherency traffic. 
    value = os::random() ; 
    } else 
... 

Zastanawiam się dlaczego hashCode() stale zwraca taką samą wartość, również po wyłączeniu JVM które próbowałem poprzez wykonanie prostego testu poniżej, ponowne uruchomienie komputera i ponowne uruchomienie main().

public class SimpleTest { 
    public static void main(String[] args) { 
    Object obj = new Object(); 
    // This calls toString() which calls hashCode() which calls os::random() 
    System.out.println(obj); 
    } 
} 

Jak wyjście być taka sama za każdym razem, gdy hashCode() jest rzeczywiście os::random()?

---

java -version daje

java version "1.8.0_40" 
Java(TM) SE Runtime Environment (build 1.8.0_40-b25) 
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) 

_Uwaga:

_{Gdyby ktoś zapytać się co System.out.println(obj);, który nazywa obj.toString() jeśli obiekt jest niezerowe i produkuje coś java.lang.Object@659e0bfd, musi z hashCode(): Część po @ jest kodem mieszania obiektu w szesnastkowy (i nie ma związku z lokalizacją obiektu w pamięci, contrary do tego, co sugeruje dokumentacja, co doprowadziło do misunderstandings).}

Answer 1

Aby odpowiedzieć na to pytanie, musimy najpierw zadać pytanie wtórnego, „Dlaczego os::random() zaszczepiono stałym seed?”

Jak sugerował @DavidSchwartz, posiadanie "losowego" generatora liczb ze stałym nasieniem jest bardzo użyteczne, ponieważ daje arbitralne, ale deterministyczne zachowanie. Programiści JVM mogą zadzwonić pod numer os::random() i nadal wiedzą, że zachowanie JVM nie zależy od czynników zewnętrznych. Wśród innych korzyści oznacza to, że testy JVM są powtarzalne; użycie "prawidłowo" zaszczepionego RNG mogłoby utrudnić odtworzenie awarii związanych z RNG.

Teraz możemy odpowiedzieć na oryginalne pytanie, przeformułowane jako "Dlaczego wdrożenie HotSpot Object.hashCode() używa os::random()?"

Odpowiedź na to pytanie jest prosta, ponieważ jest prosta i działa. Hasła hasłowe muszą być dobrze rozłożone, coś, co zapewnia RNG. Najprostszym, najbardziej dostępnym RNG w tym obszarze JVM jest os::random(). Ponieważ Object.hashCode() nie daje żadnych gwarancji co do źródła tych wartości, nie ma znaczenia, że ​​os::random() nie jest w ogóle losowy.

Zauważysz, że jest to tylko jeden z możliwych strategii mieszania, kilka innych są zdefiniowane (i wybrany przez hashCode globalny), w tym jedno, które będą „likely make ... the default in future releases.”

Ostatecznie, jest to tylko szczegół realizacja . Po prostu nie ma potrzeby bardziej agresywnej randomizacji Object.hashCode() i jest całkiem możliwe, że inne maszyny JVM nie robią tego w ten sposób, lub inne systemy operacyjne zachowują się inaczej. W rzeczywistości w Eclipse widzę różne kody skrótu podczas wielokrotnego uruchamiania kodu. Ponadto, umowa o Object.hashCode() sugeruje, że typowe implementacje JVM nie wdrażają Object.hashCode() ten sposób na wszystkich:

Jest to zazwyczaj realizowane poprzez przekształcenie wewnętrzny adres obiektu do liczby całkowitej

---

Należy również zauważyć, że Twój test sprawdza tylko, czy pierwsze połączenie z jest zgodne. W jakimkolwiek programie wielowątkowym nie można oczekiwać takiego zachowania. Nie polega również na niczym innym w JVM wywoływania os::random() podczas wykonywania, co może zrobić w dowolnym momencie (na przykład, jeśli śmieciarz opiera się na os::random() wyniku wywołań .hashCode() po tym, jak pierwsza GC będzie niedeterministyczna).

Answer 2

Zachowanie deterministyczne ułatwia kodowanie debugowania, ponieważ można go replikować. Tak więc implementacje zwykle wybierają to, o ile to możliwe. Wyobraź sobie, jak trudno byłoby replikować niektóre testy jednostkowe, które nie powiodły się z powodu niewłaściwego zderzenia mieszania (powiedzmy, po skrócie skrótu), jeśli skróty były różne za każdym razem.

Answer 3

Nie ma żadnej korzyści z posiadania różnych wartości między wykonaniami. W rzeczywistości zwiększa szansę na trudne do odtworzenia błędy.

Ważne jest to, że prawdopodobieństwo, że dwa obiekty mają ten sam kod hash, jest niskie podczas jednego wykonania.

Jeśli ktoś znalazł materiał siewny, którego rezultatem jest seria wartości, które trwają długo, aby wytworzyć powtórzenie (lub długą serię z bardzo małą liczbą powtórzeń), wtedy warto zacząć od tego za każdym razem.

Nie sprawdziłem źródła Hotspot, aby stwierdzić, czy podjęto pewne starania, aby wybrać "dobre" ziarno. Chodzi o to, że celem jest dobre rozproszenie. Losowość nie jest wymagana, a wariancja od wykonania do wykonania jest co najwyżej bezużyteczna, w najlepszym razie niepomocna.