Le Modèle de Mémoire Java (JMM) garantit qu'une fois qu'un constructeur se termine, les écritures sur les champs final deviennent visibles pour tout thread qui lit la référence de l'objet, à condition que cette référence n'ait pas échappé pendant la construction. Si la référence this fuit prématurément—en étant passée à un autre thread ou stockée dans une collection statique avant le retour du constructeur—le lien happens-before entre l'écriture du constructeur dans le champ final et la lecture du thread d'un autre est rompu. Par conséquent, le thread observateur peut témoigner de la valeur par défaut (zéro, faux ou null) au lieu de la valeur construite, rompant ainsi l'immuabilité apparente. La publication sécurisée nécessite qu'aucune référence à l'objet en construction n'échappe jusqu'à ce que la construction soit terminée, garantissant que l'action de gel sur les champs final se produise avant qu'un thread puisse charger la référence.
Nous avons rencontré cela dans un système de trading haute fréquence où des instances de Service s'enregistraient dans un ConcurrentHashMap global pendant leurs constructeurs pour faciliter la recherche. La classe définissait un final long instrumentId, initialisé à partir d'un paramètre de constructeur, mais les threads de surveillance lisaient sporadiquement zéro lors de la requête du registre immédiatement après la création.
Une solution proposée était de déclarer instrumentId comme volatile au lieu de final, espérant forcer une visibilité immédiate entre les cœurs. Cette approche garantissait l'atomicité et la visibilité mais renonçait au contrat d'immuabilité et entraînait un coût de barrière mémoire complet à chaque lecture, dégradant inutilement le débit pour une valeur qui ne changeait jamais après la construction et compliquant le raisonnement sur l'état de l'objet.
Une autre suggestion impliquait de synchroniser tous les accès au registre avec des blocs synchronized encapsulant la logique du constructeur, théorisant que le verrouillage viderait les caches mémoire. Bien que cela ait empêché les conditions de concurrence, cela a introduit une forte contention sur le verrou du registre global, transformant une structure concurrente en un goulet d'étranglement séquentiel et violant les exigences strictes de latence pour l'ingestion de données de marché.
Nous avons choisi un modèle de fabrique qui découplait l'instanciation de l'enregistrement. Le constructeur est resté privé, la méthode de fabrique a appelé new Service(id) complètement, et ce n'est qu'ensuite que la référence entièrement formée a été publiée dans le ConcurrentHashMap. Cela a tiré parti de la sémantique de gel des champs finals du JMM sans surcharge de synchronisation, garantissant que instrumentId était immédiatement visible lors de la récupération.
Le changement a éliminé les anomalies de visibilité zéro et a restauré la latence attendue à l'échelle des microsecondes pour la recherche de services, tout en préservant l'intention de conception immuable.
Pourquoi final ne garantit-il pas la visibilité si je publie simplement la référence via une collection thread-safe comme ConcurrentHashMap ?
La relation happens-before fournie par les opérations put et get de ConcurrentHashMap établit un ordre entre les changements d'état internes de la carte, pas entre les écritures du constructeur et la publication dans la carte. Si this échappe pendant la construction, l'écriture dans le champ final se produit dans un thread tandis que la publication dans la carte se produit simultanément, manquant le lien happens-before nécessaire pour prévenir le réagencement des instructions. Par conséquent, le thread de lecture peut observer la référence via la carte avant que les écritures du constructeur ne soient vidées dans la mémoire principale, observant ainsi la valeur par défaut.
Puis-je corriger cela en rendant le champ du registre volatile au lieu des champs de l'objet ?
Marquer la référence du registre comme volatile garantit seulement que les changements à la variable du registre elle-même sont visibles, et non l'état interne des objets qu'elle contient. Puisque le problème est le timing des écritures de champs de l'objet par rapport à la référence devenant visible, le volatile sur le conteneur n'établit pas l'ordre nécessaire entre le constructeur et le consommateur de l'objet. Vous observeriez toujours des instances partiellement construites.
L'utilisation de synchronized à l'intérieur du constructeur empêche-t-elle la publication non sécurisée ?
Placer synchronized sur le constructeur ou l'utiliser pour protéger l'enregistrement empêche d'autres threads d'entrer dans la section critique en même temps, mais cela n'empêche pas la référence this d'échapper si la méthode d'enregistrement fuit la référence à un thread qui opère en dehors de ce verrou. Le JMM exige spécifiquement qu'aucune référence à l'objet n'échappe avant la fin du constructeur pour que les sémantiques des champs final soient maintenues ; la synchronisation sans un ordre de publication approprié ne peut pas ressusciter cette garantie.