Gustavo Araujo Dunhão’s Post

Modern Java quietly made the Visitor pattern relevant again. Sealed classes changed the tradeoffs. It might be time to revisit Visitor. I wrote about why Visitor still makes sense if you're using Java 17–20: https://lnkd.in/dPkpgqtb

Discover the remarkable evolution of Java from boilerplate code to a modern powerhouse. From lambdas to records, and virtual threads to efficient I/O work, Java 25 is a far cry from its verbose past. Read how Java 25 is revolutionizing software engineering: https://lnkd.in/gfjERgWr #Java #ModernJava #Java25 #LanguageFeatures #SoftwareEngineering

Java Virtual Threads: simplifying concurrency without switching paradigms For a long time, scalable concurrency in Java meant choosing between: ▪️ thread pools with careful tuning ▪️ asynchronous code (CompletableFuture) ▪️ reactive programming All of these approaches work, but they introduce additional complexity into the codebase. Virtual threads (Project Loom) take a different direction: keep the blocking programming model, but remove the scalability limitations of OS threads. What changes with virtual threads Virtual threads are lightweight and managed by the JVM. Instead of mapping one thread to one OS thread, the JVM schedules many virtual threads onto a smaller pool of carrier threads. This allows: ▪️ creating a large number of concurrent tasks ▪️ writing code in a familiar, sequential style ▪️ avoiding callback chains and reactive pipelines Where they fit well ▪️ Virtual threads are a good fit for: ▪️ I/O-bound services ▪️ systems with many concurrent requests ▪️ service-to-service communication ▪️ database and external API calls In these scenarios, most of the time is spent waiting, not computing. Virtual threads allow the system to scale without blocking OS threads. Limitations and trade-offs They do not improve CPU-bound workloads. If tasks are heavy on computation, the number of cores remains the limiting factor. They also require attention to blocking operations: ▪️ poorly implemented blocking (e.g. native calls) can pin carrier threads ▪️ libraries not designed for this model may reduce the benefits Adoption also depends on ecosystem readiness and team familiarity. Why this matters Virtual threads make it possible to build highly concurrent systems without introducing a different programming model. For many backend services, this can reduce the need for reactive or heavily asynchronous code, while keeping the system scalable. The key question is not whether virtual threads replace existing approaches, but where they simplify the system without introducing new risks. Have you tried virtual threads in real systems, and where do you see the biggest impact? #java #concurrency #backend #softwareengineering #loom #microservices

Your Java service isn’t slow. It’s frozen — and you have no idea why. You migrated to virtual threads. Load tests looked amazing. Throughput 🚀 Then production happened. JVM is alive. No exceptions. No CPU spike. Just… silence. This is the virtual thread pinning trap — and it hit Netflix on Java 21. What’s really happening? Virtual threads are not magic. They’re M:N scheduling. → A few carrier threads (~CPU cores) run everything → Virtual threads mount/unmount on them → Scalability depends on one thing: unmounting when blocked If they can’t unmount? 👉 Carriers get pinned 👉 Scheduler starves 👉 System looks dead The landmine: synchronized (Java 21–23) → Monitor is tied to the carrier thread, not the virtual thread → If a virtual thread blocks inside synchronized → JVM cannot unmount it Result: → 1 pinned carrier = reduced capacity → All carriers pinned = total freeze No crash. No error. Just zero progress. The Netflix case (and why it’s scary) It wasn’t their code. It was Brave (Zipkin tracing). → synchronized block → Inside: tries another lock → Virtual thread already holds a monitor → Cannot unmount → Carrier gets pinned 4 CPUs → 4 carriers → 4 pinned threads → full system stall Connections kept coming in. Nothing could run. The real pattern This is what most teams miss: 👉 Virtual thread failures happen at the library boundary Not your business logic. Your code can be perfect. But if a dependency does: → synchronized + blocking I/O You’re one deploy away from a production freeze. Ecosystem impact This wasn’t isolated: → Apache HTTP Client (fixed in 5.4) → MySQL Connector/J (fixed in 9.0) → PostgreSQL JDBC → Caffeine cache (needed JDK fix) Same root issue everywhere. How to catch it before it catches you Run this before production: -Djdk.tracePinnedThreads=full If you see: → reason: MONITOR You’ve found a ticking time bomb. The fix (and why it’s a big deal) JEP 491 (Java 24) → Monitor ownership moves to virtual thread → Blocking no longer pins carrier → Scheduler keeps flowing Same code. Completely different runtime behavior. The real takeaway Virtual threads don’t remove limits. They move the bottleneck. 👉 From memory → to scheduling 👉 From thread count → to pinning And pinning doesn’t fail loudly. It fails silently. Have you hit virtual thread pinning in production —or caught it just in time? 👇 Curious to hear real-world war stories #Java #VirtualThreads #JVM #SpringBoot #SystemDesign #DistributedSystems #BackendEngineering

