Concurrency used to mean trade-offs: simplicity vs scalability. With #VirtualThreads, #Java challenges that. Mihaela Gheorghe-Roman explores benchmarks, migration steps, & what #JDK25 adds to #ProjectLoom. Still afraid of blocking I/O? Dive in: javapro.io/2026/03/05/java-2… @openjdk

Ever seen requests fail while subtasks kept running anyway? That’s one of the nastiest problems in concurrent systems — especially with #VirtualThreads. Babneet Singh maps out how #StructuredConcurrency in #Java26 adds clear task ownership & teardown: javapro.io/2026/06/09/struct…

Why are so many #AI backends harder to debug than to build? Reactive pipelines solved scalability — but often created systems nobody enjoys maintaining. Damiana Nascimento shows where #VirtualThreads simplify #RAG & #LLM services. Read: javapro.io/2026/06/02/virtua… #Java26 @QuarkusIO

How did Java evolve from: “1 OS thread = 1 Java thread” to VIRTUAL THREADS handling millions of requests efficiently… 🧵 Initially Java used PLATFORM THREAD, which meant 1 Java Thread is mapped to one OS Thread. Simple model. Request comes → create thread → do work → send response. Worked fine initially. Until traffic exploded. 10 users. 100 users. 10k users. Now JVM creates thousands of OS threads. Problem? OS threads are EXPENSIVE. Each thread needs: - stack memory - kernel scheduling - CPU coordination - context switching - thread metadata And default stack space for a thread alone can be ~1MB. So, 100k threads = 100GB of stack space 💀 But memory wasn’t even the biggest problem. Most backend threads were not computing. They were WAITING. Waiting for: - DB - APIs - network - disk That means, thousands of expensive OS threads just sleeping idle. Even worse, CPU starts spending huge time in CONTEXT SWITCHING. Saving thread state. Loading another. Flushing caches. Server starts burning CPU doing “thread management” instead of actual work. So industry moved towards: - async programming - callbacks - event loops - reactive systems Because thread-per-request stopped scaling. But async code became nightmare fuel. Then Java introduced: VIRTUAL THREADS. And the idea was insane: “What if threads were cheap?” Now, many Java virtual threads run on few real OS threads. Instead of: 1 Java thread = 1 OS thread we can now get: Millions of virtual threads mapped onto maybe 8 carrier threads. Carrier thread = actual OS thread underneath. You as a passenger are virtual thread riding that Uber ride which is carrier thread. Once you reach your stop(done with the task) or do wait for your another friend (blocking task) , it will save your context of that state as a chunk and store it in heap (which we normally used to do on stack) and will drop u off instantly. Now that Uber driver will instantly pick up another passenger(virtual thread), you'll have to wait until your friend comes(blocking task completes) before jumping into another ride. In technical terms, Virtual thread uses carrier thread while actively running. But when it hits blocking call: db.fetch() socket.read() JVM does something magical. Instead of blocking OS thread, it PAUSES virtual thread, saves its execution state, and immediately frees carrier thread. Carrier thread now starts executing another virtual thread. This is the breakthrough. Earlier: blocking call blocked whole OS thread. Now: only virtual thread pauses. Internally JVM uses: - continuations - heap stored stacks - async IO underneath - scheduler managing remounting So virtual threads basically make: ASYNC EXECUTION look like NORMAL BLOCKING CODE. You write simple synchronous code. JVM secretly handles scalability magic underneath. But there’s one catch: PINNING. Some operations cannot release carrier thread safely. Example: - synchronized blocks - JNI/native calls Then carrier thread also gets stuck which can cause issues with scalability... Still… Virtual threads are one of the biggest backend engineering upgrades in years because they combine: simple code massive concurrency without callback hell. Stack is basically OS-thread associated memory while heap is JVM managed that's what gave JVM full flexibility over concurrency management. Backend evolution basically became: 1 thread per request → thread explosion → async/event loops → callback hell → reactive programming → virtual threads making blocking code scalable again. Do share and repost if you like this way of learning concepts 🫶 #java #virtualthreads #concurrency #tech #engineering #techblogs

Las charlas de #jmad26 ya han empezado! La de VirtualThreads de @gortizja está petada!

How many threads in your #Java app are doing work you’ll throw away anyway? #Java 25’s #Structured Concurrency helps you cancel fast, fail fast, & keep subtasks scoped (no leaks). Read the breakdown by @hannotify & Bram Janssens: javapro.io/2026/01/28/how-to… #VirtualThreads @OpenJDK

#VirtualThreads aren’t just a #Java hype feature. This article shows them powering agent calls safely in production-style #Microservices—with fallback observability. Steal the blueprint by @sibaspadhi: javapro.io/2026/01/22/java-2… #SpringBoot #GenAI #Observability #VectorSearch

