Raj Modha’s Post

Java virtual threads are the most underrated performance upgrade I have seen in years. And most teams are still not using them. Here is the problem they solve: In traditional Java, every thread you create maps to an OS thread. OS threads are expensive. They consume memory, they are slow to create, and under high load they become a bottleneck that no amount of hardware can fully solve. That is why the industry moved toward reactive programming, frameworks like WebFlux, and async/non-blocking code. Effective, yes. But the complexity cost is real. Debugging reactive pipelines at 2am in a banking production environment is not fun. Java 21 changed this with Project Loom and virtual threads. Virtual threads are lightweight, JVM-managed, and can number in the millions without the overhead of OS threads. You write simple, readable, blocking code. The JVM handles the scheduling. With Spring Boot 4 now fully embracing Java 21 and virtual threads, the combination means: → Higher throughput without reactive complexity → Simpler, more maintainable code → Faster response times under load → Lower infrastructure costs I work on systems where transaction volume and latency are not negotiable. Virtual threads are not a future consideration anymore. They are production-ready today. If your team is still on Java 11 or Java 17 and debating the upgrade to Java 21, this feature alone makes the case. What has your experience been migrating to virtual threads? Feel free to drop your thoughts below. #Java #Java21 #SpringBoot4 #ProjectLoom #VirtualThreads #Microservices #BackendEngineering #FullStackDeveloper #AWS #Kafka #C2C #Corp2Corp #ContractDeveloper #OpenToWork #TechRecruiting #ITStaffing #RemoteDeveloper #JavaDeveloper #SoftwareArchitecture #CloudNative

Stop wasting memory on threads that do nothing. 🛑 If you’re building Java backends, you’ve probably seen this: More users → more threads → more RAM usage I recently explored Virtual Threads (Java 21 / Project Loom), and this concept finally clicked for me. 💡 The Problem In standard Java: 1 request = 1 Platform Thread During DB/API call → thread gets blocked It’s like a waiter standing idle while food is cooking 🍽️ 👉 Wasted resources + poor scalability 🔍 The Solution: Virtual Threads 👉 Lightweight threads managed by JVM (not OS) Cheap to create Can run thousands easily Perfect for I/O-heavy backend systems ⚙️ How it actually works (Mounting / Unmounting) 1️⃣ Mounting Virtual Thread runs on a Carrier Thread (Platform Thread) 2️⃣ I/O Call (DB/API) Your code looks blocking 3️⃣ Unmounting (Parking) Virtual Thread is paused & parked in heap memory 👉 It releases the Carrier Thread 4️⃣ Carrier Thread is free Handles another request immediately 5️⃣ Remounting (Resume) Once response comes → Virtual Thread continues 💻 The "magic" in code // Looks like blocking code Runnable task = () -> { System.out.println("Processing: " + Thread.currentThread()); String data = fetchDataFromDB(); // DB/API call System.out.println("Result: " + data); }; // Run using Virtual Thread Thread.ofVirtual().start(task); 🧩 What’s happening behind the scenes? 👉 Thread.ofVirtual() Creates a lightweight thread (stored in heap, not OS-level) 👉 During DB/API call Virtual Thread gets unmounted (parked) Carrier Thread becomes free 👉 While waiting Same thread handles other requests 👉 When response comes Scheduler remounts Virtual Thread Execution continues 📈 Result No idle threads Better resource usage Simple synchronous code High scalability without complex async code 🧠 Biggest takeaway 👉 “Code looks blocking… but system is not blocked.” That’s the mindset shift. Have you tried Virtual Threads in your services yet? Did you see any real performance improvement? 🤔 #Java #BackendEngineering #VirtualThreads #ProjectLoom #Java21 #Microservices #Performance