🚀 Java Virtual Threads: The "Death" of Reactive Complexity? The era of choosing between "Easy to Write" and "Easy to Scale" is officially over. For years, Java backend developers faced a trade-off. If you wanted massive scale, you had to embrace Reactive Programming (like CompletableFuture). It was powerful, but it turned our stack traces into nightmares and our logic into "callback hell." Virtual Threads changed the game. Here is why this is a revolution for Microservices and high-throughput systems: 🧵 The "Thread-Per-Request" Comeback Historically, OS threads were expensive (roughly 1MB per thread). In a high-traffic API, you’d run out of memory long before you ran out of CPU. Virtual Threads are lightweight—we’re talking kilobytes, not megabytes. 💡 The Big Shift: Legacy: We carefully managed FixedThreadPools to avoid crashing the JVM. Modern: We spawn a new Virtual Thread for every single task and let the JVM handle the heavy lifting. 🛠️ Why this matters for Backend Engineering: Simplicity: Write clean, sequential, blocking code. No more .flatMap() chains. Scale: Handle millions of concurrent requests on standard hardware. Observability: Debugging and profiling work exactly as they should. A stack trace actually tells you where the error started. ⚠️ The "Real World" Reality Check It isn't magic. While threads are now "free," your downstream resources (Database connections, API rate limits) are not. The challenge has shifted from Thread Management to Resource Management. In 2026, if you’re building microservices in Java 21+, Virtual Threads aren't just an "option"—they are the new standard for efficient, readable backend architecture. Java developers: Are you still sticking with traditional thread pools, or have you migrated your production workloads to Virtual Threads? 🚀 #Java #SpringBoot #BackendEngineering #VirtualThread #Microservices #SoftwareDevelopment #Concurrency

Your Java app didn’t crash because something broke. It crashed because it kept holding on. We’ve all been told this: Java has Garbage Collection… memory is handled for you. And that’s where the misunderstanding begins. Because GC doesn’t clean unused objects. It only cleans objects that are no longer reachable. So if somewhere in your system… → a static cache keeps growing → a ThreadLocal is never cleared → a listener is never removed Then those objects don’t die. They stay. And they keep everything they reference alive too. Nothing looks wrong. The code compiles. The system runs. The APIs respond. But underneath… 📈 memory keeps climbing 📈 objects keep accumulating 📈 pressure keeps building Until one day… it collapses. What makes this tricky is: This isn’t a typical bug. It’s not about logic. It’s about ownership. 👉 Who owns this object? 👉 When should it be released? 👉 Who is still holding the reference? Because in Java: Memory isn’t freed by the GC. It’s freed when your system lets go. I broke this down with a simple whiteboard + real scenarios. It’s one of those things… once you see it, you start noticing it everywhere. https://lnkd.in/etAYAswr #Java #MemoryLeak #GarbageCollection #SystemDesign #BackendEngineering #JVM #SpringBoot #Performance #Microservices #SoftwareEngineering #Coding #TechLeadership

Does Java really use too much memory? This is a common concern we hear from developers. Igor Souza takes a fact-based look at Java's memory usage, examining specific JEPs (JDK Enhancement Proposals) that have significantly improved memory efficiency over the years. The article covers: - How modern Java has changed compared to older versions - Concrete JEPs that reduced memory footprint - Real-world implications for your applications If you've been avoiding Java because of memory concerns, or if you're working with legacy assumptions about Java's resource usage, this article provides the data you need. Read the full analysis here: https://lnkd.in/e9RrhpSQ #Java #JVM #Performance #Memory

Go vs. Java: Which handles concurrency better? 🚀 I’ve been diving deep into backend performance lately, specifically how different languages manage threading at scale. I just published a technical deep dive comparing Go’s Goroutines with Java’s threading models. If you’re interested in software architecture, memory management, or high-concurrency systems, I’d love to hear your thoughts on it! Check out the full deep dive below 👇 #SoftwareEngineering #Backend #Java #Golang #SystemDesign #Concurrency

CQRS in Java: Separating Reads and Writes Cleanly. As systems grow in complexity, keeping read and write operations separate can significantly improve performance and maintainability.  In this article, Mike LaSpina breaks down the Command Query Responsibility Segregation (CQRS) pattern and shows how to implement it cleanly in Java applications. You'll learn: • The core principles behind CQRS • When to use this pattern (and when not to) • Practical implementation examples • How it scales with your application needs Whether you're dealing with high-traffic systems or just looking to improve your architecture, this guide offers practical insights you can apply right away. Read the full article here: https://lnkd.in/e8bUV_ji #Java #CQRS #SoftwareArchitecture #CleanCode

Every Java developer deals with concurrency sooner or later. But even experienced engineers need a quick refresh from time to time. I wrote this article to help you revisit the essentials — without diving back into books or long courses. Read it briefly, sharpen your memory, and get your concurrency skills back in shape. https://lnkd.in/eP5x5hS3