Perché viene generato un codice hash Java stringa pigro?

Question

Appare in java.lang.String.java, che Java genererà solo l'hashcode e quindi lo memorizzerà dopo una chiamata a hashcode(), ma perché non creare semplicemente l'hashcode nel costruttore?

Il codice rilevante:

if (h == 0 && count > 0) { 
    int off = offset; 
    char val[] = value; 
    int len = count; 

    for (int i = 0; i < len; i++) { 
     h = 31*h + val[off++]; 
    } 

    hash = h; 
} 

potrebbe in gran parte essere collocato nel costruttore.

Answer 1

Perché trascorrere del tempo generando un codice hash che molto probabilmente non verrà utilizzato? La maggior parte delle stringhe viene costruita, utilizzata e quindi raccolta dei dati inutili senza che hashcode() venga mai chiamata.

Answer 2

Questo non è il forum corretto per questo e la domanda sarà probabilmente chiusa. Puoi provare a chiedere in programmers.stackexchange.com.

Uno dei motivi potrebbe essere che l'hashCode di elaborazione non è economico ed è richiesto solo in alcuni casi.

Answer 3

Joshua Bloch chiama questa pratica "racy single-check".

Jeremy Manson ha un'ottima spiegazione del perché è fatto e perché it'safe: on his blog

In sostanza, in tempi di costruzione di risparmiare un po 'di tempo saltando calcolo codice hash. Nell'ambiente multithreaded pagherai per questo motivo perché thread multipli potenzialmente potrebbero fare lo stesso calcolo.

Answer 4

2 motivi:

1) Informatica hashCode() non è a buon mercato: è un O(n) complessità della lunghezza della stringa, quindi meglio farlo solo quando bisogno.

e:

2) istanze String sono immutabili: Dal momento che non cambiano mai, si calcola sempre hashCode() al massimo una sola volta.

Answer 5

Non è previsto alcun vantaggio quando viene inserito nel costruttore. Ma c'è un aspetto negativo quando sarebbe nel costruttore. Quando hashCode for a String non viene mai chiamato, il calcolo è stato fatto per niente. E quando chiami hashCode(), viene calcolato una volta in entrambi i casi, solo in luoghi e tempi diversi.