有了Synchronized为什么还需要Lock

在并发编程领域，有两大核心问题:互斥、同步
互斥：指的是同一时刻只允许一个线程访问共享资源。
同步：指的是线程之间的通信和协作。
这两大问题用管程(monitor,是操作系统中的一个重要概念)都能解决。
Java 关键字Synchronized 已经是管程的一个实现了，那为什么Java SDK并发包还需要搞一个Lock来实现管程呢？这不是重复了嘛？

我们先来看下死锁产生的四个必要条件：
1、互斥：某共享资源一次只允许一个线程占有。
2、占有且等待：一个线程本身占有资源（一种或多种），同时还有资源未得到满足，则不会释放已有的资源。
3、不可抢占：其他线程不能抢占已被别的线程占有的资源。
4、循环等待：线程A等待线程B的资源，线程B等待线程A的资源，这就是循环等待。

只要这4个条件都满足就会发生死锁，也就是说这4个条件我们只要破环一个就不会发生死锁，然而Synchronized无法破环不可抢占条件，因为Synchronized申请资源的时候，如果申请不到，线程就直接进入阻塞状态，进入阻塞状态就啥事都干不了了，所以也释放不了已经占有的资源。
所以就搞了个Lock。Lock搞了3种方法来破环不可抢占的条件。
1、void lockInterruptibly() throws InterruptedException; 这是个支持中断的API。Synchronized进入阻塞之后就没办法唤醒它，所以针对这个问题想了个支持响应中断的方法，让线程阻塞(lock下是等待状态)的时候可以响应中断信号，从而有机会释放已占有的资源来破环不可抢占的条件。
2、boolean tryLock();这就是在获取锁的时候，如果获取不到就直接返回，这样也有机会释放已占有的资源来破环不可抢占的条件。
3、boolean tryLock(long time, TimeUnit unit) throws InterrptedException;这是个支持超时的API，也就是让在一段时间内获取不到资源的线程直接返回一个错误，不进入阻塞状态，那也有机会释放已占有的资源来破环不可抢占的条件。
然后再来说说Lock的实现类一共有三个，一个是ReentrantLock,另两个是ReentrantReadWriteLock类中的两个静态内部类ReadLock和WriteLock。实现思路大同小异。
我来简单说说ReentrantLock，它是利用了volatile 的Happens-Before规则来保证了可见性，ReentrantLock内部持有一个volatile成员变量state,每次获取锁的时候会读写state的值，每次解锁的时候也会读写state的值。看下缩减的示意代码

volatile int state;
lock() {
state = 1;
}
unlock() {
state = 0;
}

volatile 变量规则：对volatile变量的写操作Happens-Before 于后面对这个变量的读操作。
来看个例子:

private final Lock lock = new ReentrantLock();
int a;
public void addOne() {
lock.lock();
try{
a = getA()+1;
} finally {
lock.unlock();
}
}
public int getA() {
lock.lock();
try{
return a;
} finally {
lock.unlock();
}
}

假设现在有两个线程A和B
1、根据程序次序规则:线程A中a = getA()+1;Happens-Before 于lock.unlock();
2、根据volatile 变量规则:来看lock方法，state=1,它首先是会读取state的值，而unlock执行state=0,对state进行了写操作。所以线程A执行了unlock操作，那么根据volatile 变量规则，它是Happens-Before 线程B的lock操作。
3、根据传递性规则：所以线程A中a = getA()+1;Happens-Before线程B的lock操作。所以线程A中加一之后结果是对线程B可见的！

总结

所以Lock提供了这三种方式来弥补Synchronized的不足使得我们能写出更加安全，健壮的代码。

本文地址：https://blog.csdn.net/bjmsb/article/details/108242456