AI Course
    NEW
    Placements

    Progress

    0%

    What is Software Design?High-Level vs Low-Level Design — Drawing the BoundarySoftware Architecture vs Software DesignFunctional vs Non-Functional RequirementsThe Software Design Process and Design ThinkingCharacteristics of Good Software DesignCommon Software Design MistakesHow to Read and Write Design DocumentsThe Framework: How to Approach LLD Problems

    Introduction to OOP and the Java Memory ModelClasses, Objects, and the this KeywordConstructors and Object InitializationEncapsulation and Access ModifiersAbstraction : Interfaces vs Abstract ClassesInheritance and Its TypesPolymorphism : Compile-Time vs RuntimeAssociation, Aggregation, and CompositionDependency RelationshipsGenerics and Type SafetyThe Golden Rule : Composition Over Inheritance

    Introduction to Design PrinciplesSingle Responsibility PrincipleOpen-Closed PrincipleLiskov Substitution PrincipleInterface Segregation PrincipleDependency Inversion PrincipleDRY, KISS, and YAGNI PrinciplesHigh Cohesion and Loose CouplingLaw of DemeterSeparation of Concerns and Information HidingDesigning for Testability : The Ultimate Proof of Loose Coupling

    Why UML Matters in LLDClass DiagramsSequence DiagramsActivity DiagramsState DiagramsComponent and Object DiagramsUsing UML Effectively in InterviewsCommon UML Mistakes to Avoid

    What Are Design Patterns?History and the Gang of FourCategories of Design PatternsHow to Choose a Design PatternAnti-Patterns and Common MisuseDesign Patterns Interview Strategy

    Creational Patterns OverviewSingleton Pattern: Including Thread-Safe and Bill Pugh ImplementationsFactory Method PatternAbstract Factory PatternBuilder and Fluent Builder PatternPrototype PatternFactory vs Builder : When to Use WhichReal-World Usage of Creational Patterns

    Structural Patterns OverviewAdapter PatternBridge PatternComposite PatternDecorator PatternFacade PatternProxy PatternFlyweight PatternAdapter vs Facade vs ProxyReal-World Usage of Structural Design Patterns — How Spring Security Uses Filters and Proxies

    Behavioral Patterns OverviewStrategy PatternObserver PatternCommand PatternChain of ResponsibilityTemplate Method PatternState PatternMediator PatternIterator PatternMemento PatternVisitor PatternStrategy vs State — Key DifferencesReal-World Usage of Behavioral Patterns

    Introduction to Domain ModelingIdentifying Entities and Value ObjectsAggregates and Aggregate RootsDomain ServicesRepositories in Domain DesignBusiness Rules ModelingDomain EventsDesigning Rich vs Anemic Domain ModelsPutting It Together — Full Domain Model Walkthrough

    Introduction to API Design — Principles and GoalsREST Principles and Resource ModelingDTO Design and Mapping Strategies — MapStruct and JacksonRequest and Response DesignInput Validation DesignError Handling and Standardized Error ResponsesPagination, Filtering and SortingAPI Versioning StrategiesIdempotency in APIsAPI Security BasicsDesigning Internal vs External APIs

    Introduction to Persistence DesignThe Repository Pattern — Spring Data JPA Under the HoodDAO vs Repository PatternTransactions and ACID PropertiesUnit of Work PatternOptimistic vs Pessimistic LockingLazy Loading vs Eager Loading and the N+1 ProblemCaching FundamentalsWrite-Through vs Write-Back vs Cache-AsidePersistence Design Best PracticesDesigning for Data Consistency in Concurrent Systems

    Introduction to Concurrency — Threads vs ProcessesThread LifecycleThread Class vs Runnable vs CallableThe Executor Framework and Thread PoolsSynchronization and LocksReentrantLock and ReadWriteLockSemaphores and Countdown LatchesConcurrent Collections — ConcurrentHashMap and FriendsFuture and CompletableFuture for Async DesignThread Communication — Wait, Notify, NotifyAllCommon Concurrency Problems — Deadlock, Starvation, Race ConditionsDesigning Thread-Safe ClassesConcurrency Design Best Practices

    Introduction to Event-Driven ArchitectureThe Publisher-Subscriber ModelObserver Pattern vs Pub-Sub — Where They DifferEvent Modeling — Designing Good EventsMessage Queues — Concepts and Internal DesignEventual Consistency and What It Means for Object DesignEvent Sourcing — Concepts and When to Use ItCQRS — Command Query Responsibility SegregationCommon Pitfalls in Event-Driven Systems

    Logging Fundamentals and Best PracticesAudit LoggingMonitoring and Metrics DesignHealth ChecksRetry Mechanisms and Backoff StrategiesCircuit Breaker PatternRate Limiting AlgorithmsFeature FlagsDesigning for Observability — Putting It All Together

    How to Approach Any LLD Case Study — The 45-Minute FrameworkDesign a Parking LotDesign an Elevator SystemDesign a Vending MachineDesign an ATM MachineDesign a Chess GameDesign Tic-Tac-ToeDesign Snake and LadderDesign a Library Management SystemDesign a Logging FrameworkDesign an Inventory Management SystemDesign a Car Rental SystemDesign a Hotel Booking SystemDesign a URL ShortenerDesign Splitwise

    Advanced LLD — What Changes at the Senior LevelDesign a Movie Ticket Booking System — Handling Concurrency and LockingDesign an E-Commerce Shopping Cart and Order FlowDesign a Notification System — Internal Class OrchestrationDesign a Rate LimiterDesign a Job SchedulerDesign a Real-Time Chat System — WebSocket Handlers and Message Queues at the Class LevelDesign a Pub-Sub System Like Kafka — Internal Data Structures of the BrokerDesign a Payment Processing SystemRequirement Gathering Techniques for InterviewsIdentifying Entities and Relationships Under PressureChoosing Design Patterns in an InterviewDiscussing Trade-Offs ConfidentlyCommon LLD Interview MistakesMock LLD Interview Walkthrough — End to EndWhat to Do After the Interview — Learning from Every Session

    Thread Lifecycle

    Learning Objectives#

    • Name the six thread states in Java and the transition that moves a thread into each one.
    • Read a thread dump and explain, from the state names, what a stuck thread is actually waiting on.
    • Distinguish BLOCKED from WAITING and the two timers that control them.

    Introduction#

    A thread is not a thing that runs; it is a thing that is sometimes running. Java models that with an explicit set of states, NEW, RUNNABLE, BLOCKED, WAITING, TIMED_WAITING, TERMINATED, and every tool in this chapter is a way of pushing a thread into one of them. Knowing the states is the difference between reading a thread dump and reading a riddle.

    Problem Statement#

    A server hangs. The request thread that used to answer is now idle, and nobody can say whether it is waiting for a lock, waiting for a notification, or just asleep for a while. The team guesses. They restart, it hangs again, and the eventual answer, a single thread stuck in WAITING on an object monitor because the code that was supposed to notify() never ran, takes two days. The six states exist precisely so you never have to guess: the state name tells you what the thread is blocked on, and that is the start of every real diagnosis.

    Core Concept#

    The states are a state machine the JVM drives, and each transition is caused by something concrete.

    StateMeaningHow you get thereHow you leave
    NEWconstructed, not startednew Thread(...)start()
    RUNNABLEready or actually on a CPUstart(), returning from a waitscheduling
    BLOCKEDwaiting to enter a synchronized blocka lock is held by someone elsethe lock is released
    WAITINGwaiting indefinitely for a signalwait(), join(), park()notify()/notifyAll(), unpark
    TIMED_WAITINGwaiting with a deadlinesleep(), wait(timeout), join(timeout)timeout or signal
    TERMINATEDdone or threwrun() returnsnothing

    A thread in RUNNABLE may or may not be executing right now. That state conflates "on a core" and "in the ready queue", which is deliberate, because Java cannot cheaply tell you which. So a busy CPU-bound thread and a thread that keeps getting descheduled both read RUNNABLE, and that is fine, the state is about the ability to run, not about possessing a core.

    The division that matters for debugging is BLOCKED versus WAITING. BLOCKED means the thread wants to enter a synchronized block and the monitor is taken. WAITING means the thread is parked until another thread calls a notifier. The two are different promises: one waits for a lock, the other waits for a wake-up. A thread dump that shows one stuck in WAITING on Object#wait is a thread that is waiting to be told something, and the fix is in the thread that should have told it.

    Diagram: the six states and the transitions between them.

    NEW RUNNABLE BLOCKED WAITING TIMED_WAITING TERMINATED start() lock taken wait(), join() sleep() notify() lock released timeout

    There are a few details in that diagram that deserve a second look. BLOCKED and the lock release arrow is the story of a thread that wants in and waits. The notify() arrow is the story of WAITING. The sleep() path is TIMED_WAITING, and note that sleep does not release any locks you hold, which makes it a common cause of a locked object staying locked. There is no direct state called "deadlock"; a deadlock in a dump appears as a cycle of threads, each BLOCKED on a monitor that the next one in the cycle holds.

    Real Production Usage#

    Thread.currentThread().getState() and, more usefully, a JVM thread dump (jstack, or the kill -3 path, or Thread.dumpAllThreads) are the tools. A healthy pool shows threads parked in WAITING on a pool condition, which is normal. A pool that has run out shows threads in WAITING on the pool's take() forever, which means the pool died or the tasks are stuck. Reading a dump well means asking, of each stuck thread, "is it waiting for a lock, a signal, or a timer?" and each state answers it directly.

    Common Mistakes#

    1. Treating sleep as a way to "pause" a shared object. It does not release the monitor, so other threads stay BLOCKED while the sleeper naps. Sleep and wait are not the same verb.
    2. Reading RUNNABLE as "the thread is on a core." It is not, and chasing a spin that shows RUNNABLE as a hang takes you down a wrong path; the thread may just be repeatedly descheduled.
    3. Confusing BLOCKED with WAITING in a dump. The two need different fixes: release a lock versus send a notification.

    Interview Perspective#

    Interviewers ask the states to see if you can translate a problem into a thread's position. Weak: listing the six names. Strong: "a thread in WAITING is parked for a signal and the fix is the notifier; a thread in BLOCKED is queued on a monitor and the fix is the lock holder." They love asking what sleep does to a held lock, because the person who says "releases it" reveals they memorized the diagram instead of the semantics.

    Follow-up: "what does a deadlock look like in a dump" and "why does RUNNABLE not tell you the thread is running."

    Knowledge Check#

    • A thread is shown in BLOCKED on an object monitor. Name the concrete condition and the concrete fix.
    • Two threads call wait() on the same object. You call notify() once. What is true about the waiters after, and what changes with notifyAll()?
    • A thread does sleep(5000) while holding a lock. What states do other threads take, and why is this not a timeout for them?

    Key Takeaways#

    • The six states are the JVM's answer to "what is this thread doing now," and each names the exact wait.
    • BLOCKED waits on a lock, WAITING waits on a signal, and the fixes are different.
    • sleep does not release the monitor, and RUNNABLE does not mean on a core.

    What's Next#

    Now that a thread has a lifecycle, the next article answers the obvious question: how do you actually create the thing. The thread class versus Runnable versus Callable is the decision every Java program makes first, and the choice changes whether your work can return a value, throw, and be scheduled by a pool.

    Want to Master Spring Boot and Land Your Dream Job?

    Struggling with coding interviews? Learn Data Structures & Algorithms (DSA) with our expert-led course. Build strong problem-solving skills, write optimized code, and crack top tech interviews with ease

    Learn more

    Last updated on Aug 19, 2026

    Was it helpful?

    Subscribe to our newsletter

    Read articles from Coding Shuttle directly inside your inbox. Subscribe to the newsletter, and don't miss out.

    Previous
    Introduction to Concurrency — Threads vs Processes
    Next
    Thread Class vs Runnable vs Callable