线程状态被阻止和等待之间的区别 [英] difference between Thread state blocked and waiting
问题描述
我已经通过以下信息阅读了答案: WAIT和BLOCKED之间的差异线程状态 但是，我仍然感到困惑.
我想知道JVM级别有什么区别，CPU级别有什么区别.
这两个都有线程上下文切换"吗? ，在多线程环境中哪个更快?
假设您要询问状态Thread.State.BLOCKED和Thread.State.WAITING(即，由t.getState()返回的状态)之间的区别?
我想知道jvm级别有什么区别，CPU上有什么区别
自下而上地工作，在硬件级别没有区别，因为那些状态不是硬件概念.等待线程和阻塞线程根本不使用CPU资源.如果CPU没有运行您程序的代码，则它要么运行的代码属于某个其他进程，要么属于操作系统；否则，它可能正在运行.否则它处于空闲状态，与Java或JVM无关.
然后，您跳过了一层操作系统.所有实用的JVM都使用操作系统提供的线程原语来实现Java线程.
在操作系统中，每个线程都由一个对象表示，该对象包含OS需要了解的有关该线程的所有信息.当某个线程在某个CPU上运行时，该对象会告诉OS哪个CPU以及它运行了多长时间等.当一个线程不在运行时，该对象包含必须恢复的CPU状态的快照才能使该CPU处于运行状态.线程再次运行.
可以在几个容器之一中找到OS中的每个线程对象:有一个容器可以容纳所有正在运行的线程，而还有其他容器(主要是队列)可以容纳未运行的线程./p>
通常有一个 run队列，其中包含准备运行的线程，但这些线程正在等待CPU运行.然后，每个 mutex (又名 lock )都有一个队列，其中包含等待输入该互斥量的线程，每个 condition变量都有一个队列.保存正在等待关于该条件的notify() d等的线程.
每当某个线程离开互斥锁时，操作系统就会在该队列中查找该互斥锁.如果队列不为空，则从该队列中选择一个线程并将其移至运行队列.每当某些线程调用o.notify()时，操作系统就会从该条件变量的队列中选择一个线程并将其移至运行队列，或者，如果程序调用了notifyAll()，则操作系统会将所有线程从该队列移至运行队列.
因此，在OS级别上，与线程所在的 state 问题无关，而只是针对哪个 queue 是线程的问题.
最后，在JVM级别上，没有什么可说的了，因为JVM使OS可以完成几乎所有的工作. Java提供了RUNNING和WAITING这两种状态，只是为了给程序员带来方便，以防您知道它们之间的区别. (提示:当您查看程序的转储，并试图弄清楚每个线程当时在做什么时，这最有意思.)
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.)
这篇关于线程状态被阻止和等待之间的区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
