Discussion :

[bredelet]

Ce n'est pas une raison de performance : si la clef n'est pas immuable on risque de ne plus pouvoir accéder à sa valeur.

Les données sont stockés selon le hashCode de la clef.
Si tu modifies la valeur de la clef après l'avoir inséré, son hashCode ne correspondra plus et tu ne pourra plus accéder à la valeur via get().

Ce n'est pas spécifique à la ConcurrentHashMap mais commun à la majorité des Map qui ont quasi toute le même mécanisme basé sur le hashCode...


a++

Je comprends bien, et c'est pourquoi j'étais intrigué par la remarque "Pour des raisons de performance, il est très fortement conseillé d'utiliser des objets immutables pour la clé."

Peut-être que la hashmap a moyen de contourner ça au prix d'un peu de performance ?

[Invité]

Bonjour bredelet,

adiGuba décrit très bien le problème avec les objets mutables. Je t’encourage très fortement à ne jamais utiliser ce type d’objet comme clé. Ça va forcément générer des bugs dans tes applications. Il a raison sur ce point, pas besoin de parler de performances pour ces objets.


Il a quelques considérations à prendre en compte quand tu utilises des objets immuables sur les performances.

L’intérêt de la table de hachage est d’accéder de manière quasi immédiate à une valeur à partir de sa clé. Les implémentations de Map sont basées comme cités ci-dessus sur un mécanisme basé sur le hash code de la clé. Le calcul du hash code est coûteux dans ces structures de données, elle passe leur temps à calculer des hash code. Pour cette raison, il est primordial d’utiliser des objets immuables dont le calcul du hash code est rapide.
Certaines classes du JDK sont de bonnes candidates pour être des clés :

• Integer : le hash code de l’entier est l’entier lui-même
• String : le hash code est réalisé sur un calcul de chaque caractère de la chaîne (coûteux). Le hash code est mis en cache lors du premier calcul de celui-ci.

Ci-dessous le code source de la méthode hashCode() de String.
La variable d’instance "hash" permet la mise en cache de ce hash code.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
public int hashCode() {
        int h = hash;
        if (h == 0 && value.length > 0) {
            char val[] = value;
 
            for (int i = 0; i < value.length; i++) {
                h = 31 * h + val[i];
            }
            hash = h;
        }
        return h;
    }

Les objets immuables ne changent pas avec le temps, on a seulement besoin de calculer une seule fois ce hash code. Il est primordial de stocker ce hash code en cache quand l’objet est utilisé comme clé d’un HashMap ou ConcurrentHashMap, surtout lorsque celui-ci est très coûteux à calculer. Ne pas mettre en cache le hash code des clés va forcément entrainer des non-performances dans l’utilisation de votre table de hachage. Les dégradations des performances seront de plus en plus importantes au fur et à mesure de la taille et de l’utilisation de la table.

Utilisez de préférences des classes telles que Integer ou String comme clé. Si vous utilisez des objets immuables, pensez à bien mettre en cache le hash lors du premier calcul.

Julien.