Migrating #JDKs and hitting “why did this break?” moments? @speakjava highlights the releases that introduced the biggest shifts — Jigsaw/modules, preview features, #VirtualThreads. Read this before your next upgrade sprint: javapro.io/2026/01/20/25-ver… #Java #Migration #DevOps

🚀 Most Java devs still build Spring Boot microservices like it's 2022. But in 2026, Virtual Threads are quietly changing everything. What is a Virtual Thread?🤯 It's a lightweight thread managed by the JVM — not the OS. Traditional platform threads are heavy (~1MB each) and limited. Virtual threads use just a few KB — the JVM can run millions efficiently by mounting/unmounting them on a small pool of carrier threads. Biggest benefit? 😇 Write simple blocking code and still get near-reactive performance. No callback hell. No forcing WebFlux everywhere.Many teams are seeing 2x–5x better throughput with lower memory usage. Have you switched your Spring Boot apps to Virtual Threads yet? Yes → What's your biggest win (or gotcha)? No → What's stopping you? Drop your thoughts below 💭 Follow for more practical Spring Boot, microservices & system design cheat sheets. 🚀 #SpringBoot #Java #VirtualThreads

ThreadLocal breaks with #VirtualThreads. @chwoerz explains why — and how ScopedValue replaces it with safe, immutable, scope-bound context propagation. Migrating to #Java25? Read this first: javapro.io/2025/12/23/java-2… #JVM #Java #StructuredConcurrency #Performance #JAVAPRO

100k blocking tasks. A few seconds. On a laptop. With #VirtualThreads in #Java25, that’s reality. Mihaela Gheorghe-Roman explains what changed since #JDK21 & why thread-per-request is back. Still running huge thread pools? Rethink: javapro.io/2026/03/05/java-2… #ProjectLoom @openjdk

Do you really know how threads work in Java? And how about Virtual Threads, the game-changing feature introduced in Java 21? Read more 👉 lttr.ai/Ama8h #BazlurRahman📚 #EmbracingVirtualThreads #VirtualThreads

Still fighting thread pools when traffic spikes? #ProjectLoom offers a different path. @BalaRawool shows how #VirtualThreads, #StructuredConcurrency, and Scoped Values work together in a real #SpringBoot app. See what you can simplify: javapro.io/2026/02/19/virtua… #Performance

We are thrilled to welcome Mihaela Gheorghe-Roman to the stage at Java Day Istanbul for a truly unique, live-coded session: "Chaos Meets Code: Fractals as a Playground for Modern Java Features." Mihaela will pull back the curtain on recursion, fractals, and chaos theory, using them as a powerful lens to explore the capabilities of modern Java. She’ll be demonstrating in real time how features like Virtual Threads, Pattern Matching, and Records make these complex, mathematically beautiful renderings possible and efficient. This isn't just theory. You'll walk away with practical techniques and code you can apply to your own performance-critical and creative projects. 🔗 Join us on April 18th in Istanbul! Register here: javaday.istanbul/ #JavaDayIstanbul #ModernJava #ChaosTheory #Fractals #CodingArt #VirtualThreads #MihaelaGheorgheRoman

Concurrency used to mean trade-offs: simplicity vs scalability. With #VirtualThreads, #Java challenges that. Mihaela Gheorghe-Roman explores benchmarks, migration steps, & what #JDK25 adds to #ProjectLoom. Still afraid of blocking I/O? Dive in: javapro.io/2026/03/05/java-2… @openjdk

100k blocking tasks. A few seconds. On a laptop. With #VirtualThreads in #Java25, that’s reality. Mihaela Gheorghe-Roman explains what changed since #JDK21 & why thread-per-request is back. Still running huge thread pools? Rethink: javapro.io/2026/03/05/java-2… #ProjectLoom @openjdk

Java Updates Roundup: JDK 26, MCP Toolbox, and More linkedin.com/pulse/java-upda… #Java #JavaNews #OpenJDK #JDK26 #JDK27 #JavaDevelopers #JavaNews #JavaEcosystem #Quarkus #Micronaut #NetBeans #OpenLiberty #TornadoVM #JReleaser #WebAssembly #Wasm #VirtualThreads #JavaFrameworks

Building high-throughput #Java servers? Don’t let #VirtualThreads pin you down. With Panama io_uring, David Vlijmincx shows how to truly go async—from memory arenas to native calls. Benchmark results included: javapro.io/2025/10/16/async-… @RedHat @OpenJDK #ProjectPanama

Your batch job works on your laptop… but triggers OOM errors & DDoS-es your dependencies. What now? See how a high-scale #SpringBoot #gRPC workload evolved: from single-threaded prototypes → #VirtualThreads & semaphores. “Just async” isn’t enough: bit.ly/3YBRr2h

#VirtualThreads aren’t just a #Java hype feature. This article shows them powering agent calls safely in production-style #Microservices—with fallback observability. Steal the blueprint by @sibaspadhi: javapro.io/2026/01/22/java-2… #SpringBoot #GenAI #Observability #VectorSearch