为什么需要Lock，而不是直接用synchronized

构建Lock的理由

在解决死锁的时候提出了一个方案是：破坏不可抢占条件，但是这个方案 synchronized 没有办法解决。原因是 synchronized 申请资源的时候，如果申请不到，线程直接进入阻塞状态了，而线程进入阻塞状态，啥都干不了，也释放不了线程已经占有的资源（锁），也就会造成死锁。

但是我们希望的是：

对于“不可抢占”这个条件，占用部分资源的线程进一步申请其他资源时，如果申请不到，可以主动释放它占有的资源，这样不可抢占这个条件就破坏掉了，就可以防止死锁的产生。

有以下三种解决方案：

1. 能够响应中断。synchronized 的问题是，持有锁 A 后，如果尝试获取锁 B 失败，那么线程就进入阻塞状态，一旦发生死锁，就没有任何机会来唤醒阻塞的线程，也就无法释放持有的锁A。但如果阻塞状态的线程能够响应中断信号，也就是说当我们给阻塞的线程发送中断信号的时候，能够唤醒它，那它就有机会释放曾经持有的锁 A。这样就破坏了不可抢占条件了。
2. 支持超时。如果线程在一段时间之内没有获取到锁，不是进入阻塞状态，而是返回一个错误，那这个线程也有机会释放曾经持有的锁。这样也能破坏不可抢占条件。
3. 非阻塞地获取锁。如果尝试获取锁失败，并不进入阻塞状态，而是直接返回，那这个线程也有机会释放曾经持有的锁。这样也能破坏不可抢占条件。

以上三种方案可以全面弥补 synchronized 的问题。这三个方案就是构建Lock的主要原因，体现在 Java的API 上，就是 Lock 接口的三个方法。

// 支持中断的 API
void lockInterruptibly() throws InterruptedException;
// 支持超时的 API
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
// 支持非阻塞获取锁的 API
boolean tryLock();

Lock如何保证可见性

class X {
   
  /** 锁，应是私有的、不可变的、不可重用的。Integer 和 String 类型的对象不适合做锁。如果锁发生变化，就意味着失去了互斥功能。
  Integer 和 String 类型的对象在 JVM 里面是可能被重用的，除此之外，JVM 里可能被重用的对象还有 Boolean，
  重用意味着你的锁可能被其他代码使用，如果其他代码synchronized(你的锁)，而且不释放，那你的程序就永远拿不到锁，这是隐藏的风险。*/
	private final Lock rtl = new ReentrantLock