I thread virtuali in Project Loom operano come continuazioni montate sopra thread carrier tratti da un ForkJoinPool. Quando un thread virtuale incontra un blocco synchronized o esegue codice nativo, blocca il suo thread carrier sottostante, impedendo al pianificatore di smontare il thread virtuale durante le operazioni di I/O bloccanti. Questo riduce effettivamente il grado di concorrenza alla dimensione della piscina carrier (tipicamente pari al numero dei core CPU), causando potenzialmente un collasso della capacità sotto carico mentre i thread virtuali in contesa monopolizzano la fissa piscina carrier.
Un'azienda di servizi finanziari ha migrato il proprio gateway legacy per l'elaborazione degli ordini da un modello tradizionale Tomcat thread-per-request (limitato a 500 thread di piattaforma) a Jetty con thread virtuali, aspettandosi di gestire 50.000 connessioni WebSocket contemporanee. Subito dopo il deployment, nonostante l'adozione dei thread virtuali, la latenza è aumentata a secondi e la capacità è rimasta stagnante a solo 800 TPS durante la volatilità dell'apertura del mercato. I dump dei thread hanno rivelato che tutti e 24 i thread carrier erano bloccati nello stato BLOCKED all'interno di blocchi synchronized, mentre migliaia di thread virtuali in coda per l'I/O non potevano procedere.
La prima soluzione considerata è stata l'aumento del parallelismo del ForkJoinPool tramite -Djdk.virtualThreadScheduler.parallelism a 1000. Questo avrebbe fornito più thread carrier per assorbire il carico bloccato, ripristinando effettivamente il comportamento di un ampio pool di thread di piattaforma. Tuttavia, questo approccio maschera semplicemente il difetto architetturale sottostante consumando eccessive risorse del sistema operativo e annullando i benefici di efficienza della memoria promessi dalla virtualizzazione dei thread virtuali.
La seconda soluzione ha coinvolto la rifattorizzazione di tutti i blocchi synchronized che proteggono le cache condivise di limitazione della velocità per utilizzare ReentrantLock invece. A differenza dei monitor intrinseci, ReentrantLock si integra con il pianificatore dei thread virtuali, consentendo lo smontaggio durante la contesa o le operazioni di blocco senza pinning del carrier. Questo approccio preserva la natura leggera dei thread virtuali ma richiede un audit sistematico del codice e una gestione attenta delle semantiche di interruzione del lock.
La terza soluzione proposta consisteva nel sostituire le cache di mappe hash concorrenti con strutture dati completamente senza lock come i metodi compute di ConcurrentHashMap o StampedLock per letture ottimiste. Sebbene questo elimini il blocco per molti percorsi di lettura, non affronta gli scenari che richiedono accesso esclusivo a risorse esterne stateful come le sequenze di checkout delle connessioni al database che richiedono inegabilmente l'esclusione reciproca.
Il team ha selezionato la seconda soluzione, dando priorità a una migrazione mirata di cinquanta sezioni critiche synchronized a ReentrantLock dopo aver identificato tramite profiling i loro hotspot di pinning. Questa scelta ha affrontato direttamente la causa principale consentendo al pianificatore di smontare i thread virtuali durante la contesa, senza alterare la logica di business dell'applicazione sottostante o aumentare l'impronta di memoria.
Dopo la rifattorizzazione e il riutilizzo, il sistema ha raggiunto il target di 50.000 connessioni contemporanee con una latenza p99 stabile sotto i 100 ms. La piscina dei thread carrier è rimasta della dimensione predefinita di 24 (corrispondente ai core CPU), dimostrando che i thread virtuali offrono vera scalabilità solo quando il codice evita di pinning i carrier attraverso la sincronizzazione intrinseca.
// Prima: Pinning del thread carrier synchronized (rateLimiter) { // Il thread virtuale non può smontare se bloccato qui externalApi.call(); } // Dopo: Consente lo smontaggio rateLimiter.lock(); try { // Il thread virtuale si smonta, liberando il carrier externalApi.call(); } finally { rateLimiter.unlock(); }
Perché il pinning si verifica specificamente con blocchi sincronizzati e metodi nativi, mentre ReentrantLock consente lo smontaggio?
Il pinning si verifica perché la JVM implementa monitor intrinseci (synchronized) utilizzando record di monitor basati su stack di thread e strutture interne VM a livello di C++ che sono intrinsecamente legate al contesto di esecuzione del thread OS fisico. Quando un thread virtuale entra in un blocco sincronizzato, la JVM non può migrare in sicurezza la continuazione a un altro carrier senza corrompere lo stato del monitor o violare le garanzie di happens-before a livello nativo. Al contrario, ReentrantLock è implementato puramente in Java sopra AbstractQueuedSynchronizer, che utilizza i primitivi VarHandle e LockSupport.park su cui si interpone il pianificatore dei thread virtuali, consentendo uno smontaggio e un rimontaggio sicuro tra carrier senza dipendenza dallo stato del thread nativo.
Come interagisce il pinning del thread carrier con il meccanismo di furto di lavoro del ForkJoinPool per creare potenziali scenari di starvazione?
Durante il funzionamento normale, il ForkJoinPool presuppone che i compiti siano bound al CPU o non bloccanti; quando un thread di lavoro blocca, compensa avviando o attivando ulteriori lavoratori fino al limite di parallelismo. Tuttavia, un thread virtuale pinning blocca il suo carrier senza segnalare efficacemente il meccanismo di compensazione della pool. Di conseguenza, se venti thread virtuali pinano simultaneamente venti carrier (ad es., entrando in blocchi sincronizzati), non rimangono carrier per eseguire i migliaia di thread virtuali pronti in coda nel pianificatore. Questo crea una inversione di priorità in cui il lavoro non bloccato non può progredire nonostante le attività disponibili, riducendo effettivamente dinamicamente e in modo catastrofico la dimensione della pool utilizzabile.
L'uso aggressivo delle variabili ThreadLocal può causare pinning dei thread carrier negli ambienti a thread virtuali?
ThreadLocal non induce pinning perché l'implementazione dei thread virtuali migra la mappa thread-locale tra carrier durante le operazioni di montaggio e smontaggio. Tuttavia, i candidati trascurano frequentemente che ThreadLocal presenta una catastrofe di gestione della memoria distintiva: con milioni di thread virtuali a vita breve che toccano i thread-local, ogni thread carrier accumula voci nella sua ThreadLocalMap per ogni thread virtuale che ha mai ospitato. Poiché queste mappe vengono pulite solo al momento della rimozione esplicita o della garbage collection della chiave (il thread virtuale), ciò genera una crescita di memoria non limitata nei thread carrier a lungo termine. Questo costituisce effettivamente una perdita di memoria non correlata al pinning ma ugualmente fatale per i deployment di thread virtuali su larga scala, richiedendo la migrazione a ScopedValue (JEP 446) per una corretta pulizia.