I have read the answer through the following posting: Difference between WAIT and BLOCKED thread states However, I am still puzzled.
I want to know what is the difference on the JVM level and what is the difference on the CPU level.
Whether both of these have the "Thread Context switch"? , which is faster on a multithreaded environment?
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.)