Ci sono degli svantaggi con ConcurrentHashMap?

Question

Ho bisogno di un HashMap che è accessibile da più thread.

Ci sono due opzioni semplici, utilizzando una HashMap normale e la sincronizzazione su di esso o utilizzando un ConcurrentHashMap.

Dato ConcurrentHashMap non blocca su operazioni di lettura sembra molto più adatto per le mie esigenze (si legge quasi esclusivamente, quasi mai gli aggiornamenti). D'altra parte, mi aspetto molto bassa concorrenza comunque, quindi non ci dovrebbero essere di blocco (solo il costo di gestione della serratura).

La mappa sarà anche molto piccole (sotto i dieci iscrizioni), se questo fa la differenza.

Rispetto ad un HashMap regolare, quanto più costose sono le operazioni di lettura e scrittura (io parto dal presupposto che essi sono)? O è solo ConcurrentHashMap sempre meglio quando ci potrebbe essere anche un livello moderato di accesso simultaneo, a prescindere dal rapporto di lettura / aggiornamento e le dimensioni?

Answer 1

  

D'altra parte, mi aspetto molto bassa concorrenza comunque, quindi non ci dovrebbe essere nessun blocco (solo il costo di gestione della serratura).

Il costo di acquisizione e rilasciando un uncontend Java mutex (lock primitivo) è minuscolo. Quindi, se si ritiene che la probabilità di contesa è molto bassa quindi un semplice HashMap è probabilmente la soluzione migliore.

Ma questo è tutto congetture. A meno che e fino a quando si è effettivamente profilata l'applicazione, tutto il tempo speso per l'ottimizzazione speculativa è più probabile (*) tempo sprecato.

^{* ... a meno che non si dispone di una davvero un buon intuito.}

Answer 2

CHM paga un po 'di pena per l'uso di Atomic * operazioni sotto le coperte, se confrontato con HashMap. Quanto? Indovinate un po '... misurarlo nella vostra applicazione ...; -)

Se si scopre che in realtà hanno un problema di prestazioni, c'è probabilmente una soluzione molto specializzato per <10 voci che sarebbe più conveniente rispetto a qualsiasi soluzione assemblato fuori del territorio java.util, ma non mi sarei saltare a che finché non si sa di avere un problema di prestazioni.

Answer 3

In termini di produttività e prestazioni, il sovraccarico è generalmente trascurabile.

Una nota diversa, l'occupazione di memoria di un ConcurrentHashMap (a livello di istanza) è leggermente più grande di una HashMap. Se si dispone di un gran numero di piccole dimensioni CHMs, questo overhead potrebbe aggiungere.

Answer 4

Il problema principale w / CHM:. Non scala bene a meno che non si cambia la chiamata c-tor ma soprattutto non scala automaticamente per i core disponibili

3 link qui sotto per lock-libera hashmap
http://www.azulsystems.com/blog / scogliera-click / 2007-03-26-non-blocking-tabella hash
http: //www.azulsystems .com / blog / scogliera-click / 2007-04-01-non-blocking-tabella hash-parte-2
http://sourceforge.net/projects/high-scale-lib/