Perché il Netty avere un proprio ConcurrentHashMap?
Domanda
Ho notato che Netty ha qualche utilità HashMap concorrenti interni. Sono curioso di sapere perchè Netty non utilizza il ConcurrentHashMap che è costruito in Java Nucleo. È l'implementazione Netty meglio, in qualche modo, o ha alcune nuove funzionalità? Sto lavorando su un progetto che ha bisogno di un concomitante HashMap e sto discutendo se devo usare l'attuazione Netty, ma non riesco a vedere alcuna differenza nel codice sorgente.
Soluzione
ConcurrentHashMap
non esisteva fino JSR-166 , che è stato rilasciato in Java 5 come il pacchetto java.util.concurrent
.
Netty non include la propria ConcurrentHashMap
perché è superiore - in realtà, è certamente solo una copia di JSR-166 - è in modo che possano funzionare su Java 1.4.
Per i propri progetti, si dovrebbe utilizzare java.util.concurrent.ConcurrentHashMap
se si può prendere una dipendenza da Java 5. E se non è possibile, allora si dovrebbe solo includerlo nel vostro prodotto (e cambiare il nome del pacchetto in modo che doesn' t conflitto con progetti inclusi del runtime Java 5.) Ogni volta che è possibile ottenere Doug Lea o Brian Goetz per scrivere il codice thread-safe per voi, probabilmente dovrebbe.
Altri suggerimenti
ConcurrentHashMap di Netty è in realtà buggy; non è threadsafe.
ho scoperto che di recente. Si può dimostrare che con un semplice test.
Abbiamo avuto: Thread1 loop over map.values ??(). flusso (). ordinate (). FindFirst () Thread2 concurrenly mettere / rimuovere dalla mappa.
In base alla progettazione di qualsiasi forma di iterazione dovrebbe non riflettono necessariamente la mappa, ma non dovrebbe mai mancare con ArrayIndexOutOfBoundsException in qualche codice profonda e oscura meno che la versione Netty incasinato i dati della mappa, mentre il JDK flussi roba si basa su di esso.