Я прочитал ответ в следующем сообщении: Разница между состояниями WAIT и BLOCKED thread Тем не менее, я все еще озадачен.
Я хочу знать, в чем разница на уровне JVM и в чем разница на уровне ЦП.
Есть ли у обоих из них «переключатель контекста потока»? , что быстрее в многопоточной среде?
Предполагая, что вы спрашиваете о разнице между состояниями Thread.State.BLOCKED и Thread.State.WAITING (т.е. как возвращается t.getState())?
Я хочу знать, в чем разница на уровне jvm и какая разница в процессоре
Работая снизу вверх, на аппаратном уровне нет никакой разницы, потому что эти состояния не являются аппаратными концепциями. WAITING threads и BLOCKED threads вообще не используют ресурсы процессора. Если центральный процессор не выполняет код вашей программы, то он либо выполняет код, принадлежащий какому-то другому процессу, либо операционной системе; или же он находится в состоянии простоя, которое не имеет ничего общего с Java или JVM.
Затем вы пропустили слой — операционную систему. Все практические JVM реализуют потоки Java, используя примитивы потоков, предоставляемые операционной системой.
В операционной системе каждый поток представлен объектом, который содержит всю информацию, которую ОС должна знать о потоке. Когда поток выполняется на некотором ЦП, объект сообщает ОС, какой ЦП и как долго он работает и т. д. Когда поток не выполняется, объект содержит моментальный снимок состояния ЦП, который необходимо восстановить, чтобы сделать поток запустить еще раз.
Каждый объект потока в ОС можно найти в одном из нескольких контейнеров: есть один контейнер, который содержит набор всех запущенных потоков, и есть другие контейнеры (в основном очереди), содержащие неработающие потоки.
Обычно существует очередь выполнения, содержащая потоки, готовые к запуску, но ожидающие запуска ЦП. Затем существует очередь для каждого мьютекса (также известная как замок), которая содержит потоки, ожидающие входа в этот мьютекс, очередь для каждой переменной условия, которая содержит потоки, ожидающие получения notify()d об этом условии и т. д.
Всякий раз, когда какой-либо поток покидает мьютекс, операционная система просматривает очередь для этого мьютекса. Если очередь не пуста, он выбирает поток из этой очереди и перемещает его в очередь выполнения. Всякий раз, когда какой-либо поток вызывает o.notify(), ОС выбирает один поток из очереди этой условной переменной и перемещает его в очередь выполнения или, если программа вызывает notifyAll(), ОС перемещает все потоки из этой очереди в очередь выполнения.
Итак, на уровне ОС вопрос не столько в том, в каком состоянии находится поток, сколько в том, в какой очереди находится поток.
Наконец, на уровне JVM сказать особо нечего, потому что JVM позволяет ОС выполнять практически всю работу. Java предоставляет два состояния, РАБОТАЕТ и ОЖИДАЕТСЯ просто для удобства вас, программиста, на тот случай, если вам будет полезно знать разницу. (Подсказка: это особенно интересно, когда вы просматриваете дамп программы и пытаетесь выяснить, что каждый поток делал в это время.)
Состояние ожидания — это когда поток намеренно вызывает метод wait(). Это означает, что он ожидает завершения некоторого события/действия. Как будто вы идете в службу поддержки, а очередь пуста. Вы ждете, пока ваша жена приедет с гарантийным талоном. Значит, вы намеренно ждете.
Но в состоянии BLOCKED поток готов к запуску, но по какой-то причине его заблокировали другие события. Как поток собирается войти в синхронизированный блок, но есть другой поток, который в настоящее время выполняется внутри синхронизированного блока на том же объекте.
Другим примером является несколько потоков, называемых методом ожидания завершения некоторого события. Как только это событие завершено, вызывается notifyAll(). Тогда только один поток получит цикл ЦП, другие все равно будут заблокированы.
Это похоже на то, что вы идете в службу поддержки клиентов, а представителя клиента нет. Вы заблокированы.
