notify()会立刻释放锁么?

矫情吗；* 2022-12-26 10:24 169阅读 0赞

大佬问我: **notify()会立刻释放锁么?**

我的内心戏: 肯定会啊! 这么简单的问题?

![f32929581b0b18859a10b0c9f037b16d.png][]

image

聪明如我, 决定装小白, 回答: **不会?**

大佬: **很好, 小伙子基础不错!**

我:

![9cf9411a9365ae4876d7068b2535e4ee.png][]

image

大佬: **说说为什么**

我: ………………

![f59f432286ccf653882c251d02251284.png][]

image

于是, 有了这篇文章!

问题的根本原来在于 “**立刻**”这个描述词!

如果你和咸鱼君一样懵逼, 不妨往下看!

技术大佬可以告辞了!!

**接下来, 我们深入的分析分析wait和notify**

## 前言 ##

前面介绍了Synchronized关键词的原理与优化分析，Synchronized的重要不言而喻, 而作为配合Synchronized使用的另外两个关键字也显得格外重要.

今天, 来聊聊配合Object基类的

*  **wait()**
 *  **notify()**

这两个方法的实现,为多线程协作提供了保证。

## wait() & notify() ##

Object 类中的 wait&notify 这两个方法，其实包括他们的重载方法一共有 5 个，而 Object 类中一共才 12 个方法，可见这 2 个方法的重要性。

我们先看看 JDK 中的定义：

public final native void notify();

其中有 3 个方法是 native 的，也就是由虚拟机本地的 c 代码执行的。

> ps: native 即 JNI,Java Native Interface,
> 
> Java平台提供的用户和本地C代码进行互操作的API

有 2 个 wait 重载方法最终还是调用了 wait（long）方法。

wait方法

> wait是要释放对象锁，进入等待池。  
> 既然是释放对象锁，那么肯定是先要获得锁。  
> 所以wait必须要写在synchronized代码块中，否则会报异常。

notify方法

> 也需要写在synchronized代码块中,  
> 调用对象的这两个方法也需要先获得该对象的锁.  
> notify,notifyAll, 唤醒等待该对象同步锁的线程,并放入该对象的锁池中.  
> 对象的锁池中线程可以去竞争得到对象锁,然后开始执行.  
>   
> 如果是通过notify来唤起的线程,  
> 那进入wait的线程会被随机唤醒;  
> (注意: 实际上, hotspot是顺序唤醒的!! 这是个重点! 有疑惑的点击传送[大佬问我: notify()是随机唤醒线程么?][notify]

)

> 如果是通过notifyAll唤起的线程,  
> 默认情况是最后进入的会先被唤起来,即LIFO的策略;

比较重要的是:

**notify()或者notifyAll()调用时并不会真正释放对象锁, 必须等到synchronized方法或者语法块执行完才真正释放锁.**

举个例子:

public void test()
    {
        Object object = new Object();
        synchronized (object){
            object.notifyAll();
            while (true){
            }
        }
    }

如上, 虽然调用了notifyAll, 但是紧接着进入了一个死循环。

这会导致一直不能出临界区, 一直不能释放对象锁。

所以，即使它把所有在等待池中的线程都唤醒放到了对象的锁池中，

但是锁池中的所有线程都不会运行，因为他们始终拿不到锁。

## 案例分析 ##

为了说明wait() 和notify()方法的功能,

我们举个例子

public class WaitNotifyCase {
    
    public static void main(String[] args) {
      final Object lock = new Object();
    
      new Thread(new Runnable() {
          @Override
          public void run() {
              System.out.println("线程 A 等待 获得 锁");
              synchronized (lock) {
                  try {
                      System.out.println("线程 A 获得 锁");
                      TimeUnit.SECONDS.sleep(1);
                      System.out.println("线程 A 开始 执行 wait() ");
                      lock.wait();
                      System.out.println("线程 A 结束 执行 wait()");
                  } catch (InterruptedException e) {
                      e.printStackTrace();
                  }
              }
          }
      }).start();
    
      new Thread(new Runnable() {
          @Override
          public void run() {
              System.out.println("线程 B 等待 获得 锁");
              synchronized (lock) {
                  System.out.println("线程 B 获得 锁");
                  try {
                      TimeUnit.SECONDS.sleep(5);
                  } catch (InterruptedException e) {
                      e.printStackTrace();
                  }
                  lock.notify();
                  System.out.println("线程 B 执行 notify()");
              }
          }
      }).start();
    }
    }

执行结果：

