Netflix, connu pour son utilisation intensive de Java, était ravi d'adopter les threads virtuels pour leurs avantages en matière de performances. Cependant, pendant la migration vers Java 21, les ingénieurs ont rencontré des timeouts intermittents et des instances non réactives dans les applications utilisant des threads virtuels avec SpringBoot 3 et Tomcat embarqué. Les enquêtes ont révélé une augmentation des sockets bloqués dans l'état closeWait, indiquant que les applications échouaient à fermer les connexions. Les dumps de threads ont initialement montré des JVM inactives, mais une analyse plus approfondie utilisant des commandes spécifiques a révélé un grand nombre de "threads vides" virtuels, qui sont des threads créés mais pas encore en cours d'exécution. Cela a pointé vers un problème avec l'exécution des threads virtuels, où Tomcat créait un nouveau thread virtuel pour chaque demande entrante, mais les threads du système d'exploitation sous-jacent étaient tous occupés. Une analyse plus approfondie des dumps de threads a montré que ces threads du système d'exploitation étaient verrouillés sur des threads virtuels bloqués en attente d'acquérir un verrou à l'intérieur d'un bloc synchronisé dans le code. Le coupable était un verrou détenu par un thread de plateforme régulier qui était incapable de réacquérir le verrou après avoir terminé une opération d'attente. Cette situation de deadlock empêchait les nouveaux threads virtuels d'être planifiés, ce qui entraînait les problèmes de performance observés.