Java Multithreading Deadlocks and Performance Issues

When a system creates too many threads for small tasks, it can waste CPU and memory resources. Day 23 of my Low Level Design journey. Today I learned about Thread Pools and Executors in Java. Instead of creating a new thread for every task, a Thread Pool reuses a fixed number of threads to execute tasks efficiently. I learned about: • execute(Runnable) → Fire and forget tasks • submit(Runnable/Callable) → Returns Future to track task status • newFixedThreadPool() • newCachedThreadPool() • newSingleThreadExecutor() This approach helps in: • Better resource management • Improved performance • Controlled thread creation • Scalable concurrent systems Key takeaway: Thread Pool manages threads, while Executor manages task execution. Day 23 ✅ #LearningInPublic #LowLevelDesign #Multithreading #Concurrency #Java #SystemDesign #SoftwareEngineering #TakeUForward

Race Condition : happens when multiple threads access and modify shared data at the same time, and the final result depends on the timing of execution. example: int count = 0; public void increment() { count++; } two threads execute count++ simultaneously: Both read count = 0 Both increment to 1 Both write back 1 Final result = 1 instead of 2 Problem: Data inconsistency Unpredictable results Solution: Use synchronization (synchronized) Use locks (ReentrantLock) Use atomic classes (AtomicInteger) Thread Starvation : thread is “waiting forever” while others keep running. example: Thread t1 = new Thread(task); t1.setPriority(Thread.MAX_PRIORITY); Thread t2 = new Thread(task); t2.setPriority(Thread.MIN_PRIORITY); t2 may rarely or never execute. problem: Some threads never complete Solution: ReentrantLock lock = new ReentrantLock(true); #Java #BackendDevelopment #SoftwareEngineering #MultiThreading #Concurrency #JavaPerformance #CodingTips #Programming #SystemDesign

More threads ≠ faster system. It often makes it slower. Most devs don’t realize this until production. 🔹 What actually happens ❌ Context switching increases ❌ Threads spend time waiting ❌ Memory overhead grows 👉 Result: performance drops 🔹 Quick Reality Check 👉 CPU-bound → threads ≈ cores 👉 IO-bound → slightly more threads Anything beyond that = diminishing returns 🔹 What about Virtual Threads? Java’s Virtual Threads (Project Loom): ✔ Lightweight ✔ Handle massive concurrency ✔ Reduce thread management overhead BUT 👇 👉 They don’t remove CPU limits 👉 Bad design will still hurt performance 🔹 Real Insight Multithreading is not about more threads It’s about right threads 🔹 Quick Interview Questions 1️⃣ What is context switching? 2️⃣ CPU-bound vs IO-bound? 3️⃣ How to decide optimal thread count ? 4️⃣ What are Virtual Threads? 5️⃣ Can more threads reduce performance? 🔹 Final Thought 👉 Platform threads need control 👉 Virtual threads need understanding 💬 Be honest: Are you overusing threads in your system? #Java #Multithreading #Performance #VirtualThreads #Backend

#Post9 In last post(https://lnkd.in/ddzdPfvQ), we learned about selecting optimal number of threads for our process. Common assumption is, a thread is either running or not. In reality, a thread spends most of its life NOT running. To understand multithreading properly, we need to understand the lifecycle of a thread. Let’s break it down. 1. New A thread is created but not started yet. Thread t = new Thread(); At this point, it’s just an object in memory. 2. Runnable Once you call start(), the thread becomes ready to run. It doesn’t mean it is running immediately. It simply means it is waiting for CPU scheduling. 3. Running When the CPU scheduler picks the thread, it starts executing. This is the state where actual work happens. 4. Blocked A thread enters this state when it is trying to acquire a lock, but another thread already holds it. Until the lock is released, the thread cannot proceed. 5. Waiting A thread goes into this state when wait() is called. • It pauses execution indefinitely • Releases the monitor lock • Becomes runnable again only after notify() or notifyAll() 6. Timed Waiting A thread waits for a specific amount of time. Examples: • sleep() • join() • wait(timeout) Important detail: • sleep() does NOT release the lock • wait(timeout) releases the lock 7. Terminated The thread has finished execution. Once terminated, it cannot be started again. Below is a reference diagram of the thread lifecycle. We will revisit this as we go deeper into concepts like start(), wait(), and synchronization Key takeaway A thread is not constantly running. In real systems, most threads are: • Waiting • Blocked • Or ready to run Understanding this helps build the foundation for: • Debugging concurrency issues • Avoiding deadlocks • Writing efficient multithreaded code In the next post, we will look at different ways to create threads in Java. #Java #Multithreading #Concurrency #BackendDevelopment #SoftwareEngineering

𝐓𝐡𝐫𝐞𝐚𝐝 𝐒𝐚𝐟𝐞𝐭𝐲 - 𝐭𝐡𝐞 𝐛𝐮𝐠 𝐭𝐡𝐚𝐭 𝐥𝐢𝐞𝐬 𝐪𝐮𝐢𝐞𝐭𝐥𝐲 𝐮𝐧𝐭𝐢𝐥 𝐩𝐞𝐚𝐤 𝐭𝐫𝐚𝐟𝐟𝐢𝐜. Multiple threads sharing the same memory is powerful. It is also dangerous. 𝐖𝐡𝐚𝐭 𝐢𝐬 𝐢𝐭? When two threads read and write the same variable at the same time the result becomes unpredictable. This is called a Race Condition. No crash. No exception. Just silently wrong results. A payment processed twice. A counter off by thousands. A balance that never adds up. 𝐖𝐡𝐞𝐧 𝐝𝐨𝐞𝐬 𝐢𝐭 𝐡𝐚𝐩𝐩𝐞𝐧? → Shared counters updated by multiple threads → Shared collections read and written simultaneously → Singleton beans with mutable state in Spring → Cached values updated without synchronization 𝐇𝐨𝐰 𝐭𝐨 𝐩𝐫𝐞𝐯𝐞𝐧𝐭 𝐢𝐭? → Use Atomic types for simple counters and flags → Use immutable objects wherever possible → Use thread-safe collections like ConcurrentHashMap → Avoid shared mutable state entirely when you can → Scope variables locally - local variables are always safe 𝐓𝐡𝐞 𝐦𝐢𝐧𝐝𝐬𝐞𝐭 𝐬𝐡𝐢𝐟𝐭: Stop asking "does this work?" Start asking "what happens when 1000 threads hit this simultaneously?" Thread safety bugs don't show in unit tests. They show in production at the worst possible moment. #Java #ThreadSafety #Concurrency #RaceCondition #BackendEngineering

