Java Virtual Threads: The Pinning Problem and the Fix in Java 24
Posted by Normal-Tangelo-7120@reddit | programming | View on Reddit | 31 comments
I came across an internal engineering writeup at my org where a production service stalled after adopting virtual threads, a feature introduced in Java 21 that lets you run millions of lightweight threads on a handful of OS threads. Switching back to platform threads fixed it immediately.
Turns out Netflix hit the exact same problem of virtual threads getting pinned inside synchronized blocks, exhausting all carrier threads, and hanging the application.
I put together a write-up with a demo one can run locally to see it happen. It goes into what pinning is and why it exists, how to read thread dumps to spot it
programming-ModTeam@reddit
This content is low quality, stolen, blogspam, or clearly AI generated.
barockok@reddit
The JFR pinning detection is the part that actually changes the debugging workflow. Before this you'd just see throughput collapse under load and have to grep your codebase for every synchronized block that might be on a hot path. Getting the stack trace at the pin point makes it tractable. Curious if anyone has benchmarked the throughput delta on workloads that were previously pin-heavy.
programming-ModTeam@reddit
No content written mostly by an LLM. If you don't want to write it, we don't want to read it.
Syncher_Pylon@reddit
The pinning problem was the main reason I held off on adopting virtual threads in production. Having synchronized blocks pin the carrier thread to a platform thread essentially defeated the purpose. Glad to see Java 24 finally fixed this — it was the last major blocker for using virtual threads at scale.
wannaliveonmars@reddit
Is that like Win32 fibers? I think they were using the Win3.1 style cooperative-multitasking, so they occupy the same thread and just swap out the call stack and registers when switching. But if a fiber doesn't yield it blocks all other fibers.
That was a problem in Win3.1 too - any program that hanged would require you to restart, because there was no preemtive multitasking.
random_lonewolf@reddit
Java 25 is GA and LTS, there's no reason to use Java 24 now.
SaxAppeal@reddit
Funny, my company’s been pushing for “blocking” code backed by virtual threads (rather than async patterns) and I was skeptical, so I did what every modern engineer does in the last 6 months and probed Claude on why it would or wouldn’t lock up our applications under load. It uncovered this exact problem, as well as the fix in Java 24, and concluded we’re fine because we’re on Java 25.
OffbeatDrizzle@reddit
when was issue known about / fixed? I highly doubt claude "discovered" this by consuming Java source code, and merely consumed and regurgitated information that was already available on the web
cain261@reddit
Yeah but search engines are pretty awful now with the amount of garbage spit out in the results
owogwbbwgbrwbr@reddit
AI did its job fine, provided enough information to allow them to research further if desired
SaxAppeal@reddit
Did you read the article?
The problem was fixed in Java 24. And Claude most definitely just consumed Netflix’s blog post, I wasn’t implying that it “found the issue just by reading my source code” like a fucking magician or something. It’s a tool that reads code, reads sources, and spits out shit that may or may not be right, and in this case it was right. I don’t see how that makes it any less legitimate though…
If it could fine the answer to a real question in 30 seconds that might have taken me a lot longer to track down and fully grep, why wouldn’t I use that?
pyt1m@reddit
interesting that this wasn’t identified as problematic when virtual threads where implemented initially
davispw@reddit
It was, it was a well known and document limitation.
pyt1m@reddit
Yet it caused issues in some of the largest software systems in the world.
Chii@reddit
just because they're large, doesn't mean they're maintained by competent people?
pyt1m@reddit
Yes, that’s my point. The limitation was documented but nobody said “hey this could cause issues because people often don’t read the fine print, let’s fix this limitation first”
Alborak2@reddit
yeah this speaks pretty poorly of the java runtime maintainers. Having worked on user mode scheduling stuff, this is a pretty terrible rough edge in a core primitive.
seanluke@reddit
This article copies text verbatim, without permission or citation, directly from Oracle's documentation. See for example https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html#GUID-704A716D-0662-4BC7-8C7F-66EE74B1EDAD
This is either AI slop or it is engaged in copyright violation. I think it should be removed.
MrChocodemon@reddit
AI can create things that violate copyright
Alborak2@reddit
Like the middle 2/3 of this article is kind of a waste. It boils down to virtual threads were launched only half implemented, with the built -in synchronization method of
synchronizedbeing fundamentally broken.cake-day-on-feb-29@reddit
It seems to be at least partially AI-generated, the excessive use of "The _____" header phrasing, the button points, the ordered list "steps", phrasing like
And
Clearly someone went through the effort of modifying the speech, or prompting the AI in an attempt at making it less obvious.
danskal@reddit
I don't know, if I read it in an indian accent, it seems perfectly fine to me. Hmmm maybe they used indian staff to train AI.
thetinguy@reddit
It's ai slop.
sammymammy2@reddit
You don't need this writing pattern. Seriously, please stop :(.
sailing67@reddit
had this bite me once adn it looked like a 'random' outage until we stared at thread dumps for way too long. virtual threads are sick, but synchronized stuff is a sneaky footgun. did the fix in 24 basically just reduce pinning, or does it also give better tooling to spot it?
CptGia@reddit
There are some new JFR events to help you diagnose problems with virtual threads
pohart@reddit
It eliminated most of it.
aookami@reddit
damn, who though reading documentation on a crucial implementation point would be a good thing
happyscrappy@reddit
These kinds of threads are the same as green threads and even were used in Java before. They have the same issues. Including this well-known one.
https://en.wikipedia.org/wiki/Green_thread
Not putting down your own detective abilities, just saying if you are looking to see if there might be other issues you could run into with these later then searching for information on green threads might give you some warning as to what else you might encounter.
bwmat@reddit
Were virtual threads not 'supported' until 24?
Because that's a pretty broken feature without the fix...
MintySkyhawk@reddit
Yeah, I was investigating an issue where our worker pods would just randomly stop doing anything and then go radio silent until they were eventually killed. I was pretty stumped until I found that Netflix article. Managed to put in a hacky workaround that made it happen much less often and then we updated to Java 24 as soon as it came out.