E 'una buona pratica per avvolgere ConcurrentHashMap lettura e operazioni di scrittura con ReentrantLock?

Question

Credo che nella realizzazione di ConcurrentHashMap, ReentrantLock è già stato utilizzato. Quindi non v'è alcuna necessità di utilizzare ReentrantLock per l'accesso di un oggetto ConcurrentHashMap. E che solo aggiungere di più la sincronizzazione in testa. Eventuali commenti?

Answer 1

Cosa vuoi (o nessuno) come di ottenere con questo? ConcurrentHashMap è già thread-safe come è. Avvolgendolo con il codice di blocco in più sarebbe solo rallentare in modo significativo, in quanto

1. non si blocca sulla legge di per sé,
2. anche per scritture, difficilmente si può imitare il suo comportamento interno di blocco partizionamento esternamente.

In altre parole, l'aggiunta di bloccaggio supplementare aumenterebbe la probabilità di filo contesa significativamente (oltre a rendere le garanzie di sicurezza filo di operazioni di lettura più severe, per il record).

  

ConcurrentHashMap fornisce un'implementazione di ConcurrentMap e offre una soluzione altamente efficace al problema di conciliare produttività con sicurezza thread. E 'ottimizzato per la lettura, in modo da non bloccare recuperi anche quando il tavolo è in fase di aggiornamento (per consentire ciò, gli stati del contratto che i risultati di recuperi saranno riflettere le ultime operazioni di aggiornamento completati prima dell'inizio del recupero). Aggiornamenti anche spesso possono procedere senza bloccare, perché un ConcurrentHashMap consiste nel non uno ma una serie di tabelle, denominati segmenti, ciascuno dei quali può essere bloccato in modo indipendente. Se il numero di segmenti è abbastanza grande rispetto al numero di fili di accesso a tavolo, ci sarà spesso non più di un aggiornamento in corso per segmento in qualsiasi momento.

Da Java Generics e collezioni, il capitolo 16.4.

Answer 2

Il punto di ConcurrentHashMap, non è lock attorno accesso / modifiche. bloccaggio Extra aggiunge solo in testa.