#day24 🛠️ Debugging multithreading — what happens in production Concurrency bugs don’t always show in development — they appear in production ⚠️ 👉 Key tools I explored: Thread dump (jstack) VisualVM / JConsole Java Flight Recorder 👉 Common issues: Deadlocks High CPU usage Thread contention 💡 Example insight: Too many BLOCKED threads → lock contention → performance bottleneck 👉 Fix: reduce synchronization or use concurrent structures #Java #Multithreading #Debugging #PerformanceTuning #Concurrency #JavaDeveloper #InterviewPreparation #LearningInPublic

Day 65/100: Today I took another topic of LLD i.e. #Concurrency. Concurrency is nothing but dealing with multiple things at the same time. Every modern software system deals with concurrency. Your phone runs dozens of apps simultaneously. A web server handles thousands of requests at once. In Golang we can achieve concurrency using goroutines whereas in other programming languages like java we have multithreading concept for concurrency. When we talking about concurrency there is always confusion between concurrency and parallelism. Concurrency is about organizing code to handle many tasks in overlapping time periods. Parallelism involves performing multiple tasks at the same exact time, usually on different CPU cores. In concurrency we have to discover some important terms related to it. Race condition: A race condition occurs when the behavior of a program depends on the relative timing of events, such as the order in which threads are scheduled. When two or more threads access shared data concurrently, and at least one modifies it, the final result depends on who "wins the race" to access the data first. Deadlock: A deadlock is a state where a set of threads is blocked because each thread is holding a resource and waiting for a resource held by another thread in the set. Mutex: Mutex is a synchronization primitive that provides mutual exclusion. When a thread acquires (locks) a mutex, any other thread that tries to acquire the same mutex will block until the first thread releases (unlocks) it. The thread that locks must be the one to unlock. Concurrency Patterns: Thread Pool Pattern Producer-Consumer Pattern Fork-Join Pattern FanIn/out Pattern Time to do it again tomorrow :) #systemdesign #100daysofcode #softwareengineering #consistency

𝐉𝐚𝐯𝐚 𝐏𝐞𝐫𝐟𝐨𝐫𝐦𝐚𝐧𝐜𝐞: 𝐒𝐭𝐫𝐞𝐚𝐦𝐬 𝐯𝐬 𝐅𝐨𝐫 𝐋𝐨𝐨𝐩 When it comes to processing collections in Java, both Streams and For Loops have their place. 𝐒𝐭𝐫𝐞𝐚𝐦𝐬 Cleaner & more readable Functional programming style Great for parallel processing Slightly higher CPU usage due to abstraction 𝐅𝐨𝐫 𝐋𝐨𝐨𝐩 Better performance (lower CPU usage) More control & flexibility Ideal for performance-critical code 𝐓𝐚𝐤𝐞𝐚𝐰𝐚𝐲: Use Streams for readability & maintainability. Use For Loops when performance is critical. Smart developers choose based on the use-case, not trends. Follow Madhu K. for more such Java & backend insights #Java #Performance #BackendDevelopment #CodingTips #SoftwareEngineering

Over the Easter break I wrapped up my Operating Systems assignment for the master’s program: a Java CPU scheduling simulator (FCFS, non-preemptive SJF, SRTF, static priority, Round Robin), file-based input, metrics on the console, and a layered layout plus Strategy-style algorithms. Tests with JUnit/Mockito and Maven for the build. The repo stays private until the submission deadline (31 May); I’ll open it afterward for anyone who wants to browse the code. Project's gituhub: https://lnkd.in/dWHA4nyG Here's a spoiler of the chosen architecture design: #OperatingSystems #GradSchool #Masters #Java #UFMS #FACOM

Your threads are not slow… they are just waiting. Most developers blame performance. But the real culprit is often #thread #contention. 🔹 What’s actually happening? Multiple threads → fighting for the same resource Only one wins → others just sit idle (blocked) 👉 CPU is free 👉 Threads exist 👉 But work is NOT happening 🔹 Common Mistake synchronized(this) { // heavy logic + DB calls + API calls } ❌ You just locked EVERYTHING ❌ Other threads are now waiting unnecessarily 🔹 Fix (Simple but Powerful) 👉 Keep critical section as small as possible synchronized(this) { // only shared resource logic } Move heavy work outside the lock 🔹 Real Insight Performance issue ≠ slow code It’s often → threads waiting for locks 🔹 Some Interview Questions 1️⃣ What is thread contention? 2️⃣ How does synchronization impact performance? 3️⃣ What is a critical section? 4️⃣ How can you reduce contention in Java? 5️⃣ Difference between blocking and waiting threads? 🔹 Key Takeaway 👉 More threads ≠ faster system 👉 Less blocking = better performance 💬 Have you ever debugged a “slow” system that turned out to be locking? #Java #Multithreading #Performance #Backend #InterviewPrep