本节说的可能并不好。该篇我看了三遍也没能完全看懂，于是自己搜索java管程相关的技术文章，才大致对管程有了个认知，总结如下：
1.管程是一种概念，任何语言都可以通用。
2.在java中，每个加锁的对象都绑定着一个管程（监视器）
3.线程访问加锁对象，就是去拥有一个监视器的过程。如一个病人去门诊室看医生，医生是共享资源，门锁锁定医生，病人去看医生，就是访问医生这个共享资源，门诊室其实是监视器（管程）。
4.所有线程访问共享资源，都需要先拥有监视器。就像所有病人看病都需要先拥有进入门诊室的资格。
5.监视器至少有两个等待队列。一个是进入监视器的等待队列一个是条件变量对应的等待队列。后者可以有多个。就像一个病人进入门诊室诊断后，需要去验血，那么它需要去抽血室排队等待。另外一个病人心脏不舒服，需要去拍胸片，去拍摄室等待。
6.监视器要求的条件满足后，位于条件变量下等待的线程需要重新在门诊室门外排队，等待进入监视器。就像抽血的那位，抽完后，拿到了化验单，然后，重新回到门诊室等待，然后进入看病，然后退出，医生通知下一位进入。

总结起来就是，管程就是一个对象监视器。任何线程想要访问该资源，就要排队进入监控范围。进入之后，接受检查，不符合条件，则要继续等待，直到被通知，然后继续进入监视器。

重新回答思考题，问题变成wait的timeout参数是否必要。

在MESA模型中，线程T1被唤醒，从条件A的等待队列中（其实是一个set，list的话可能会重复）移除，并加入入口等待队列，重新与其他的线程竞争锁的控制权。那么有这样一种可能，线程T1的优先级比较低，并且经常地有高优先级的线程加入入口等待队列。每次当它获得锁的时候，条件已经不满足了（被高优先级的线程抢先破坏了条件）。即使T1可以得到调度，但是也没办法继续执行下去。

最后T1被饿死了（有点冷。。。）

另外我刚才的问题想通了。不需要实现像lock一样的条件对象，并调用condition.await(). Synchronized用判断条件+wait（）就可以了。

感谢老师的精彩分享，谈一下个人对信号量和管程的理解。

信号量机制是可以解决同步/互斥的问题的，但是信号量的操作分散在各个进程或线程中，不方便进行管理，因每次需调用PV操作，还可能导致死锁或破坏互斥请求的问题。

管程是定义了一个数据结构和能为并发所执行的一组操作，这组操作能够进行同步和改变管程中的数据。这相当于对临界资源的同步操作都集中进行管理，凡是要访问临界资源的进程或线程，都必须先通过管程，由管程的这套机制来实现多进程或线程对同一个临界资源的互斥访问和使用。管程的同步主要通过condition类型的变量（条件变量），条件变量可执行操作wait()和signal()。管程一般是由语言编译器进行封装，体现出OOP中的封装思想，也如老师所讲的，管程模型和面向对象高度契合的。

好记性不如烂笔头
管程定义：
管理共享内存和操作共享内存的过程，令其支持并发。

并发编程领域两大难题，互斥和同步。

互斥如何保证：封装共享数据及其对应操作，每个操作任意时刻只允许一个线程执行。

同步如何保证：使用MESA模型。

MESA模型之前没接触过，只是能够按照老师的思路顺下来，还没有深刻的理解，希望老师在接下来的文章中，加深MESA的使用😄