Java Concurrency Bug: Deadlock in Microsoft's Threads

💥 Tricky Java Concurrency Bug — When Meta’s Threads Forgot to Wake Up 😴 At Meta, a developer built a notification system where one thread waited for new messages, and another thread sent them. Everything worked great… until production, when some threads never woke up again. Let’s take a look class Messenger { private boolean hasMessage = false; synchronized void waitForMessage() { while (!hasMessage) { try { wait(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } System.out.println("📩 Message received!"); hasMessage = false; } synchronized void sendMessage() { hasMessage = true; System.out.println("✉️ Message sent!"); notify(); } } Two threads: waitForMessage() → called by the receiver thread sendMessage() → called by the sender thread But sometimes, the receiver never gets notified. 😬 💣 The Root Cause — Missed Notification If the sender calls notify() before the receiver calls wait(), the notification is lost forever the receiver will then wait indefinitely. 💀 Classic missed signal problem. This usually happens when thread scheduling or timing changes under load a nightmare to debug because it’s nondeterministic. ✅ The Fix — Use a Condition Flag (and Always Recheck!) The code above already uses a while loop instead of if — that’s good. But to avoid the missed signal, you must ensure ordering: Start the waiting thread before the notifying thread. Or, better yet — use java.util.concurrent tools like CountDownLatch or BlockingQueue. Example fix with a BlockingQueue: BlockingQueue<String> queue = new ArrayBlockingQueue<>(1); Thread receiver = new Thread(() -> { try { String msg = queue.take(); System.out.println("📩 Received: " + msg); } catch (InterruptedException ignored) {} }); Thread sender = new Thread(() -> { try { queue.put("Hello Meta!"); System.out.println("✉️ Message sent!"); } catch (InterruptedException ignored) {} }); No lost signals, no missed wake-ups — just clean, reliable communication. ✅ --- 🧠 Debugging Tips 🔍 If a thread appears “frozen,” inspect if it’s stuck in wait(). ⚙️ Use thread dumps (jstack) to identify which locks are held. 🪞 Always recheck condition flags after waking up. 🧩 Prefer BlockingQueue, CountDownLatch, or Condition objects for signaling. ✅ Quick Checklist ☑️ Never assume notify() happens after wait(). ☑️ Use while, not if, to recheck the condition. ☑️ Prefer modern concurrency utilities over raw wait/notify. ☑️ Always synchronize on the same monitor object for wait/notify. At Meta, the issue wasn’t with the messages it was with the threads that forgot to wake up and check them. 😂 #Java #Concurrency #Meta #Multithreading #wait #notify #DebuggingTips #JavaDevelopers #SoftwareEngineering #CleanCode #ThreadSafety #CodingHumor #DailyLearning #InterviewPrep

💥 Tricky Java Concurrency Bug — When Jio ’s Threads Saw Different Realities 🌀 At Jio, an engineer noticed something strange: the server logs said “Connected”, but some threads still behaved as if the network was offline. 😳 Everything looked fine in the code: class NetworkManager { private boolean connected = false; public void connect() { connected = true; System.out.println("Connected to Jio network ✅"); } public void checkConnection() { if (connected) { System.out.println("Already connected!"); } else { System.out.println("Not connected yet..."); } } } Multiple threads were calling connect() and checkConnection(). Sometimes it worked. Sometimes it didn’t. Sometimes both messages appeared together. 🤯 💣 The Root Cause — The Missing volatile In Java, each thread can cache variables locally for speed. Without volatile, one thread’s update to a variable may not be visible to another thread immediately. So even though one thread set connected = true, others were still reading the old cached value (false). 👉 Threads weren’t disagreeing on logic. They were just living in different realities. 😅 ✅ The Fix — Declare It volatile class NetworkManager { private volatile boolean connected = false; ... } Now, every read and write to connected happens directly from main memory — ensuring visibility and freshness across threads. ✅ ⚙️ What volatile Does (and Doesn’t Do) ✔️ Guarantees visibility (latest value is always read) ❌ Doesn’t guarantee atomicity (use synchronized or atomic variables for that) ✔️ Prevents instruction reordering for that variable 🧠 Debugging Tips 🔍 If threads read stale or inconsistent data, check for missing volatile. 🪞 Use thread dumps or logging to confirm unexpected execution order. ⚙️ For counters, prefer AtomicInteger over volatile int. 🧩 Always think in terms of visibility and atomicity — they solve different problems. ✅ Quick Checklist ☑️ Use volatile for shared flags and status variables. ☑️ For compound updates, use Atomic* or synchronization. ☑️ Don’t rely on printlns — race conditions rarely show up in logs. ☑️ Remember: thread-safe != visibility-safe. At Jio, the bug wasn’t in the network — it was in the threads that refused to stay in sync. 😂 > Lesson: In a multi-threaded world, even reality needs the volatile keyword. 🌍 #Java #Concurrency #Jio #Multithreading #Volatile #JavaDevelopers #CleanCode #DebuggingTips #SoftwareEngineering #ThreadSafety #DailyLearning #CodingHumor

💥 Tricky Java Concurrency Bug — When X ’s ConcurrentHashMap Wasn’t So Concurrent 🧵😅 At X (formerly Twitter), the engineering team built a feature to cache trending topics per region. Each request updated a shared ConcurrentHashMap — safe and simple, right? After all, it’s thread-safe. 😎 Well… not entirely. 🧩 The Code ConcurrentHashMap<String, Integer> trends = new ConcurrentHashMap<>(); void updateTrend(String topic) { trends.put(topic, trends.getOrDefault(topic, 0) + 1); } Under high traffic, multiple threads were calling updateTrend("java") simultaneously. Everything looked fine during testing... but in production, the counts were lower than expected. 😨 “Wait, how can a thread-safe map lose updates?” 💣 The Root Cause ConcurrentHashMap guarantees thread-safe operations per method, but not for compound actions like: 👉 get → modify → put Each of those is atomic individually, but the combination isn’t. So two threads could do this at the same time: Thread 1 Thread 2 Reads old value = 5 Reads old value = 5 Increments → 6 Increments → 6 Puts 6 Puts 6 Final value = 6 (not 7!) ❌ Lost update Boom 💥 — your trending count quietly went down the drain. ✅ The Fix — Use Atomic Operations Option 1️⃣ — merge() trends.merge(topic, 1, Integer::sum); Option 2️⃣ — compute() trends.compute(topic, (k, v) -> v == null ? 1 : v + 1); Both ensure the entire update happens atomically, without any lost increments — even with 1000 threads fighting for the same key. 🧠 Debugging Tips 🔍 If your counts or data occasionally “miss” updates → check for compound operations. ⚙️ ConcurrentHashMap methods are atomic, but combinations are not. 🪄 Use merge(), compute(), or putIfAbsent() for safe updates. 📊 Reproduce with a stress test — race conditions rarely appear in unit tests. ✅ Quick Checklist ☑️ Don’t chain get → modify → put on concurrent maps. ☑️ Prefer merge() or compute() for atomic updates. ☑️ Avoid synchronized wrappers around ConcurrentHashMap (it kills performance). ☑️ Use LongAdder for high-frequency counters. At X, the issue wasn’t the algorithm — it was the illusion of safety. 😅 > “Just because something is thread-safe doesn’t mean your logic is.” 💡 #Java #ConcurrentHashMap #X #Twitter #Multithreading #DataStructures #JavaDevelopers #DebuggingTips #CleanCode #SoftwareEngineering #Concurrency #ThreadSafety #CodingBestPractices #DailyLearning

💥 Tricky Java 25 Concurrency Bug — When Google Finally Stopped Leaking Threads At Google, a backend service was making three parallel API calls per request: user profile recommendations ads Simple, right? Until one day the JVM started crying: “Thread leak detected!” Why? Because the old code looked like this: ExecutorService executor = Executors.newCachedThreadPool(); Future<String> user = executor.submit(() -> fetchUser()); Future<String> recs = executor.submit(() -> fetchRecs()); Future<String> ads = executor.submit(() -> fetchAds()); return user.get() + recs.get() + ads.get(); If any task threw an exception or timed out the remaining futures kept running in the background like abandoned pets. This caused: ❌ Thread leaks ❌ Zombie tasks ❌ Quiet memory growth ❌ Slower GC ❌ Higher latency Google’s SRE team summed it up perfectly: > “If your tasks are structured like spaghetti, your threads will behave like spaghetti.” 💡 Enter Java 25’s Structured Concurrency Java 25 gives us StructuredTaskScope, which treats a group of tasks as ONE unit — so if one fails, the whole group is cancelled. No leaks. No zombies. No forgotten futures. try (var scope = new StructuredTaskScope.ShutdownOnFailure()) { var user = scope.fork(() -> fetchUser()); var recs = scope.fork(() -> fetchRecs()); var ads = scope.fork(() -> fetchAds()); scope.join(); // wait for all scope.throwIfFailed(); // throw if any failed return user.get() + recs.get() + ads.get(); } ✔ If any task fails → the entire scope is shut down ✔ Remaining tasks are cancelled automatically ✔ No more thread leaks ✔ No more forgotten futures ✔ Clean, readable, predictable Google engineers called it: > “Finally… concurrency with parental supervision.” 😎 🧠 Why Structured Concurrency Is a GAME-CHANGER ✔ Prevents thread leaks ✔ Ensures tasks complete together ✔ Cleaner error handling ✔ Cancellation is automatic ✔ Works beautifully with virtual threads ✔ Zero orphan tasks This is the concurrency model Java should have had 15 years ago. And now it does. 🧵 Debugging Tips 🔍 If you see a slow memory leak → check for abandoned futures 🔍 If executor threads keep growing → you’re missing cancellation 🔍 If one subtask fails but others continue → use structured concurrency 🔍 If virtual threads are leaking → switch immediately to StructuredTaskScope ✅ Quick Checklist ☑ Use Structured Concurrency for parallel subtasks ☑ Never use Future + executor spaghetti for multi-step workflows ☑ Use ShutdownOnFailure when you want “fail-fast” behavior ☑ Use ShutdownOnSuccess when only the first successful task matters ☑ Combine with virtual threads for maximum speed > Lesson: Java 25 didn’t just fix concurrency… it finally added a cleanup crew. 🧹 #Java #Java25 #Google #StructuredConcurrency #VirtualThreads #ProjectLoom #Multithreading #JavaDevelopers #CleanCode #SoftwareEngineering #DailyLearning #CodingHumor #InterviewPrep

🚀 Java 21 — Virtual Threads Java 21 quietly brought a game-changer for concurrency — Virtual Threads. If you’ve ever fought with Thread.sleep(), blocking I/O, or scaling your app under load, this one’s for you. Traditional Threads — The Old Way In classic Java, when you run: new Thread(() -> {   // some task }).start(); You’re creating an OS-level thread. Each one is heavy — it consumes memory (around 1MB stack space by default) and limited by the operating system. On a typical machine, you can only handle a few thousand concurrent threads before performance drops. That’s why frameworks (like Spring WebFlux or Reactive Streams) were created — to avoid blocking and manage concurrency efficiently. Virtual Threads — The New Way Java 21 introduces Virtual Threads (via Project Loom). They are lightweight, user-mode threads managed by the JVM, not the operating system. Creating millions of them? Totally fine. Each virtual thread takes only a few KBs of memory and doesn’t block the OS thread when waiting (e.g., for I/O). Traditional vs Virtual Threads 🔸 Traditional Thread Example ExecutorService executor = Executors.newFixedThreadPool(100); for (int i = 0; i < 1000; i++) {   executor.submit(() -> {     doDatabaseCall(); // blocking   }); } Here, we’re limited by 100 OS threads. If 100 tasks are waiting on I/O, others must wait. 🔸 Virtual Thread Example ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor(); for (int i = 0; i < 1000; i++) {   executor.submit(() -> {     doDatabaseCall(); // blocking   }); } Each task runs on its own virtual thread — even if it’s blocking, it doesn’t “occupy” an OS thread. The JVM smartly parks and resumes threads as needed. Result: ✅ Scales effortlessly ✅ Simpler, synchronous code ✅ No reactive complexity Virtual Threads make high concurrency simple again. You can now write plain, readable, blocking code — and still handle massive workloads efficiently. 👋 Have you tried Virtual Threads yet in Java 21?

🔥 Tricky Java / Production Bug — The ThreadLocal Memory Leak (a.k.a. The Silent Killer of Threads 😅) Picture this: You’re working at Microsoft, your microservice is running smooth as butter 🧈... until suddenly, memory usage starts climbing like it just got promoted 🚀 You open your monitoring dashboard — GC is running fine, no OutOfMemoryError yet... but the heap looks like it’s hoarding sessions from the Windows XP era 👀 Welcome to the sneaky world of ThreadLocal memory leaks 🧵 💡 The Sneaky Cause: You use ThreadLocal to store request-specific data (user info, correlation ID, transaction state). But you forget the golden rule: threadLocal.remove(); Your thread pool reuses threads — and guess what stays behind? 👉 Old values. Since ThreadLocalMap keeps weak keys but strong values, once the key is GC’ed, the value just… hangs there. Forever. Leaking memory byte by byte 💀 🧠 Example: ThreadLocal<UserContext> context = new ThreadLocal<>(); void process(UserContext ctx) { context.set(ctx); // Business logic here... context.remove(); // 🧹 Mandatory cleanup! } 🔍 Debugging Tips (When You Suspect ThreadLocal Trouble): 1️⃣ Use a heap dump tool like Eclipse MAT or VisualVM — search for ThreadLocalMap. 2️⃣ Look for “unreachable” keys with large retained sizes. 3️⃣ Check if threads in the pool are holding references to old request objects. 4️⃣ Enable GC logs or use a memory profiler — rising heap after GC = red flag 🚩 5️⃣ Watch for “slow leaks” — this one creeps up over hours or days, not minutes. 🧾 Quick Checklist for Safe ThreadLocal Usage: ✅ Always call remove() after use. ✅ Avoid storing heavy objects (like sessions, big collections). ✅ Prefer request-scoped beans or dependency injection where possible. ✅ Review all ThreadLocal usage before deploying to prod. ✅ Don’t assume frameworks will clean it up for you — they won’t 😏 🎯 Final Thought: ThreadLocal is like caffeine ☕ — great in moderation, disastrous when overused. Use it smartly, clean it up religiously. Otherwise, your memory leak will show up in the next sprint review saying: > “Hi, I’m still here… and I brought more heap!” 😜 #Java #SpringBoot #ThreadLocal #MemoryLeak #Microsoft #TrickyInterviewQuestion #BackendEngineering #Concurrency #Debugging #ProductionBug #JavaDeveloper #CodingHumor

🚀 The 3 Java Maps That Outperformed HashMap (and Made My Code 3× Faster) Most Java developers swear by HashMap. It’s our go-to. Reliable. Familiar. Always the first choice. But here’s the thing 👉 HashMap isn’t always the best tool for the job. A few months ago, I was chasing down latency issues in a high-traffic service. After hours of profiling, the culprit wasn’t a slow DB, not network lag… It was a plain old HashMap. Turns out, using the wrong map in the wrong place can quietly crush performance. So I replaced it — and my code ran 3× faster. Here are the 3 hidden gems that changed everything 👇 1️⃣ WeakHashMap — The Self-Cleaning Cache 🧹 Most developers use HashMap for caching. But HashMap never forgets — objects stay until you manually remove them. That’s how memory leaks start. WeakHashMap fixes that by holding weak references to keys. Once a key is no longer referenced elsewhere, the GC wipes it automatically. Map<UserSession, String> cache = new WeakHashMap<>(); cache.put(new UserSession("u123"), "Active"); ✅ Perfect for temporary caches or listeners. ❌ Not for data that must persist. My service’s memory stabilized instantly after switching to it. 2️⃣ IdentityHashMap — When .equals() Betrays You 🧠 Ever had two different objects that look “equal”? HashMap treats them as the same key — because it uses .equals() and .hashCode(). IdentityHashMap doesn’t. It uses reference equality (==). Map<Object, String> map = new IdentityHashMap<>(); map.put(new String("Hello"), "A"); map.put(new String("Hello"), "B"); System.out.println(map.size()); // 2 This saved me from hours of debugging “why is my key missing?” nightmares. ✅ Great for frameworks, DI containers, parsers. ❌ Avoid if logical equality is intended. 3️⃣ EnumMap — The Ferrari of Fixed Keys 🏎️ If your keys are enums, stop using HashMap. Seriously. EnumMap is backed by an array, not hashes.That means O(1) lookups and zero overhead. enum Status { NEW, PROCESSING, DONE } Map<Status, String> map = new EnumMap<>(Status.class); map.put(Status.NEW, "Queued"); In my benchmarks, it was 2–3× faster than HashMap for enum keys. ✅ Type-safe, compact, and blazing fast. ❌ Only for enum-based keys. ⚡ Quick Decision Guide Goal Use This Map -------------------- ----------------- Auto-cleanup WeakHashMap Compare by reference IdentityHashMap Enum keys EnumMap General purpose HashMap  🧩 The Bigger Lesson We obsess over frameworks, cloud, and architecture — but sometimes raw data structures make the biggest difference. The right Map can reduce GC pressure, CPU load, and subtle equality bugs. The wrong one can silently waste thousands of cycles per second. So next time, pause before typing new HashMap<>(). There might be a better tool for that job. #Java #Performance #CleanCode #SystemDesign #HashMap #Collections #BackendDevelopment #ProgrammingTips

#Java_Concurrency Imagine your computer is like a super busy ice cream shop. A long time ago, computers were like a tiny shop with just one worker named Single-Core Steve. If you wanted a big sundae and your friend wanted a popsicle, Steve had to make your entire sundae first before he could even look at your friend's order. This is synchronous programming - doing one thing at a time. But today's computers are like a huge ice cream shop with many workers - maybe Dual-Core Dana, Quad-Core Quinn, and Octa-Core Oscar all working together! Now when you order your sundae and your friend orders a popsicle, different workers can help you both at the same time. This is called concurrency. Java gives us special tools to manage all these workers. Let me explain these tools using our ice cream shop story. First, we have Runnable. Think of this as an order slip where you write down exactly what needs to be done. It's like writing: "Step 1: Scoop vanilla ice cream. Step 2: Add hot fudge. Step 3: Add sprinkles." Next, we have Threads. These are our actual workers. When we create a new thread and give it a Runnable, we're basically hiring a new worker and handing them instructions. When we call thread.start(), it's like telling the worker "Go ahead, start making this order!" But here's where things get tricky. What if there's only one hot fudge machine and two workers both need it at the same time? They might bump into each other! This is called a race condition. To solve this, Java gives us synchronized. Think of this as putting a special lock on the hot fudge machine. Only one worker can hold the lock at a time. If Worker Dana gets to the machine first, she takes the lock. When Worker Quinn arrives, he sees the lock is taken and has to wait patiently until Dana finishes. Now, what if hundreds of customers show up at once? If we hired a new worker for every single customer, we'd have chaos! That's why smart shop owners use a manager called ExecutorService. Instead of creating new workers for every task, we have a manager who maintains a team of workers (a thread pool). When we have a new task, we give it to the manager, who assigns it to the next available worker. So to summarize: Threads are workers, Runnable is their instruction sheet, synchronized is the lock that prevents fights, and ExecutorService is the smart manager. Java concurrency ensures our digital ice cream shop runs efficiently and serves customers quickly!

☕🚀 Java 17 – The Modern LTS Every Developer Should Know! Java 17 is one of the most powerful Long-Term Support (LTS) releases — packed with modern language improvements, performance boosts, and cleaner code practices. Here are the top features you should know 👇 🔹 1️⃣ Sealed Classes What it is: A sealed class restricts which other classes can extend or implement it. Why it’s useful: Helps you control your class hierarchy — making code safer and easier to maintain. public sealed class Shape permits Circle, Rectangle { } public final class Circle extends Shape { } public final class Rectangle extends Shape { } ✅ Restricts unwanted subclassing ✅ Improves security and maintainability 🔹 2️⃣ Pattern Matching for Switch (Preview) Before Java 17: Objects weren’t compatible with switch. Now: You can directly use objects and the compiler automatically casts them for you! In Java 17: switch (obj) {   case String s -> System.out.println("String length: " + s.length());   case Integer i -> System.out.println("Integer value: " + i);   case null -> System.out.println("Null value");   default -> System.out.println("Unknown type"); } ✅ No explicit casting ✅ Type-safe & null-safe ✅ Cleaner, modern syntax 🔹 3️⃣ Strong Encapsulation of JDK Internals Java 17 hides internal APIs (like sun.misc.*) to improve security and modularity. Previously, many developers used these internal classes — leading to unsafe, unstable code. sun.misc.* --> Unsafe memory ops --> Hidden sun.reflect.* --> Reflection internals --> Hidden sun.security.* --> Security helpers --> Hidden 🔹 4️⃣ Support for macOS/AArch64 ✅ Native support for Apple Silicon (M1/M2 Macs). 💡 Faster performance and better compatibility for macOS developers. 🔹 5️⃣ Foreign Function & Memory API (Incubator) What it is: Lets Java call native libraries safely without using old JNI. Why it matters: Faster, cleaner, and safer interoperability with C/C++ code. 🔹6️⃣ Enhanced Random API Java 17 improves the Random API for more flexible random number generation: Random random = new Random(); random.ints(5, 0, 100).forEach(System.out::println); ✅ Generates multiple numbers in a range ✅ Cleaner and stream-friendly 7️⃣ New macOS Rendering Pipeline New rendering pipeline improves graphics performance for Swing/JavaFX apps on macOS 🍏 8️⃣ Other Key Improvements 🗑️ Applet API removed (legacy feature cleanup) ⚙️ GC improvements (G1, ZGC performance boost) 🧩 Removed experimental AOT/JIT compilers for simpler JVM structure 🔍 Summary Java 17 focuses on: ✨ Cleaner, safer, maintainable code (Sealed Classes, Pattern Matching) 🧠 Modern platform support (Apple Silicon, rendering updates) 🛡️ Security & modularity (Strong encapsulation) ⚡ Performance optimization (Better GC & APIs) #Java17 #JavaLTS #Programming #SoftwareDevelopment #CleanCode #JavaDevelopers #FullStackDevelopment #TechTrends #CodingTips #JavaFeatures #JavaFullStackDevelopment #BackendDevelopment #CodeWithMohan

SOLID PRINCIPLES IN CORE JAVA you are a backend engineer, you have to understand the SOLID principle without any exception. I have received multiple dms asking me to explain it in an understandable way. So here we go. Save this, you'll thank me later. SOLID is a set of five design principles that help developers create software that is easy to maintain, understand, and extend. Think of this like rules for building with lego bricks, and shouldn't fall apart when you add a new piece. →S - Single Responsibility Principle A class should have only one job or one reason to change. How I remember: A screwdriver is designed to drive screws. It's not also a hammer and a saw. If you make it do too many things, it becomes complex and hard to use properly. →O - Open/Closed Principle Software should be open for extension, but closed for modification. Means one should be able to add new features without changing the existing, tested code. How I remember: Your phone is "closed" because you can't change its core operating system. But it's "open" cause one can extend its functionality by installing new apps from the Play/App Store without breaking the phone. →L - Liskov Substitution Principle If you have a class A, any class B that inherits from A should be able to replace A without causing any errors. In short, child classes should be perfectly substitutable for their parent classes. How I remember: If you have a universal remote control designed for a "TV," it should work whether you're pointing it at a Samsung TV or an LG TV. You can substitute one type of TV for another, and the remote still works as expected →I - Interface Segregation Principle Clients should not be forced to depend on interfaces or methods they do not use. It's better to have many small, specific interfaces than one large, general-purpose one. How I remember: When you go to a restaurant, you don't get one giant menu with every food item in the world. You get a breakfast menu, a lunch menu, or a dessert menu. You only see what's relevant to you at that moment →D - Dependency Inversion Principle High-level modules (your main business logic) should not depend on low-level modules (like a specific database or a payment gateway). Both should depend on abstractions (like a generic Database interface). How I remember: You don't wire a lamp directly into your house's electrical system. Instead, the lamp has a standard plug, and your wall has a standard socket. The plug and socket (the abstraction) allow you to switch out the lamp for any other appliance without rewiring your house.