为什么需要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();
	int value;
	public void addOne() {
		// 获取锁
		rtl.lock();
		try {
			value+=1;
		} finally {
			// 保证锁能释放
			rtl.unlock();
		}
	}
}

Lock中保证可见性的原理是：利用了 volatile 相关的 Happens-Before 规则。Java SDK 里面的 ReentrantLock，内部持有一个 volatile 的成员变量 state，获取锁的时候，会读写 state 的值；解锁的时候，也会读写 state 的值（代码如下面所示）。也就是说，在执行 value+=1 之前，程序先读写了一次 volatile 变量 state，在执行 value+=1 之后，又读写了一次 volatile 变量 state。根据相关的 Happens-Before 规则：

1. 顺序性规则：对于线程 T1，value+=1 Happens-Before 释放锁的操作 unlock()；
2. volatile 变量规则：由于T1线程释放锁时的setState()操作Happens-Before 与线程T2的获取锁时的getState()操作，所以线程 T1 的 unlock() 操作 Happens-Before 线程 T2 的 lock() 操作；
3. 传递性规则：因此线程 T1 的 value+=1 Happens-Before 线程 T2 的 lock() 操作。（也就是线程T1对value的更改操作对线程T2是可见的）

		private volatile int state;

    /**
     * Returns the current value of synchronization state.
     * This operation has memory semantics of a {@code volatile} read.
     * @return current state value
     */
    protected final int getState() {
        return state;
    }
    /**
     * Sets the value of synchronization state.
     * This operation has memory semantics of a {@code volatile} write.
     * @param newState the new state value
     */
    protected final void setState(int newState) {
        state = newState;
    }
    //获取锁
	final boolean nonfairTryAcquire(int acquires) {
          	final Thread current = Thread.currentThread();
            int c = getState();//读取state值
            if (c == 0) {
                if (compareAndSetState(0, acquires)) {
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            else if (current == getExclusiveOwnerThread()) {
                int nextc = c + acquires;
                if (nextc < 0) // overflow
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);//更新state值
                return true;
            }
            return false;
        }

    protected final boolean tryRelease(int releases) {
            int c = getState() - releases;//读取state值
            if (Thread.currentThread() != getExclusiveOwnerThread())
                throw new IllegalMonitorStateException();
            boolean free = false;
            if (c == 0) {
                free = true;
                setExclusiveOwnerThread(null);
            }
            setState(c);//更新state值
            return free;
        }

什么时候才使用锁

三个用锁的最佳时机：

1. 永远只在更新对象的成员变量时加锁
2. 永远只在访问可变的成员变量时加锁
3. 永远不在调用其他对象的方法时加锁

Lock与synchronized的区别

1. Lock是一个接口，而synchronized是Java中的关键字，synchronized是内置的语言实现；
2. synchronized在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生；而Lock在发生异常时，如果没有主动通过unLock()去释放锁，则很可能造成死锁现象，因此使用Lock时需要在finally块中释放锁；
3. 能够响应中断：Lock可以让等待锁的线程响应中断，而synchronized却不行，使用synchronized时，等待的线程会一直等待下去，不能够响应中断；
4. 支持超时：Lock支持超时获取锁，超时后释放资源，synchronized是永久阻塞等待
5. 非阻塞地获取锁：Lock支持非阻塞地获取锁，synchronized是阻塞地获取锁
6. Lock可以提高多个线程进行读操作的效率。（可以通过readwritelock实现读写分离）
7. 性能上来说，在资源竞争不激烈的情形下，Lock性能稍微比synchronized差点（编译程序通常会尽可能的进行优化synchronized）。但是当同步非常激烈的时候，synchronized的性能一下子能下降好几十倍。而ReentrantLock确还能维持常态。