简述：Java SDK 并发包通过 Lock 和 Condition 两个接口来实现管程，其中 Lock 用于解决互斥问题，Condition 用于解决同步问题。
再造管程的理由和期望
- 理由：synchronized 没有办法解决“破坏不可抢占条件方案”。 原因是synchronized 申请资源的时候，如果申请不到，线程直接进入阻塞状态了，无法释放线程占有的资源。
- 期望：对于“不可抢占”这个条件，占用部分资源的线程进一步申请其他资源时，如果申请不到，可以主动释放它占有的资源，这样不可抢占这个条件就破坏掉了。
重新设计一把互斥锁去解决这个问题（三个功能）
- 能够响应中断
- 如果阻塞状态的线程能够响应中断信号，能够唤醒它，那它就有机会释放曾经持有的锁 A。这样就破坏了不可抢占条件了。
- 支持超时
- 如果线程在一段时间之内没有获取到锁，不是进入阻塞状态，而是返回一个错误，那这个线程也有机会释放曾经持有的锁。这样也能破坏不可抢占条件。
- 非阻塞的获取锁
- 如果尝试获取锁失败，并不进入阻塞状态，而是直接返回，那这个线程也有机会释放曾经持有的锁。这样也能破坏不可抢占条件。
-
如何保证可见性
- Java SDK 里面 Lock 的使用，有一个经典的范例，就是try{}finally{}，需要重点关注的是在 finally 里面释放锁。
- 它是利用了 volatile 相关的 Happens-Before 规则。Java SDK 里面的 ReentrantLock，内部持有一个 volatile 的成员变量 state，获取锁的时候，会读写 state 的值；解锁的时候，也会读写 state 的值（简化后的代码如下面所示）。也就是说，在执行 value+=1 之前，程序先读写了一次 volatile 变量 state，在执行 value+=1 之后，又读写了一次 volatile 变量 state。根据相关的 Happens-Before 规则：
- 顺序性规则：对于线程 T1，value+=1 Happens-Before 释放锁的操作 unlock()；
- volatile 变量规则：由于 state = 1 会先读取 state，所以线程 T1 的 unlock() 操作 Happens-Before 线程 T2 的 lock() 操作；
- 传递性规则：线程 T1 的 value+=1 Happens-Before 线程 T2 的 lock() 操作。
后续线程T2能够看到value的正确规则
