Java: cartes multithread: comment les implémentations se comparent-elles?

Question

Je suis à la recherche d'une bonne implémentation de la carte de hachage. Plus précisément, c'est un bon outil pour créer un grand nombre de cartes, la plupart petites. Donc, la mémoire est un problème. Il devrait être sûr pour les threads (bien que perdre le set impair soit un bon compromis en échange d'une meilleure performance), et rapide pour les deux get et put. Et j'aimerais aussi la lune sur un bâton, s'il vous plaît, avec un ordre de justice.

Les options que je connais sont:

• HashMap. Désastreusement un thread-safe.

• ConcurrentHashMap. Mon premier choix, mais cela a une empreinte mémoire lourde - environ 2k par instance.

• Collections.sychronizedMap (HashMap). Cela fonctionne bien pour moi, mais je suis sûr qu'il doit y avoir des alternatives plus rapides.

• Trove ou Colt - Je pense que ni l'un ni l'autre n'est thread-safe, mais peut-être que le code pourrait être adapté pour être thread-safe.

D'autres? Un conseil sur ce qui bat quoi quand? De très bons nouveaux algorithmes de carte de hachage que Java pourrait utiliser une implémentation?

Merci d'avance pour votre contribution!

Answer 1

Eh bien, il y a un Colt rehaussé chez Apache Mahout. Ce n'est toujours pas dans les affaires courantes. Quel est le problème avec la protection du code avec un bloc synchronisé? Vous attendez-vous à un système diaboliquement complexe qui contient des verrous pour une granularité plus petite que put ou get?

Si vous pouvez en coder un, merci de le signaler à Mahout.

Answer 2

Il est intéressant de jeter un coup d'œil aux cartes de hachage persistantes de Clojure.

Il s'agit de structures de données stables, stables au thread, avec des performances comparables à celles des Java HashMaps classiques. Vous devez évidemment les envelopper si vous voulez une carte modifiable, mais cela ne devrait pas être difficile.

http://clojure.org/data_structures

Answer 3

Collections.synchronizedMap() fait simplement toutes les méthodes Mapsynchronized.

ConcurrentMap est vraiment l'interface que vous voulez et il existe plusieurs implémentations (par exemple ConcurrentHashMap, ConcurrentSkipList). Il a plusieurs opérations que Map ne sont pas importantes pour les opérations threadsafe. De plus, il est plus granulaire qu'un Map synchronisé, car une opération ne verrouille qu'une tranche de la structure de données de sauvegarde plutôt que la totalité.

Answer 4

Je n'ai aucune expérience de ce qui suit, mais j'ai travaillé avec un projet qui a juré par Javolution pour les tâches sensibles en temps réel et sensibles à la mémoire.

Je remarque dans l'API FastMap qui prétend être thread-safe.Comme je le dis, je n'ai aucune idée si c'est tout bon pour vous, mais vaut le détour:

API for FastMap

Javolution Home

Answer 5

Google Collection « s MapMaker semble comme il peut faire le travail aussi.

Answer 6

Très surprenant qu'il ait une empreinte de 2k pieds !! Pourquoi ne pas réduire le paramètre de concurrence de ConcurrentHashMap (par exemple 2-3) et optimiser sa taille initiale (= rendre plus petit).

Je ne sais pas d'où vient cette consommation de mémoire, mais peut-être que cela a quelque chose à voir avec le maintien des verrous à rayures. Si vous réduisez le paramètre de concurrence, il aura moins.

Si vous voulez de bonnes performances avec une sécurité de filetage prête à l'emploi, ConcurrentHashMap est vraiment sympa.