Historique : Avant Java 8, l'accumulation concurrente reposait sur AtomicLong, dont un seul emplacement mémoire est devenu un goulet d'étranglement de scalabilité sous contention de threads en raison d'une invalidation excessive des lignes de cache à travers les cœurs CPU. LongAdder a été introduit dans le cadre du paquet java.util.concurrent.atomic pour résoudre ce problème grâce à une technique inspirée par l'algorithme Striped64, partitionnant dynamiquement les opérations d'écriture à travers plusieurs cellules rembourrées.
Problème : Lorsque de nombreux threads tentent simultanément des opérations CAS sur un AtomicLong partagé, chaque échec déclenche une diffusion de cohérence de cache qui sériel le trafic mémoire et dégrade l'augmentation du débit exponentiellement avec le nombre de cœurs. Ce phénomène, connu sous le nom de rebond de ligne de cache, empêche la scalabilité linéaire même sur des tâches autrement embarrassantes à paralléliser.
Solution : LongAdder tente d'abord d'effectuer des mises à jour sur un seul champ base en utilisant CAS ; ce n'est qu'en détectant une contention—spécifiquement lorsqu'un thread échoue à acquérir le verrou de base après une séquence de sondage probabiliste (généralement mise en œuvre par un compteur de collision et un hachage local au thread dans Striped64)—qu'il alloue paresseusement un tableau d'objets Cell annotés avec @Contended. Chaque thread hache ensuite vers une cellule distincte, effectuant des additions non contestées sur des lignes de cache isolées, tandis que la méthode sum() agrège paresseusement ces valeurs uniquement lorsqu'un instantané cohérent est requis.
Une plateforme de trading à haute fréquence nécessitait un compteur global pour valider le débit des ordres sur une installation à 64 cœurs, initialement mise en œuvre à l'aide de AtomicLong. Lors des pics de volatilité du marché, le système a montré une dégradation de latence non linéaire où le temps de réponse au 99ème percentile a été multiplié par dix, le profilage a révélé que 40 % des cycles CPU étaient gaspillés sur des protocoles de cohérence de cache en concurrence pour l'adresse mémoire unique du compteur.
L'équipe d'ingénierie a envisagé trois solutions architecturales. Tout d'abord, ils ont évalué une carte de compteur local au thread manuelle où chaque thread maintenait un AtomicLong indépendant dans un ConcurrentHashMap, agrégé périodiquement par un rapporteur de fond ; bien que cela ait éliminé la contention, cela a introduit un surcoût mémoire significatif par thread et une gestion de cycle de vie complexe lors du redimensionnement de la piscine de threads, risquant des fuites de mémoire dans les exécuteurs à long terme. Deuxièmement, ils ont prototypé une stratégie de partitionnement personnalisée utilisant un tableau de 64 instances AtomicLong indexées par Thread.currentThread().getId() % 64 ; cela a réduit le trafic de cache mais souffrait d'une distribution inégale lorsque les pools de threads réutilisaient les ID et nécessitait une gestion manuelle du redimensionnement du tableau lors de la croissance du trafic, ajoutant une charge de maintenance fragile. Troisièmement, ils ont évalué la migration vers LongAdder, qui offrait un rayonnement dynamique intégré avec un rembourrage automatique @Contended pour prévenir le partage faux, bien qu'au prix du fait que les opérations de lecture retournaient des approximations faiblement cohérentes plutôt que des valeurs atomiques exactes.
L'équipe a finalement sélectionné LongAdder car l'exigence commerciale tolérait des valeurs de lecture légèrement obsolètes pour les tableaux de bord de surveillance, tandis que le chemin de validation lourd d'écritures exigeait un débit maximum. L'heuristique d'expansion automatique des cellules garantissait qu'en période de faible trafic, l'objet restait léger (champ de base unique), tandis qu'une forte contention déclenchait une mise à l'échelle transparente à travers des cellules rembourrées. Après le déploiement, la latence s'est stabilisée, avec un débit se déplaçant linéairement jusqu'à 64 cœurs alors que le trafic d'invalidation de cache se répartissait à travers des régions mémoire distinctes plutôt que de se concentrer sur un seul point chaud.
Question : Pourquoi le sondage fréquent de LongAdder.sum() dans une boucle serrée peut-il potentiellement annuler les avantages de performance du rayonnement, et quelles garanties de cohérence cette méthode fournit-elle ?
Réponse : La méthode sum() doit parcourir le champ base et chaque Cell active dans le tableau pour calculer un total, nécessitant des barrières mémoire qui déclenchent une synchronisation de cohérence de cache à travers tous les cœurs participants ; par conséquent, des charges de travail continues lourdes en lecture sériel efficacement les écritures rayées et réintroduisent la contention que LongAdder a été conçu pour éviter. En outre, sum() n'offre qu'une cohérence faible, retournant une valeur exacte uniquement au moment de l'invocation sans garanties d'atomicité par rapport aux mises à jour concurrentes, ce qui signifie que le résultat peut représenter un état transitoire où certaines incréments de threads sont visibles tandis que d'autres ne le sont pas.
Question : Comment l'annotation @Contended à l'intérieur de la classe interne Cell de LongAdder prévient-elle le partage faux, et quel drapeau JVM régit ce comportement de rembourrage ?
Réponse : @Contended ordonne au compilateur HotSpot d'injecter 128 octets (ou la valeur spécifiée par -XX:ContendedPaddingWidth) de rembourrage autour du champ value au sein de chaque Cell, garantissant que les éléments de tableau adjacents résident sur des lignes de cache distinctes indépendamment des optimisations de mise en page d'objet. Sans ce rembourrage, des cellules séquentielles partageraient une ligne de cache de 64 octets, causant des écritures sur une cellule à invalider les copies mises en cache des voisines dans d'autres cœurs et réintroduisant le rebond de cache ; les candidats négligent souvent que cette annotation est réservée aux classes internes du JDK à moins que -XX:-RestrictContended ne soit explicitement désactivé pour permettre l'exploitation du code utilisateur.
Question : Dans quelles circonstances spécifiques LongAdder afficherait-il des performances inférieures à celles de AtomicLong, et comment l'implémentation de longValue() influence-t-elle ce risque ?
Réponse : LongAdder engendre des coûts d'allocation pour son tableau de Cell et la logique de calcul de hachage même lors d'une exécution à un seul thread sans contention, rendant AtomicLong supérieur pour les scénarios de faible contention ou les compteurs mis à jour exclusivement par un thread. De plus, longValue() délègue directement à sum(), ce qui signifie que tout chemin de code vérifiant continuellement la valeur du compteur—comme un algorithme de verrouillage de rotation ou de contre-pression—force une agrégation globale répétée qui synchronise toutes les lignes de cache, transformant effectivement la structure rayée en un singleton en contention et détruisant la scalabilité.