Java developers spent 20 years avoiding blocking code. Java 21 just made it… acceptable again. Sounds wrong, right? For years, we were told: 👉 “Never block threads” And honestly—that advice was correct. 🧱 The real problem wasn’t blocking Earlier: 1 request = 1 OS thread And those threads were: ● Heavy (~1–2 MB each) ● Kernel-managed ● Expensive to context switch So when a thread blocked on DB/API: 👉 It did nothing… but still consumed memory & scheduler time At scale: 👉 Systems failed due to thread exhaustion, not business logic 🔄 What we did to fix it We introduced: ● Thread pools ● Futures / callbacks ● Reactive (WebFlux) They worked—but added: ❌ Complexity ❌ Harder debugging ❌ Reduced readability Let’s be honest—most teams didn’t adopt reactive for love of it 😅 🧵 What changed in Java 21 (Virtual Threads) ● JVM-managed (not OS-bound) ● Lightweight (KBs, not MBs) ● Millions of threads possible 👉 The key shift: When a Virtual Thread blocks, it releases the OS thread immediately So: Blocking ≠ resource waste anymore ⚡ The real insight Earlier: 👉 Waiting = expensive Now: 👉 Waiting = almost free That’s a fundamental shift in concurrency design 💡 What this means for us You can now: ✔ Write simple, blocking code ✔ Handle massive concurrency ✔ Avoid unnecessary async complexity ⚠️ But stay practical Virtual Threads won’t: ● Fix bad design (N+1 still hurts) ● Improve CPU-bound workloads ● Replace good observability They remove a bottleneck— 👉 not architectural responsibility 💬 Honest question How much complexity in your system exists only to avoid blocking? ● Custom thread pools? ● Callback-heavy flows? ● Reactive where it’s not needed? 👉 If that constraint is gone… would you simplify? This shift is less about performance, and more about making simple code scalable again. #Java #Java21 #VirtualThreads #SystemDesign #Backend #Concurrency #SoftwareArchitecture

Most backend performance issues don’t come from bad code. They come from not understanding how the system behaves under load. While exploring Java 21, I tried to connect a few important pieces: • JVM latency improvements with ZGC • Virtual Threads (Project Loom) for concurrency • SQL patterns that impact real performance • Reflection vs Method Handles Put everything into a single visual to make it easier to revise. If you're preparing for backend roles, this might be useful to keep handy. Which part of backend performance do you find hardest to understand? #Java #Java21 #SpringBoot #BackendDevelopment #SystemDesign #PerformanceOptimization #SQL #SoftwareEngineering #java

This week I continued working on the performance issue I previously described in a Java Spring service. Initially, I tried to address the OutOfMemoryError by writing large data to a temporary file and then reading it line by line before storing it in the cache. While this approach reduced peak memory usage, it introduced significant I l/O overhead and made the process much slower. After further analysis, I removed the temporary file solution. Instead, I kept the streaming approach and processed the data in smaller chunks in memory. These chunks are then incrementally written to the database. This provided a better balance between memory usage and overall performance. I also kept the asynchronous cache update. The response is now returned to the client without waiting for the cache write to complete, while the cache is updated in the background. This reduced response time and improved system responsiveness. This change highlighted the importance of balancing memory usage and throughput, instead of focusing only on memory optimization. #java #springboot #softwareengineering #backend #performance #caching #architecture #scalability #microservices #javadeveloper

Most Java devs know Tomcat caps at ~200 threads. What Project Loom did about it. The issue: every Java thread maps to an OS thread. ~1MB RAM each. Under heavy I/O, 90% of those threads are just blocked (waiting on a DB, an API, a file). Sitting idle. Burning memory. Request 201? It waits. Or drops. That's been Java's reality for 20 years. Not a bug. A design constraint. Project Loom flips the model: Virtual thread hits a blocking call -> unmounts from OS thread -> OS thread immediately picks up next task -> millions of concurrent tasks, same machine. You write the exact same blocking code. The JVM does the scheduling. What changes: 1. Not execution speed 2. How many requests your server handles before it says "wait" 3. No reactive rewrite (WebFlux, RxJava) 4. Lower cloud bill. Same codebase. One thing interviewers love to ask: "what's the catch?" Two real ones: 1. Synchronized blocks pin virtual threads. Can silently kill your scaling gains. Check JVM pinning logs. 2. ThreadLocal breaks at scale. Use ScopedValue. Same code. Way cheaper server. #Java #ProjectLoom #SystemDesign #Backend #JavaDeveloper

