I've been experimenting with Java virtual threads and encountered some synchronization problems, especially when using connection pools like Agroal or Hikari. When testing with a low-core setup (only one core), I found that with a high number of virtual threads (like 100,000), they tended to block, ultimately leading to timeouts with a "Sorry, acquisition timeout!" SQLException. Meanwhile, platform threads managed to handle the load without issues. I took a closer look at the Agroal synchronizer, which employs a spin-wait mechanism, and I'm wondering if this approach is inappropriate for virtual threads. Shouldn't spin-waiting be limited to platform threads? I even adjusted the AgroalSynchronizer to utilize a Semaphore instead of spinning, allowing waiting without blocking during connection acquisition. I'm curious about others' experiences and thoughts on this matter. Is the legacy synchronization code just not compatible with virtual threads?
2 Answers
You've raised several important points. The synchronization issues you're encountering have indeed been addressed in Java 24, so I recommend you to run your tests using that version or even a release candidate of Java 25. Also, can you clarify what you mean by a 'single core container'? Is this just a regular Linux setup, or are you running it in Kubernetes? If it's the latter, don’t forget to set your cpu.requests and cpu.limit correctly! That could make a difference too.
I doubt that the Java 24 fix will completely solve your problem. The method description for tryAcquireNanos in AbstractQueuedLongSynchronizer suggests that it might still lead to issues on single-core setups, especially with virtual threads. Sounds like a complex situation where old synchronization patterns just clash with the new threading model.
It sounds like you're hitting some limitations with the synchronization structures on low-core setups. When you're working with just a single core, those sync structures can struggle to keep up, especially under heavy load. Have you tried using Thread.onSpinWait() wisely to yield threads when you’re only on one core? It might help alleviate some of that blocking while waiting for connections.
I feel like the real issue is more about CPU intensive pinning rather than spin locking. It may not be a straightforward fix.