等待JVM处理的对象锁导致线程处于阻塞状态答案

【问题标题】：How is a thread in blocked state caused by waiting on a objects lock handled by the JVM等待JVM处理的对象锁导致线程处于阻塞状态
【发布时间】：2011-06-15 05:34:37
【问题描述】：

我已经看到线程可以通过不同的方式进入阻塞状态。我很想知道线程处于阻塞状态后究竟会发生什么。它如何回到运行状态。如果它被 sleep(time) 阻塞，那么它会在 time 毫秒后移动到可运行队列。如果它在 I/O 操作上被阻塞，一旦完成，它就会进入可运行队列。它在等待对象锁时如何进入可运行队列。它如何知道它等待的对象上的锁现在可用。有人还可以解释 I/O 上的阻塞线程如何工作的内部结构吗？如果我对上述任何主题的理解不正确，请纠正我..

谢谢

【问题讨论】：

标签： java multithreading synchronized blocked

【解决方案1】：

它在等待对象锁时如何到达可运行队列？

如果线程由于试图进入synchronized 块而被阻塞，当另一个线程（持有锁）通过退出同一对象的synchronized 块来释放锁时，该线程会自动标记为可运行.

如果当前线程由于调用someObject.wait()而被阻塞，当另一个线程调用someObject.notify()时，该线程被“释放”。

在字节码级别它看起来如下：

[load some object, obj, onto the operand stack]
monitorenter  // grab the lock

// do stuff

[load obj onto the operand stack again] 
monitorexit   // release the lock

如果其他人已经持有obj 的锁，则线程将挂起monitorenter，直到其他线程调用monitorexit。

JLS 没有具体说明应该如何实现monitorenter 和monitorexit。也就是说，它依赖于 JVM/OS。

更多详情，请参考JLS Wait Sets and Notifications。

【讨论】：

假设有一些线程处于就绪状态（即未运行但可运行）和一些处于阻塞状态的线程等待获取相同的锁。一旦该锁被正在运行的线程释放，是否有可能，从就绪状态的线程移动到运行状态，然后在执行一些执行后获取已释放的锁，而处于阻塞状态的线程没有机会在这里重新获取已释放的锁锁？

【解决方案2】：

AFAIK JVM 使用本机线程。因此，管理线程调度和上下文切换的是操作系统而不是 JVM。

您可以查看实际的 JVM 源代码。它已经打开了。

【讨论】：

如果您明确提到 Suns/Oracles Hotspot JVM，您可能需要澄清这一点。
关于 JVM 源的帖子：stackoverflow.com/questions/2026093/…

【解决方案3】：

在接近代码的层面上，它看起来像这样：

线程 1：

Object mutex = new Object();
....
synchronized(mutex) {
    //lock to mutex is acquired.
    mutex.wait(); //lock to mutex is released. Thread is waiting for somebody to call notify().
    doSomething();
}

线程 2：

synchronized(Thread1.mutex) {
    //acquires the lock on mutex. 
    //Can be done only after mutex.wait() is called from Thread1
    // and the lock is released
    Thread1.mutex.notify(); // notifies Thread1 that it can be resumed.
}

一般你应该记住 Thread.sleep() 持有资源的锁，但是 Thread.wait() 释放锁并且可以被其他线程通知。

【讨论】：