Difference Between Wait and Blocked Thread States

Difference between WAIT and BLOCKED thread states

A thread goes to wait state once it calls wait() on an Object. This is called Waiting State. Once a thread reaches waiting state, it will need to wait till some other thread calls notify() or notifyAll() on the object.

Once this thread is notified, it will not be runnable. It might be that other threads are also notified (using notifyAll()) or the first thread has not finished his work, so it is still blocked till it gets its chance. This is called Blocked State. A Blocked state will occur whenever a thread tries to acquire lock on object and some other thread is already holding the lock.

Once other threads have left and its this thread chance, it moves to Runnable state after that it is eligible pick up work based on JVM threading mechanism and moves to run state.

difference between Thread state blocked and waiting

Assuming that you asking the difference between the states Thread.State.BLOCKED and Thread.State.WAITING (i.e., as returned by t.getState())?

I want to know what is the difference on jvm level and what difference on the CPU

Working from the bottom up, there is no difference at the hardware level because those states are not hardware concepts. WAITING threads and BLOCKED threads do not use CPU resources at all. If a CPU is not running your program's code, then it is either running code that belongs to some other process or, to the operating system; or else it is in an idle state that has nothing to do with Java or JVMs.

---

Then, you skipped a layer--the operating system. All practical JVMs implement Java threads by using threading primitives that are provided by the operating system.

In the operating system, every thread is represented by an object that holds all of the information that the OS needs to know about the thread. When a thread is running on some CPU, the object tells the OS which CPU and how long it's been running, etc. When a thread is not running, the object contains a snapshot of the CPU state that must be restored in order to make the thread run once more.

Every thread object in the OS can be found in one of several containers: There is one container that holds the set of all running threads, and there are other containers (queues mostly) that hold the threads that are not running.

Typically there is a run queue holding the threads that are ready to run, but which are waiting for a CPU to run on. Then there is a queue for each mutex (a.k.a., lock) that holds threads waiting to enter that mutex, a queue for each condition variable that holds threads that are waiting to be notify()d about that condition, etc.

Whenever some thread leaves a mutex, the operating system looks at the queue for that mutex. If the queue is not empty, it picks a thread from that queue and moves it to the run queue. Whenever some thread calls o.notify(), the OS picks one thread from that condition variable's queue and moves it to the run queue or, if the program calls notifyAll(), the OS moves all of the threads from that queue to the run queue.

So, at the OS level, it's not so much a question of what state is the thread in, as it is a question of which queue is the thread in.

---

Finally, at the JVM level, there's not much left to say because the JVM lets the OS do pretty much all of the work. Java provides the two states, RUNNING and WAITING merely as a convenience to you, the programmer, in case it is useful for you to know the difference. (Hint: It's mostly interesting when you're looking at a dump of the program, and trying to figure out what each thread was doing at the time.)

What is the difference between Thread.State: WAITING (parking) vs BLOCKED at sun.misc.Unsafe.park()

Thread states - here is a little explanation of the thread states.

NEW
The thread has not yet started.

RUNNABLE
The thread is executing in the JVM.

BLOCKED
The thread is blocked waiting for a monitor lock.

WAITING
The thread is waiting indefinitely for another thread to perform a particular action.

TIMED_WAITING
The thread is waiting for another thread to perform an action for up to a specified waiting time.

TERMINATED
The thread has exited.

The BLOCKED state should be concerning if it's there for a long period for the same threads.
This of course depends on your case - how you process data, how you create threads (and thread pools), what are your critical sections and how all that interacts with each other.

Single thread dump of the production is not enough - you should take several dumps and
- compare what happens and
- for how long the threads are running/waiting
- is this occurs on high load or after high load
- does your thread count increases over long time, etc.

So there is no way to tell that 500 blocked threads at this particular point in time is good or bad but for sure it's concerning. One thread takes around ~2MB just to initialize & allocate so it's 1GB of memory.

