Java Concurrency: Synchronized vs Lock for Thread Safety

🔥 Day 6 — Deadlocks in Java: How They Happen & How to Avoid Them Your system is running fine… Suddenly everything stops responding. No errors. No logs. Just stuck. 👉 You might be dealing with a deadlock. ⚠ What is a Deadlock? A situation where two or more threads are waiting on each other forever. Each thread holds a lock and waits for another lock → 👉 Result: System freeze 💻 Simple Example Thread 1: synchronized(lock1) { synchronized(lock2) { // do work } } Thread 2: synchronized(lock2) { synchronized(lock1) { // do work } } 👉 Thread 1 waits for lock2 👉 Thread 2 waits for lock1 ❌ Both wait forever → DEADLOCK ⚠ Common Causes - Inconsistent lock ordering - Nested synchronization - Holding locks for too long - Multiple resources with dependencies ✅ How to Prevent Deadlocks ✔ Always follow consistent lock order ✔ Avoid nested locks when possible ✔ Use tryLock() with timeout ✔ Keep critical sections small ✔ Prefer higher-level concurrency utilities 💡 Architect Insight: Deadlocks are dangerous because: ❌ No exception thrown ❌ Hard to reproduce ❌ Often appear only under load In production, they can cause: - Complete system halt - API timeouts - Revenue impact (especially in payments) 🚀 Rule of Thumb: Design your locking strategy upfront — 👉 Don’t “fix” concurrency later 👉 Have you ever debugged a deadlock? How did you identify it? #100DaysOfJavaArchitecture #Java #Concurrency #SoftwareArchitecture #Microservices

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

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

🚀 Day 3 – Why String is Immutable in Java (and why it matters) One question I explored today: Why are "String" objects immutable in Java? String s = "hello"; s.concat(" world"); System.out.println(s); // still "hello" 👉 Instead of modifying the existing object, Java creates a new String But why was it designed this way? ✔ Security – Strings are widely used in sensitive areas (like class loading, file paths, network connections). Immutability prevents accidental or malicious changes. ✔ Performance (String Pool) – Since Strings don’t change, they can be safely reused from the pool, saving memory. ✔ Thread Safety – No synchronization needed, multiple threads can use the same String safely. 💡 This also explains why classes like "StringBuilder" and "StringBuffer" exist—for mutable operations when performance matters. Small design decision, but huge impact on how Java applications behave internally. #Java #BackendDevelopment #JavaInternals #LearningInPublic #SoftwareEngineering

🔥 Day 10 — Thread vs Runnable vs Callable in Java If you're working with concurrency in Java, you’ll constantly decide between Thread, Runnable, and Callable. Here’s a simple, practical breakdown 👇 1️⃣ Thread — The Oldest & Loudest Way Thread represents an actual execution thread. ✔ When to use - Only when you must override thread-specific behavior - Very rare in modern applications ✖ Why it's not preferred - You can’t return a result - You can’t throw checked exceptions Tight coupling: your task is also the thread Check below example: class MyThread extends Thread {   public void run() {     System.out.println("Running thread");   } } 2️⃣ Runnable — Lightweight Tasks (No Return Value) Runnable is the simplest abstraction for a task. ✔ When to use - You just need to run a piece of code - No result required For example : Runnable task = () -> System.out.println("Task running"); executor.submit(task); 3️⃣ Callable — Runnable with Superpowers ⚡ Callable<V> is Runnable’s upgraded version. ✔ Key advantages - Returns a value - Can throw checked exceptions - Works seamlessly with Future ✔ When to use - When your task computes a result - When you need exception handling For example: Callable<Integer> task = () -> 42; Future<Integer> result = executor.submit(task); 💡 Key Takeaway Stop creating your own Thread. - Use Runnable when you need simple execution, - Use Callable when you need a result or exception handling. #100DaysOfJavaArchitecture #Java #Concurrency #SoftwareArchitecture #Microservices

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

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

⚠️ 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

🚀🎊Day 72 of 90 – Java Backend Development ✨🎆 In the world of Java multithreading, a Mutex (short for Mutual Exclusion) is a synchronization mechanism used to ensure that only one thread can access a specific resource or block of code at a time. Think of it like a bathroom key at a coffee shop: only the person holding the key can enter; everyone else has to wait in line until the key is returned. 👉 How Mutex works in Java? Java doesn’t have a class literally named Mutex. Instead, it provides several tools that implement mutex behavior to prevent race conditions (where two threads try to modify the same data simultaneously, leading to bugs). 👉 1. The synchronized Keyword This is the simplest way to achieve mutual exclusion. When a thread enters a synchronized block, it acquires an "intrinsic lock" (or monitor) on the object. No other thread can enter any synchronized block on that same object until the first thread finishes. public synchronized void increment() {   // Only one thread can execute this at a time   count++; } 👉 2. ReentrantLock Found in the java.util.concurrent.locks package, this is a more flexible, explicit version of a mutex. It offers features that synchronized doesn't, such as: i) Timed waiting: Trying to get the lock for a specific amount of time. ii) Interruptible locks: Allowing a thread to back out if it's waiting for a lock. iii) Fairness: Ensuring the longest-waiting thread gets the lock next. 👉 Why use a Mutex? Without a mutex, you encounter the "Lost Update" problem. For example, if two threads try to increment a variable count = 5 at the exact same time: i) Thread A reads 5. ii) Thread B reads 5. iii) Thread A hits 6 and saves it. iv) Thread B hits 6 and saves it. Result: The count is 6, even though two increments happened. It should be 7. A Mutex forces these operations to happen one after the other, ensuring data integrity. #Multithreading #Mutex #ReentrantLock #synchronized

Java finally fixed one of its oldest concurrency mistakes… and it’s not about performance. Think about a real backend flow: Building an account snapshot: • fetch account (DB) • fetch user details (service) • fetch country data (service) These are independent - we run them concurrently. The old way (Executor + Future): • if one fails - others keep running (thread leaks) • cancellation is manual (and often forgotten) • parent/child relationship? doesn’t exist • debugging = pain The structure exists in your head - not in the code. Java 26 - Structured Concurrency (JEP 525) This is the same logic - but now: • failure cancels everything automatically • no task outlives the request • lifecycle is scoped & enforced • code reflects the actual problem The real shift - structured concurrency brings back something we lost: call-stack thinking - but across threads And that’s why it matters. Virtual threads gave us cheap concurrency. Structured concurrency makes it correct.