Java Deadlocks: Causes & Prevention Strategies

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

Deadlocks in Java -> Small mistake, big outage Deadlock = threads waiting on each other forever. Classic case: Thread A → holds lock1, waits for lock2 Thread B → holds lock2, waits for lock1 👉 Both stuck. No crash. Just a frozen system. 💥 Deadlock-prone code Object lock1 = new Object(); Object lock2 = new Object(); new Thread(() -> { synchronized (lock1) { try { Thread.sleep(100); } catch (Exception e) {} synchronized (lock2) {} } }).start(); new Thread(() -> { synchronized (lock2) { try { Thread.sleep(100); } catch (Exception e) {} synchronized (lock1) {} } }).start(); ✅ Fix 1: Consistent lock ordering synchronized (lock1) { synchronized (lock2) { // safe } } ✔ Removes circular wait → no deadlock ✅ Fix 2: tryLock with timeout ReentrantLock l1 = new ReentrantLock(); ReentrantLock l2 = new ReentrantLock(); if (l1.tryLock()) { try { if (l2.tryLock()) { try { /* work */ } finally { l2.unlock(); } } } finally { l1.unlock(); } } ✔ Threads don’t block forever ✔ Safer for real systems 💡 Reality check: If you use multiple locks and haven’t thought about deadlocks → you’re gambling with production. Deadlocks aren’t bugs. They’re design failures. #Java #Concurrency #Backend #SystemDesign #Deadlock

I’ve seen this discussion many times — and the answer is more nuanced than “Streams vs loops”. Yes, streams can introduce overhead in certain scenarios. But the real issue isn’t the syntax. It’s using abstractions without understanding their cost. In performance-sensitive paths, what matters is: allocation patterns GC pressure data size and access patterns Streams can be perfectly fine. Or a bottleneck — depending on context. The dangerous part is optimizing based on assumptions instead of measurements. Clean code vs performance isn’t a trade-off. Blind abstraction vs informed decisions is.

Although streams might use more cpu , they’re incredibly useful when you want to transform from a collection to an array or if you simply want to map a dto from a model

Recently, while working on a backend application in Java, I encountered a common scalability issue. Even with thread pools in place, the system struggled under high load, particularly during multiple external API and database calls. Most threads were waiting but still consuming resources. While multithreading in Java is crucial for developing scalable backend systems, it often introduces complexity, from managing thread pools to handling synchronization. The introduction of Virtual Threads (Project Loom) in Java is changing the landscape. Here’s a simple breakdown: - Traditional Threads (Platform Threads) - Backed by OS threads - Expensive to create and manage - Limited scalability - Requires careful thread pool tuning - Virtual Threads (Lightweight Threads) - Managed by the JVM - Extremely lightweight (can scale to millions) - Ideal for I/O-bound tasks (API calls, DB operations) - Reduces the need for complex thread pool management Why this matters: In most backend systems, threads spend a lot of time waiting during I/O operations. With platform threads, resources get blocked, while with virtual threads, blocking becomes cheap. This leads to: - Better scalability - Simpler code (more readable, less callback-heavy) - Improved resource utilization When to use what? - Virtual Threads → I/O-heavy, high-concurrency applications - Platform Threads → CPU-intensive workloads Virtual Threads are not just a performance improvement; they simplify our approach to concurrency in Java. This feels like a significant shift for backend development. #Java #Multithreading #Concurrency #BackendDevelopment #SoftwareEngineering

Built an HTTP server from scratch in Java. No frameworks. No Netty. No Spring Boot. Just raw sockets, manual byte parsing, and a thread pool wired from the ground up. The goal was never to reinvent the wheel. It was to understand what the wheel is actually made of. What was built: → TCP socket listener handing connections to a fixed thread pool of 500 workers → HTTP/1.1 parser written byte-by-byte - request line, headers, body (JSON + form-urlencoded) → Router handling HEAD, GET and POST with static file serving and query param injection → Structured error responses for 400, 404, 500, 501, and 505 → WebRootHandler with path traversal protection → Full JUnit test suite, Maven build, SLF4J logging, and a Dockerized deployment What it reinforced: Networking - HTTP is just bytes on a wire. The kernel speaks TCP, not HTTP. The parser is what gives those bytes meaning. Operating systems - the boundary between user space and kernel space stopped being abstract. accept(), read(), write() are syscalls. Everything else lives in the JVM. Concurrency - 500 threads sharing a single handler. Statelessness stops being a design preference and becomes a correctness requirement. Docker - the container wraps the JVM, not the kernel. Syscalls go to the host kernel. There is no container kernel. Building something from scratch is one of the most honest ways to learn. Every assumption gets tested, every abstraction gets earned. A recommendation from Kashif Sohail turned into weeks of going deep on networking, OS internals, and concurrency. Grateful for that push. GitHub repo :https://lnkd.in/dxxjXxpt #Java #Networking #OperatingSystems #Backend #SystemsEngineering #Docker #OpenSource

I wrote an article for JAVAPRO about the Foreign Function and Memory (FFM) API, added in #Java 22, and how it got used to add a new and better plugin to The Pi4J Project. You can read it here: https://lnkd.in/em6K5xhM

Java Streams are killing your performance Java Streams look clean… but they can silently destroy your performance. I saw this in a production audit last week. A simple loop processing 1M records was replaced with streams “for readability”. // ❌ Stream version list.stream() .filter(x -> x.isActive()) .map(x -> transform(x)) .collect(Collectors.toList()); // ✅ Optimized loop List<Result> result = new ArrayList<>(); for (Item x : list) { if (x.isActive()) { result.add(transform(x)); } } 🚨 What happened in production: • CPU usage increased by 35% • GC pressure exploded • Latency x2 under load ❗ Why? Streams: • Create more objects • Add hidden overhead • Are NOT always optimized by JVM ✅ Fix: • Use streams for readability (small datasets) • Use loops for performance-critical paths • Benchmark before choosing https://www.joptimize.io/ Clean code ≠ fast code. Are you using streams in performance-sensitive code? #JavaDev #SpringBoot #JavaPerformance #Backend #SoftwareEngineering

⚠️ Why Java Killed PermGen (And What Replaced It) Before Java 8, JVM had PermGen (Permanent Generation) A special memory region inside the heap used for: Class metadata Method metadata String intern pool (pre-Java 7) Static variables The Problem was with PermGen as it had a fixed size: -XX:MaxPermSize=256m Sounds fine until: Applications dynamically load classes Frameworks create proxies (Spring, Hibernate) ClassLoaders don’t get garbage collected 👉 Boom: OutOfMemoryError: PermGen space Very common in: App servers Long-running systems Hot-deploy environments 🧠 Enter Metaspace (Java 8+) PermGen was removed and replaced with Metaspace Key change: Moved class metadata OUT of heap → into native memory ⚡ What Changed? Memory Location Native memory Size Dynamic (auto grows) Tuning Minimal OOM Errors Frequent Much rarer 🧠 Why This Was a Big Deal Metaspace: Grows dynamically (no fixed ceiling by default) Reduces OOM crashes Simplifies JVM tuning Handles dynamic class loading better But It’s Not “Unlimited" If not controlled It can still cause: OutOfMemoryError: Metaspace So you can still set limits: -XX:MaxMetaspaceSize=512m 🧠 What Actually Lives in Metaspace? Class metadata Method metadata Runtime constant pool NOT: Objects (Heap) Stack frames (Stack) PermGen failed because it was fixed. Metaspace works because it adapts. #Java #JVM #MemoryManagement #Metaspace #PerformanceEngineering #BackendDevelopment #JavaInternals #LearnInPublic

Multithreading in Java — The Day My Application “Woke Up” A few months ago, I was working on a backend service for transaction processing. Everything looked fine until real users hit the system. Requests started piling up Response time slowed down System felt stuck At first, I thought it was a database issue. But the real problem? My application was doing everything one task at a time. That’s when I truly understood the power of Multithreading in Java. Instead of one thread handling everything: • One thread processes transactions • Another handles logging • Another validates requests Suddenly, the same application started handling multiple tasks simultaneously. What is Multithreading? It’s the ability of a program to execute multiple threads (smaller units of a process) concurrently, improving performance and responsiveness. Why it matters in real-world systems? Better performance Improved resource utilization Faster response time Essential for scalable backend systems How Java makes it easy: • Thread class • Runnable interface • ExecutorService But here’s the twist Multithreading is powerful, but dangerous if misused. I learned this the hard way: • Race conditions • Deadlocks • Synchronization issues My key takeaway: Multithreading doesn’t just make your app faster It forces you to think like a system designer. Have you ever faced performance issues that multithreading solved (or created 😅)? #Java #Multithreading #BackendDevelopment #SystemDesign #Performance #CodingJourney