Spring Boot @RequestScope vs Singleton — Hidden concurrency issue ⚠️ By default: 👉 Beans are Singleton (shared across threads) But what if you store request-specific data? 🤔 ❌ Problem: Multiple users → same instance → data leakage Solution 👇 @RequestScope public class RequestData { ... } 💡 What happens: ✔ New bean per request ✔ Thread-safe data handling ⚠️ Mistake: Storing user data in Singleton beans ❌ 👉 Leads to unpredictable bugs in production Design for concurrency, not just functionality 🔥 #SpringBoot #Java #Concurrency

Most Java developers have used ThreadLocal to pass context — user IDs, request IDs, tenant info — across method calls. It works fine with a few hundred threads. But with virtual threads in Java 21, "fine" becomes a memory problem fast. With 1 million virtual threads, you get 1 million ThreadLocalMap instances — each holding mutable, heap-allocated state that GC has to clean up. And because ThreadLocal is mutable and global, silent overwrites like this are a real risk in large systems: userContext.set(userA); // ... deep somewhere ... userContext.set(userB); // overrides without warning Java 21 introduces ScopedValue — the right tool for virtual threads: ScopedValue.where(USER, userA).run(() -> {   // USER is safely available here, immutably }); It's immutable, scoped to an execution block, requires no per-thread storage, and cleans itself up automatically. No more silent overrides. No memory bloat. No manual remove() calls. In short: ThreadLocal was designed for few, long-lived threads. ScopedValue is designed for millions of short-lived virtual threads. If you're building high-concurrency APIs with Spring Boot + virtual threads and still using ThreadLocal for request context — this switch can meaningfully reduce your memory footprint and make your code safer. Are you already using ScopedValue in production, or still on ThreadLocal? Would love to hear what's holding teams back. #Java #Java21 #VirtualThreads #ProjectLoom #BackendEngineering #SpringBoot #SoftwareEngineering

Thread Pools to Virtual Threads. 🧵 OutOfMemoryError it is a nightmare that has always haunted Java developers. We're always been stuck with Platform Threads (heavyweight wrappers around OS threads). Since each one cost about 1MB of memory, handling 10,000 concurrent requests meant you either needed a massive, expensive server or had to write complex reactive code that nobody actually wants to debug. Enter Project Loom (Java 21+). I’ve been diving into Virtual Threads, and the "blocking" game has completely changed. Here’s why this matters for the modern backend: Cheap as Chips: Virtual threads are managed by the JVM, not the OS. They only cost a few hundred bytes. You can literally spawn one million threads on a standard laptop without breaking a sweat. The "Thread-per-Request" Revival: We can go back to writing simple, readable, synchronous code. No more "Callback Hell" or complex Mono/Flux chains just to keep the CPU busy while waiting for a database response. Massive Throughput: In I/O-heavy applications (which most Spring Boot apps are), Virtual Threads allow the CPU to switch to other tasks instantly while one thread waits for a slow API or SQL query. How to use it in Spring Boot 3.2+? It’s literally one line in your application.properties: spring.threads.virtual.enabled=true By flipping this switch, Tomcat/Undertow starts using Virtual Threads to handle web requests. It’s a complete paradigm shift that lets us build more scalable systems with less infrastructure cost. The takeaway for teams: We no longer have to choose between "easy-to-read code" and "high-performance code." With Java 21, we get both. #Java #SpringBoot #BackendDevelopment #ProjectLoom #SoftwareEngineering #Scalability #JVM

Java just quietly changed how servers handle millions of requests. And most developers haven't noticed yet. I'm talking about Virtual Threads — introduced in Java 21 (LTS). 🧵 Before Virtual Threads: → 1 request = 1 OS thread → OS threads are expensive (~1MB stack each) → 10,000 requests = system struggling → The only fix was reactive programming (complex, hard to debug) After Virtual Threads: → Millions of virtual threads, managed by the JVM → Blocking a virtual thread doesn't block an OS thread → Write simple, readable blocking code — JVM handles the rest → No reactive spaghetti needed How easy is it to use? Thread.ofVirtual().start(() -> handleRequest(req)); Spring Boot 3.2+ supports it out of the box. Set spring.threads.virtual.enabled=true and you're done. This is Project Loom — years in the making. Production-ready right now. If your team is still on Java 8 or 11 — it's time to have that upgrade conversation. Have you tried Virtual Threads yet? Drop your experience below 👇 #Java #Java21 #VirtualThreads #ProjectLoom #BackendDevelopment #SpringBoot