It's highly likely that there are some critical sections that are held by some threads that cause your problem and unresponsiveness of your application. You can potentially have some really complex situation reading from queues using blocking methods, etc.

Possible course of action:

• Make several dumps and compare - what has changed? What threads are still blocked?
• Check if you can pinpoint the invocations in the blocked threads (is somewhere your package prefix or java's/hazelcast's packges only) in the stacktrace in the dump.
• Check with tracking tools (flight-recorder / jvisualvm) the growth of the threads and when they (which are getting blocked) are created - what the app is doing at that moment?
• Analyse your codebase on the potential misuse of the blocking calls and synchronized methods/uses.
• Check thread pools maximum sizes & worker queue implementations and strategies when the limit is reached (e.g. to understand look at implementations of RejectedExecutionHandler)

What is the difference between thread states and process states?

What I learned is if a process got blocked, it will be swapped out to the disk and wait for wake-up event.

You're probably reading some very old documentation. Likely by "process" it means something scheduled by the kernel.

But, if a process can have multiple threads, what if a thread is blocked? For example, one of the threads waits for a keyboard event, the thread will be blocked. Then will the process also be blocked, or is it possible that only the thread is blocked and process is running?

If you define a "process" as a container that consists of an address space, file descriptor set and so on and that can contain more than one thread, then there is no such thing as a process being blocked. What would block a process exactly?

Java Thread wait() = blocked?

The thread is WAITING until it is notified. Then it becomes BLOCKED trying to reenter the synchronized region until all other threads have left.

Relevant parts from the link you posted (about WAITING):

For example, a thread that has called Object.wait() on an object is waiting for another thread to call Object.notify() or Object.notifyAll() on that object.

and (about BLOCKED):

A thread in the blocked state is waiting for a monitor lock to [...] reenter a synchronized block/method after calling Object.wait.

The last part occurs when the thread tries to return from wait(), but not until then.

How does I/O-methods like read() put a Thread in blocked state in java?

It doesn't change the state of the thread to BLOCKED

public static void main(String[] args) throws IOException {
    Thread main = Thread.currentThread();
    new Thread(() -> {
        for (int i = 0; i < 10; i++) {
            System.out.println(main + " is in "+main.getState()+" state");
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                throw new AssertionError(e);
            }
        }
    }).start();
    System.in.read();
}

prints

Thread[main,5,main] is in RUNNABLE state
Thread[main,5,main] is in RUNNABLE state
Thread[main,5,main] is in RUNNABLE state
Thread[main,5,main] is in RUNNABLE state
Thread[main,5,main] is in RUNNABLE state
Thread[main,5,main] is in RUNNABLE state
Thread[main,5,main] is in RUNNABLE state
Thread[main,5,main] is in RUNNABLE state
Thread[main,5,main] is in RUNNABLE state
Thread[main,5,main] is in RUNNABLE state

instead the OS doesn't return from the read until there is some data and the OS decides whether and when to context switch the thread/process.

How does the JVM notify the thread that it can continue when data in the resource its trying to read, is available again?

The OS wakes the thread when there is more data or the stream has been closed. The JVM doesn't get involved.

Java thread state transition, WAITING to BLOCKED, or RUNNABLE?

Any diagram that shows a notify invocation bringing a thread from WAITING to RUNNABLE is wrong (or is using an unclarified shortcut). Once a thread gets awoken from a notify (or even from a spurious wakeup) it needs to relock the monitor of the object on which it was waiting. This is the BLOCKED state.

Thread state for a thread blocked waiting for a monitor lock. A thread
in the blocked state is waiting for a monitor lock to enter a
synchronized block/method or reenter a synchronized block/method after
calling Object.wait.

This is explained in the javadoc of Object#notify():

The awakened thread will not be able to proceed until the current
thread relinquishes the lock on this object.

and Object#wait()

The thread then waits until it can re-obtain ownership of the monitor
and resumes execution.

---

Related Topics