Virtuele threads in Project Loom functioneren als continuaties die zijn gemonteerd op draagdraden die zijn getrokken uit een ForkJoinPool. Wanneer een virtuele thread een gesynchroniseerd blok tegenkomt of native code uitvoert, wordt zijn onderliggende draagthread vastgezet, waardoor de scheduler de virtuele thread niet kan ontmounten tijdens blokkering bij I/O-operaties. Dit vermindert effectief de graad van gelijktijdigheid tot de grootte van de draagpool (typisch gelijk aan het aantal CPU-kernen), wat mogelijk leidt tot doorvoerverval onder belasting als betwiste virtuele threads de vaste draagpool monopoliseren.
Een financiële dienstverlener migreerde hun legacy orderverwerkingsgateway van een traditioneel Tomcat model per verzoek (beperkt tot 500 platformthreads) naar Jetty met virtuele threads, in de hoop 50.000 gelijktijdige WebSocket-verbindingen te kunnen verwerken. Onmiddellijk na de implementatie, ondanks de adoptie van virtuele threads, spike de latentie naar seconden en plateauerde de doorvoer op slechts 800 TPS tijdens de volatiteit bij marktopening. Thread dumps toonden aan dat alle 24 draagthreads vastzaten in de BLOCKED status binnen gesynchroniseerde blokken, terwijl duizenden virtuele threads in de rij stonden voor I/O en niet verder konden.
De eerste overweging was om de paralleliteit van de ForkJoinPool te verhogen via -Djdk.virtualThreadScheduler.parallelism naar 1000. Dit zou meer draagthreads bieden om de vastgezette werklast op te vangen, effectief terugkerend naar het gedrag van een groot platformthread pool. Echter, deze aanpak verbergt slechts de onderliggende architectonische fout door overmatige OS-hulpmiddelen te verbruiken en annuleert de geheugen efficiëntievoordelen die door virtuele thread virtualisatie zijn beloofd.
De tweede oplossing omvatte het herschrijven van alle gesynchroniseerde blokken die gedeelde rate-limiting caches bewaken om in plaats daarvan ReentrantLock te gebruiken. In tegenstelling tot intrinsieke monitors integreert ReentrantLock met de virtuele thread scheduler, waardoor ontmounten mogelijk is tijdens inhouding of blokkering zonder de draagthread vast te pinnen. Deze aanpak behoudt de lichte aard van virtuele threads, maar vereist een systematische audit van de codebase en zorgvuldige omgang met de semantiek van lock-onderbrekingen.
De derde oplossing stelde voor om de gelijktijdige hash map caches te vervangen door puur lock-vrije datastructuren zoals ConcurrentHashMap compute-methoden of StampedLock voor optimistische lezingen. Hoewel dit blokkering voor veel leespaden elimineert, pakt het niet de scenario's aan die exclusieve toegang tot staatvolle externe bronnen vereisen, zoals databaseconnectiesequenties die inherent wederzijdse exclusie vereisen.
Het team koos voor de tweede oplossing, waarbij ze prioriteit gaven aan een gerichte migratie van vijftig kritieke gesynchroniseerde secties naar ReentrantLock nadat profilering deze had geïdentificeerd als pinning hotspots. Deze keuze pakte de onderliggende oorzaak rechtstreeks aan door de scheduler in staat te stellen virtuele threads te ontmounten tijdens inhouding, zonder de onderliggende zakelijke logica van de toepassing te veranderen of de geheugengebruik te verhogen.
Na de herstructurering en herimplementatie bereikte het systeem de doelstelling van 50.000 gelijktijdige verbindingen met stabiele sub-100ms p99 latentie. De draagthreadpool bleef op de standaardgrootte van 24 (overeenkomend met CPU-kernen), wat aantoont dat virtuele threads echte schaalbaarheid bieden alleen wanneer de code het pinnen van draagdraden door intrinsieke synchronisatie vermijdt.
// Voor: Het pinnen van de draagthread synchronized (rateLimiter) { // Virtuele thread kan niet ontmounten als deze hier is geblokkeerd externalApi.call(); } // Na: Staat ontmounten toe rateLimiter.lock(); try { // Virtuele thread ontmount, waardoor de draagdraden vrij komen externalApi.call(); } finally { rateLimiter.unlock(); }
Waarom komt pinning specifiek voor bij gesynchroniseerde blokken en native methoden, terwijl ReentrantLock ontmounten toestaat?
Pinning ontstaat omdat de JVM intrinsieke monitors (gesynchroniseerd) implementeert met behulp van monitorrecords op basis van de thread-stack en interne structuren op C++-niveau die inherent zijn verbonden met de uitvoering context van de fysieke OS-thread. Wanneer een virtuele thread een gesynchroniseerd blok binnenkomt, kan de JVM de continuatie niet veilig naar een andere draagdraden verplaatsen zonder de monitorstatus te corrumperen of de happens-before garanties op native niveau te schenden. Omgekeerd is ReentrantLock puur in Java geïmplementeerd bovenop AbstractQueuedSynchronizer, die VarHandle en LockSupport.park primitieve gebruikt die de virtuele thread scheduler bijbrengt, waardoor veilige ontmounting en remounting over draagdraden mogelijk is zonder afhankelijkheid van de native threadstatus.
Hoe gaat pinning van draagthreads om met de work-stealing van ForkJoinPool om potentiële stervingsscenario's te creëren?
Onder normale omstandigheden veronderstelt de ForkJoinPool dat taken CPU-gebonden of niet-blokkerend zijn; wanneer een werkthread blokkeert, compenseert deze door aanvullende workers te creëren of te activeren tot aan de limiet van de paralleliteit. Echter, een vastgezette virtuele thread blokkeert zijn draagdraden zonder effectief te signaleren naar het compensatiemechanisme van de pool. Dienovereenkomstig, als twintig virtuele threads tegelijkertijd twintig draagdraden vastzetten (bijv. het binnenkomen van gesynchroniseerde blokken), dan blijven er geen draagdraden over om de duizenden gereedstaande virtuele threads in de scheduler uit te voeren. Dit creëert een prioriteitsinversie waarbij onbelemmerd werk niet kan vorderen, ondanks beschikbare taken, wat de bruikbare poolgrootte dynamisch en catastrofaal verkleint.
Kan agressief gebruik van ThreadLocal-variabelen pinning van draagdraden in virtuele threadomgevingen veroorzaken?
ThreadLocal-variabelen veroorzaken geen pinning omdat de implementatie van de virtuele thread de thread-lokale map tussen draagdraden verplaatst tijdens mount- en unmount-operaties. Kandidaten over het hoofd zien echter vaak dat ThreadLocal een aparte ramp voor geheugenbeheer met zich meebrengt: met miljoenen kortlevende virtuele threads die thread-locals aanraken, accumuleert elke draagthread invoeren in zijn ThreadLocalMap voor elke virtuele thread die het ooit heeft gehost. Aangezien deze mappen alleen worden schoongemaakt bij expliciete verwijdering of garbage collection van de sleutel (de virtuele thread), genereert dit ongekende geheugengroei in lange-lopende draagdraden. Dit vormt effectief een geheuglek dat niet gerelateerd is aan pinning, maar even fataal is voor grootschalige implementaties van virtuele threads, wat migratie naar ScopedValue (JEP 446) vereist voor de juiste opruiming.