Thread.join()是否释放锁定？还是继续坚持下去？

Question

据我了解,内部obj.join()调用wait().这意味着join()始终释放锁(因为wait()在调用后总是释放锁).

API文档解释说:

此实现使用一系列this.wait调用条件 this.isAlive.当一个线程终止时,该this.notifyAll方法被调用.建议应用程序无法使用wait,notify或 notifyAll在Thread实例.

人们在这里SO说,join()不会释放任何锁定,因为API没有提到它明确.但这种逻辑对我来说似乎很奇怪.

这是join()代码中的主要逻辑:

 while (isAlive()) {
            wait(0);
        }

这个网站进一步增加了混乱(我认为他们错了):

3)wait()和join()方法之间的第三个区别是,当一个线程调用该wait()方法时,它释放为wait()被调用的对象保留的任何锁,但是调用该join()方法不会释放任何监视器或锁.

Answer 1

wait释放保持在wait被调用对象上的监视器,但不释放任何其他监视器.

当前线程必须拥有此对象的监视器.该线程释放该监视器的所有权并等待[...].

换句话说,给出以下内容:

synchronized (a) {
    synchronized (b) {
        b.wait();
    }
}

在b.wait(),当前线程释放b的监视器,但不是a监视器.

如果t.join()是在t.wait()内部使用,则t在等待时释放监视器,但不释放任何其他监视器.

顺便提一下,这个join实现是一个漏洞抽象的例子.如果Thread使用a private final Object monitor;来代替,我们可以说join没有发布监视器,即使它在wait内部使用而我们不知道.没有理由记录使用的实现细节wait,因为我们无法访问监视器,因此我们不需要了解它.

我们知道内部join使用的原因wait是最初编写方法的人选择了我们可以访问的监视器.这就需要揭示实现细节.join实际上不应该从我们的角度发布监视器,只是等待一个线程完成,但是选择了一个实现,这需要我们比我们应该知道更多.