并发问题的万能钥匙 - 管程
并发问题是一个IT界的公共问题，不是java语言独有的。而对于业界的公共问题，一般都会有纯理论支撑。
比如对于网络问题，有很多的论文和RFC文件。
对应到并发领域，业界有两种解决方案，一种是信号量，一种是管程。操作系统原理中指出，信号量可以解决一切的并发问题。而管程和信号量本质上是等价的，管程可以实现信号量，信号量也可以实现管程。
由于相对于信号量来说，管程使用起来更为简单，所以Java选择了管程。
管程的含义
管程，对应英文 Monitor，可以将其翻译成“监视器”（直译），也可以将其翻译成“管程”（意译，操作系统领域一般都使用这个翻译）。
所谓管程，指的是管理共享变量以及对共享变量的操作过程，让他们支持并发。对于 Java 来说，就是管理类的成员变量和成员方法，让这个类变成线程安全的。
管程模型
有三种管程模式，Hasen 模型、Hoare 模型和 MESA 模型，MESA 应用最广泛，Java也是按MESA模型来实现管程的，所以我们只关心MESA模型
核心要素
有两大问题需要解决，1、互斥；2、同步
管程模型 MESA 解决互斥问题的方法
将线程不安全的共享变量（或者说对象）封装起来，对外提供线程安全的操作。下图中最外层的框就代表封装的意思。要想操作线程不安全的共享变量queue，只能通过提供的线程安全的enq()和deq()方法。
管程模型 MESA 解决同步问题的方法
一些概念：
入口等待队列（一个）、条件变量及其等待队列（一个或者多个）
条件变量及其等待队列相关的一些操作：
wait()、notify()、notifyAll()
（下图中）框的上面只有一个入口，并且在入口旁边还有一个入口等待队列，所谓的“框”就是管程的边界。
当多个线程同时试图进入管程内部时，只允许一个线程进入，其他线程则在入口等待队列中等待。
管程里还引入了条件变量的概念，而且每个条件变量都对应有一个等待队列，如下图，条件变量 A 和条件变量 B 分别都有自己的等待队列。
那条件变量和条件变量等待队列的作用是什么呢？其实就是解决线程间的同步问题。
大致过程：
当一个线程试图进入管程内部时，需要获取锁，如果获取成功则进入管程内部，如果获取失败则进入入口等待队列。
当锁资源被释放时（不管怎么释放的，正常释放、因为wait而释放、因为响应了中断而释放都可以，这里不需要关心），入口等待队列中会有一个线程抢到（或者说得到锁，怎么说视具体策略而定）锁，从而进入管程内部。
成功进入管程内部的线程（称为线程1），可以正常执行管程内部的代码。如果管程内部的代码中包含调用了某个条件变量的wait()方法，则线程1执行完这个条件变量的wait()方法之后，会进入这个条件标量对应的条件等待队列、并释放锁资源。
当其他线程（称为线程2）获取到锁后，会进入管程内部，如果执行到了上面那个条件变量的notifyAll()方法，则线程1会被唤醒，被从条件等待队列移入入口等待队列。
Java 对管程的实现
synchronized实现了管程（ObjectMonitor）
JUC实现的管程（AQS）
两者在实现上的差异
synchronized 中是一个入口等待队列、一个条件等待队列。只能调Object的wait()方法，只对应一个条件变量。
AQS 中是一个入口等待队列、多个条件等待队列。能通过Lock，new 出多个 Condition（条件变量，每个条件变量对应一个条件等待队列）。
Java都是按MESA模型来实现管程的
1：互斥锁均是基于MESA管程模型的，e.g：synchronized，ReentrantLock等。
2：管程内部的条件变量是基于锁的，因此JUC下的Condition是通过Lock而来的，即Condition = lock.newCondition()。
3：JUC 通过 Lock 和 Condition 两个接口来实现管程，其中 Lock 用于解决互斥问题，Condition 用于解决同步问题。
注：这里的几句和上面描述的好像有点对不起来，没关系，都是对的，不用太纠结
重度参考
https://time.geekbang.org/column/article/86089
https://www.jianshu.com/p/daebf979c502
https://xiaomi-info.github.io/2020/03/24/synchronized/
https://juejin.cn/post/6844904146127044622