L'utilizzo di ConcurrentHashMap elimina problemi di data-visibilità?

Question

Ho letto attraverso Java Concurrency in Practice e sono rimasto con questa domanda: quando uso un ConcurrentHashMap , quali problemi di concorrenza dati discussi nella prima parte del libro non ho ancora bisogno di preoccuparsi? Qui ci sono un paio di esempi da uno dei miei programmi:

1. posizione corrente di un commerciante (un intero comune dove 'integer' è il termine matematico)

Questo numero rappresenta ciò che un oggetto trader attualmente possiede e definisce il suo stato. Si deve leggere la sua posizione per sapere cosa fare (guardare per iniziare una nuova posizione, o il gestore di quella attuale). metodi Trader eseguiti per conto proprio thread.

Un oggetto broker ha il compito di impostare la posizione del trader. Sarà impostare la posizione ogni volta che uno degli ordini del commerciante è pieno. Metodi Broker eseguiti sul loro proprio thread.

Sia il trader e broker sono nello stesso pacchetto. Posizione è implementato come un pacchetto di static ConcurrentHashMap-privato. I tasti sono di id degli oggetti commerciante. I valori sono interi.

esterno al pacchetto è l'applicazione. Ottiene le posizioni dei commercianti indirettamente con un getter pubblico.

Posizioni cambierà al massimo una volta ogni pochi minuti, in modo che il broker non toccherà la mappa molto spesso. Tuttavia, l'trader e l'applicazione frequentemente leggere. Inoltre abbiamo spesso parecchi commercianti che leggono la mappa contemporaneamente.

Quindi, utilizzando un ConcurrentHashMap in questo modo, non ho al lavoro sul blocco e visibilità dei dati? Il ConcurrentHashMap si occupa di tutto?

2. Il mercato (denaro, lettera, i prezzi ultimi)

Più o meno la stessa situazione come la posizione, solo che adesso il broker sarà molto frequentemente aggiornare i prezzi (fino a 10 aggiornamenti al secondo durante periodi di calca; normalmente un paio di volte al secondo). Il trader e l'applicazione ancora fare frequenti letture. Le chiavi della mappa ora sono codici che indicano che azioni o futura, ed i valori sono oggetti che tengono i prezzi di mercato.

Sembra funzionare bene, ma dopo aver letto JCIP, mi rendo conto il programma può ancora essere rotto se le cose non vengono implementate correttamente. Il libro parla della ConcurrentHashMap ma non mi dice esplicitamente quali sono le questioni da parte I non abbiamo più a indirizzo manualmente. E ' appare che io non devo synchronize nulla in questo caso. E 'corretto?

Answer 1

Quindi, utilizzando un ConcurrentHashMap in questo modo, Io non devo lavorare sul blocco e Dati visibilità? il ConcurrentHashMap si prende cura di tutto?

Questo dipende da ciò che è nella mappa, se leggo il vostro esempio correttamente gli sguardi situazione come questa

static final ConcurrentMap<Integer,Integer> map = ...

class Trader{

  public int doRead(){
      map.get(someId);
   }
}
class Broker{
   public void doWrite(){
      map.put(someId,someValue);
   }
}

Se questo è il caso, allora sì tutta la concorrenza è curato.

Tuttavia, se gli sguardi mappa come

static final ConcurrentMap<Integer,Trader> map = ..

    class Broker{
       public void doWrite(){
          map.get(someId).setPosition(somePosition);
       }
    }

Questo non è thread-safe, anche se le serrature ConcurrentHashMap quando si mette, tutto l'accesso contemporaneo di oggetti a questo punto devono gestire la propria sincronizzazione.

Answer 2

Sì, ConcurrentHashMap si prende cura di visibilità e di bloccaggio finché:

• I valori detenuti dalla mappa sono immutabili. Sembra essere vero nella tua descrizione, dato che i prezzi degli oggetti sono immutabili;
• non devi operazioni su carta che deve essere atomica e non possono essere espresse come singole chiamate a API di mappa. Per esempio, se avete bisogno di un'operazione come 'valore letto dalla mappa, eseguire calcoli, e mettere la schiena risultato sulla mappa' essere atomico, è ancora necessario mantenga il blocco esplicito durante questa operazione, o, meglio ancora, l'applicazione di modifiche in modo che solo utilizzare le operazioni atomiche di mappa API come get/put/putIfAbsent.

Answer 3

A meno che non si sta parlando di oltre 100.000 aggiornamenti / legge al secondo non vorrei considerare l'utilizzo di più thread. La ragione è che i componenti thread-safe assumere molte volte più lungo di componenti che non sono. Quindi, se un introito componente 5x più tempo per essere thread-safe, è necessario utilizzare più di 5 discussioni in concomitanza al pareggio, non importa andare più veloce.

Più thread sono molto più utile quando si dispone di operazioni relativamente costose da eseguire. Aggiornamento di una posizione o prezzo è molto più efficiente come un thread.