L'histoire de la synchronisation des ClassLoader remonte à la spécification originale de la JVM, qui imposait un chargement de classes sécurisé par des threads mais ne fournissait initialement qu'un verrouillage à grain grossier sur le moniteur d'instance de ClassLoader. Avant Java 7, chaque invocation de loadClass() était synchronisée sur this, créant un goulet d'étranglement global dans les environnements multi-threadés comme les serveurs d'application où le chargement de classes concurrent est courant. Java 7 a introduit l'API registerAsParallelCapable(), permettant aux chargeurs d'opter pour des schémas de verrouillage à grain fin qui améliorent considérablement le débit.
Le problème central provient de la nature récursive de la délégation par les parents combinée aux méthodes synchronisées. Lorsqu'un ClassLoader enfant écrase loadClass() et se synchronise sur sa propre instance, il détient ce verrou tout en invoquant parent.loadClass(), acquérant ainsi le verrou du parent. Dans des hiérarchies complexes, telles que les bundles OSGi avec des imports de paquets bidirectionnels ou des architectures de plugins avec des exigences de visibilité circulaire, cela crée des cycles classiques de commande de verrou où le Thread-A détient Child-A et attend le Parent, pendant que le Thread-B détient le Parent et attend Child-A.
La solution déplace la synchronisation de l'instance du chargeur vers le nom de classe spécifique à charger. Lorsqu'registerAsParallelCapable() est invoqué dans un initialiseur statique de ClassLoader, la JVM maintient un ConcurrentHashMap des chargeurs capables de travailler en parallèle et se verrouille sur la chaîne internee du nom de la classe plutôt que sur l'objet chargeur. Cela permet le chargement concurrent de classes distinctes par différents threads au sein du même chargeur. Cependant, cela introduit un nouveau danger : si Loader-A se verrouille sur le nom de classe "X" et délègue à Loader-B pour une dépendance, tandis que Loader-B se verrouille simultanément sur le nom de classe "Y" et délègue de nouveau à Loader-A pour "X", les threads entrent dans une attente circulaire sur des noms de classes différents à travers différents espaces de noms de chargeur—un verrou mort invisible à l'analyse standard des moniteurs.
Une plateforme de trading à haute fréquence a mis en œuvre un moteur de stratégie modulaire où chaque jar d'algorithme chargé via des enfants URLClassLoader faisait référence à un parent partagé pour les classes de données de marché. Lors de l'ouverture du marché, 500 threads ont simultanément activé des stratégies, déclenchant une massive concurrence sur le moniteur du chargeur parent et entraînant des occasions de trading manquées.
Solution 1 : Synchronisation par défaut
L'implémentation initiale reposait sur la méthode synchronized héritée loadClass. Bien que garantissant la cohérence happens-before, cette approche a sérialisé tout le chargement de classes à travers un unique moniteur. Le profilage des performances a révélé que 95 % des threads étaient bloqués en attente du verrou du ClassLoader parent, réduisant le débit effectif à des niveaux à thread unique pendant la fenêtre critique de démarrage.
Solution 2 : Chargement personnalisée non synchronisé
Les développeurs ont tenté de supprimer complètement la synchronisation, supposant que le contenu immuable des jars garantissait un chargement idempotent. Cela a entraîné la création de plusieurs objets Class distincts pour des définitions identiques résidant dans le même chargeur, causant des LinkageError et des messages ClassCastException cryptiques indiquant "Strategy ne peut pas être converti en Strategy" en raison de définitions de classes dupliquées chargées par des threads concurrents.
Solution 3 : Enregistrement capable de fonctionner en parallèle
L'équipe a implémenté registerAsParallelCapable() dans une sous-classe personnalisée de ClassLoader, en écrasant strictement findClass() plutôt que loadClass() pour préserver le mécanisme de verrouillage parallèle. Cela a permis la résolution concurrente de noms de classes distincts tout en maintenant la chaîne de délégation par le parent. La solution a nécessité de restructurer la hiérarchie des plugins pour éliminer les dépendances circulaires des paquets entre les chargeurs frères. Résultat : la latence de démarrage est passée de 120 secondes à 8 secondes sous pleine charge, avec zéro verrou morts de ClassLoader détectés durant six mois de trading en production.
Pourquoi la substitution de loadClass() au lieu de findClass() désactive-t-il silencieusement les optimisations capables de fonctionner en parallèle ?
Le mécanisme capable de fonctionner en parallèle intègre un verrouillage à grain fin dans le modèle de méthode loadClass(String name, boolean resolve) fourni par le JDK. Lorsqu'une sous-classe remplace loadClass(String), elle contourne la logique interne qui acquiert des verroux sur des noms de classes spécifiques via la parallelLockMap interne du ClassLoader. La sous-classe revient accidentellement à un accès soit non synchronisé—provoquant des courses de définition de classe dupliquées—ou doit se synchroniser manuellement sur this, réintroduisant le goulet d'étranglement global. Le modèle correct délègue à super.loadClass() pour les vérifications du cache et la délégation parent, restreignant la logique de conversion de tableau d'octets à classe personnalisée à findClass(), qui s'exécute dans le contexte de verrou spécifique au nom déjà établi.
Comment les modèles ServiceLoader peuvent-ils déclencher des verrous morts même avec des ClassLoaders capables de fonctionner en parallèle ?
Lorsque ServiceLoader exécuté dans un ClassLoader parent tente d'instancier une implémentation de service résidant dans Child-A, il invoque implicitement Child-A.loadClass(). Si cette classe d'implémentation déclenche une initialisation statique (<clinit>) qui charge une classe utilitaire depuis Parent (par exemple, un logger), et qu'un autre thread détient le verrou Parent en attente de charger une autre implémentation de service depuis Child-A, une attente circulaire se forme. Le Thread-1 détient le verrou du nom de classe Parent pour "Logger" et attend le verrou de Child-A pour "ServiceImpl". Le Thread-2 détient le verrou de Child-A pour "ServiceImpl" (en raison de l'appel initial de ServiceLoader) et attend le verrou Parent pour "Logger". Ce chargement de classe inter-chargeur durant l'initialisation crée des chaînes de verrous morts que les analyseurs de dump de threads standard ont du mal à identifier car ils surveillent les moniteurs d'instance de ClassLoader plutôt que les verroux internes basés sur des noms.
Qu'est-ce que la condition de course "defineClass window" et pourquoi la capacité parallèle ne l'empêche-t-elle pas ?
La capacité parallèle garantit que les opérations loadClass pour le même nom de classe sont sérialisées, mais defineClass() reste une opération native distincte vulnérable aux conditions de course. Si un chargeur personnalisé implémente un stockage externe ou une transformation de bytecode en dehors de la vérification standard findLoadedClass—par exemple, dans un agent Java qui intercepte loadClass—deux threads peuvent passer simultanément la vérification "non chargé" et invoquer defineClass(byte[], ...) pour le même nom binaire. Le second thread reçoit LinkageError : tentative de définition de classe dupliquée. Cela se produit parce que la vérification et l'insertion dans le SystemDictionary sont atomiques au niveau de la JVM, mais la fenêtre entre la vérification préalable personnalisée et l'invocation de defineClass n'est pas protégée par le verrou de nom capable de fonctionner en parallèle, à moins que le code ne suive strictement le modèle de méthode sans effets secondaires externes ou synchronisation supplémentaire.