在Java SDK 并发包底下，有Lock和Condition的实现，Lock有获取锁和释放锁的条件。那么为什么在有synchronized隐式锁的条件下，还要增加Lock这种需要手动释放锁的情况。
产生的意义是什么？
首先线程去获取锁时在synchronized条件下，如果线程未获取到锁，那么线程会阻塞。
如果线程进入了阻塞状态啥也干不了，也释放不了线程本身占用的资源。
而往往我们需要的是如果线程获取不到锁，也不要进入阻塞状态，去释放掉本身的资源。
于是，大牛们就想重新设计一把锁，这把锁应该具有以下几个点：
1.能够响应中断。如果synchronized获取不到锁，进入了阻塞状态。此时如果发生了死锁，那么将没有任何机会来唤醒阻塞的线程。于是，希望进入阻塞的锁，能相应中断信号，把它唤醒。
2.支持超时。如果线程在一段时间内都获取不到锁，那么就直接返回即可，不要阻塞。这样也有机会释放之前的锁和资源。
3.非阻塞的获取锁。如果线程尝试获取锁失败，那么直接返回false即可。不用进入阻塞状态。
体现三个方法上
// 支持中断的 API
void lockInterruptibly()
throws InterruptedException;
// 支持超时的 API
boolean tryLock(long time, TimeUnit unit)
throws InterruptedException;
// 支持非阻塞获取锁的 API
boolean tryLock();
【Lock和Condition】同时，如何保证可见性呢？
在Lock里面的有个属性state加了volatile关键字。可以根据
顺序性
volatile变量规则
传递性规则导致可见。
用锁的最佳实践
- 永远只在更新对象的成员变量时加锁
- 永远只在访问可变的成员变量时加锁
- 永远不在调用其他对象的方法时加锁
Lock和Condition实现起来，线程等待和通知需要调用await(),signal(),signalAll().不能用错到Object的wait(),notify().notifyAll().