线程 A 等待 获得 锁
    线程 A 获得 锁
    
    线程 B 等待 获得 锁
    
    线程 A 开始 执行 wait()
    
    线程 B 获得 锁
    线程 B 执行 notify()
    
    线程 A 结束 执行 wait()

使用时切记：**必须由同一个lock对象调用wait、notify方法**

*  当线程A执行wait方法时，该线程会被挂起；
 *  当线程B执行notify方法时，会唤醒一个被挂起的线程A；

**lock对象、线程A和线程B三者是一种什么关系？**

根据上面的案例，可以想象一个场景：

*  lock对象维护了一个等待队列list；
 *  线程A中执行lock的wait方法，把线程A保存到list中；
 *  线程B中执行lock的notify方法，从等待队列中取出线程A继续执行；

## 几个疑问 ##

### 问题一: 为何wait&notify必须要加synchronized锁? ###

从实现上来说，这个synchronized锁至关重要!

正因为这把锁，才能让整个wait/notify运转起来.

当然我觉得其实通过其他的方式也可以实现类似的机制,

不过hotspot至少是完全依赖这把锁来实现wait/notify的.

static void Sort(int [] array) {
        // synchronize this operation so that some other thread can't
        // manipulate the array while we are sorting it. This assumes that other
        // threads also synchronize their accesses to the array.
        synchronized(array) {
            // now sort elements in array
        }
    }

synchronized代码块通过javap生成的字节码中包含monitorenter 和 monitorexit 指令

如下图所示：

![bc0209a6ae738233cda99df9a202bf19.png][]

image

执行monitorenter指令可以获取对象的monitor，

而lock.wait()方法通过调用native方法wait(0)实现，其中接口注释中有这么一句：

> The current thread must own this object's monitor.

表示线程执行 lock.wait() 方法时，必须持有该lock对象的monitor.

### 问题二: 为什么wait方法可能抛出InterruptedException异常? ###

这个异常大家应该都知道，当我们调用了某个线程的interrupt方法时，对应的线程会抛出这个异常;

wait方法也不希望破坏这种规则，

因此就算当前线程因为wait一直在阻塞，当某个线程希望它起来继续执行的时候，它还是得从阻塞态恢复过来;

而wait方法被唤醒起来的时候会去检测这个状态，当有线程interrupt了，它就会抛出这个异常从阻塞状态恢复过来。

这里有两点要注意：

1.  如果被interrupt的线程只是创建了，并没有start，那等他start之后进入wait态之后也是不能会恢复的；
2.  如果被interrupt的线程已经start了，在进入wait之前，如果有线程调用了其interrupt方法，那这个wait等于什么都没做，会直接跳出来，不会阻塞；

### 问题三: notify执行之后立马唤醒线程吗? ###

其实hotspot里真正的实现是: 退出同步块的时候才会去真正唤醒对应的线程; 不过这个也是个默认策略，也可以改的，在notify之后立马唤醒相关线程。

### 问题四: notifyAll是怎么实现全唤起所有线程? ###

或许大家立马就能想到一个for循环就搞定了，不过在JVM里没实现这么简单，而是借助了monitorexit.

上面提到了当某个线程从wait状态恢复出来的时候，要先获取锁，然后再退出同步块;

所以notifyAll的实现是调用notify的线程在退出其同步块的时候唤醒起最后一个进入wait状态的线程;

然后这个线程退出同步块的时候继续唤醒其倒数第二个进入wait状态的线程，依次类推.

同样这这是一个策略的问题，JVM里提供了挨个直接唤醒线程的参数，不过很少使用, 这里就不提了。

### 问题五: wait的线程是否会影响性能? ###

这是个大家比较关心的话题.

wait/nofity 是通过JVM里的 park/unpark 机制来实现的，在Linux下这种机制又是通过pthread\_cond\_wait/pthread\_cond\_signal 来实现的;

因此当线程进入到wait状态的时候其实是会放弃cpu的，也就是说这类线程是不会占用cpu资源。

作者：咸鱼君0808  
链接：https://www.jianshu.com/p/ffc0c755fd8d  
来源：简书  
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

[f32929581b0b18859a10b0c9f037b16d.png]: /images/20221120/4a462a195e7744529e5334e6c9037a73.png
[9cf9411a9365ae4876d7068b2535e4ee.png]: /images/20221120/6d675899094043fb8109a34233bda24a.png
[f59f432286ccf653882c251d02251284.png]: /images/20221120/73c999b4291143d9bf615b63f6e17804.png
[notify]: https://www.jianshu.com/p/99f73827c616
[bc0209a6ae738233cda99df9a202bf19.png]: https://img-blog.csdnimg.cn/img_convert/bc0209a6ae738233cda99df9a202bf19.png