Java开发之高并发必备篇（六）——Lock和ReentrantLock（1）

在java面试中，多线程的安全锁的问题其实不仅仅局限于synchronized，还会被问到lock锁以及代表子类ReentrantLock可重入锁。

1、Lock锁介绍

从JDK1.5之后，

在java.util.concurrent.locks包下提供了另外一种方式来实现线程同步访问，那就是Lock锁。

之前介绍了synchronized虽然在jdk1.6之后对它进行了优化和升级，但是它还是有一些明显的缺陷：

当一个线程持有了一个同步代码的锁时，如果执行过程中遇到了IO或者其他的耗时操作（例如：sleep等）的时候，它的锁并没有被释放；这样其他的线程还需要等待它的执行那么就会非常的影响执行效率。

如果在执行某个任务的时候，我们需要当满足一个条件的时候就释放掉锁让其他线程执行任务，因为synchronized是自动获取和释放锁的所以这样的情况下synchronized也无法实现。

当多个线程读写文件或数据的时候，我们知道如果出现了有的线程读有的线程写的时候或者多个线程都写都会导致冲突；但是如果多个线程只是读的话就不存在冲突问题，这一个时候使用synchronized也只是可以一个线程进行读操作效率很低，无法到达当多个线程进行读操作的时候不冲突的情况。

synchronized是java内置的关键字，并且它不需要用户手动获取锁，当代码执行完毕或者出现了未捕获的异常那么JVM也会让线程自动释放锁。

而Lock锁是java定义的一个接口，它提供比使用synchronized方法和语句可以获得的更广泛的锁定操作，锁的获取和释放需要手动，这样可以更加灵活的操作锁，使用Lock锁能以更优雅的方式处理线程同步的问题。下面我们就来了解下这个Lock接口。

2、Lock接口

通过查看源码，我们发现Lock接口中定义了6个方法，介绍如下：

3、ReentrantLock可重入锁介绍

ReentrantLock类是Lock接口常用的实现子类，它是一个可重入互斥的Lock。

ReentrantLock提供了更多的锁操作，它的构造函数接受可选的公平参数，参数为true则表示获取一个公平锁，不带参数或者false表示一个非公平锁。

平锁的情况下，线程按照先进先出(FIFO)的顺序获取锁资源，但是按照顺序执行不一定是CPU资源的最大化利用；

非公平锁的情况下，拥有锁的线程在释放锁资源的时候, 当前尝试获取锁资源的线程可以和等待队列中的第一个线程竞争锁资源已达到资源的最大化利用，但是如果已经进入等待队列的线程还是按照FIFO的顺序执行。

4、公平锁代码实现：

5、非公平锁源码：

这两个类都是Sync类的子类，而Sync类又是AbstractQueuedSynchronizer（简称AQS）的子类，在获取锁的时候都调用了AQS中定义的acquire方法；

而acquire方法中核心就是tryAcquire()方法，在FairSync和NonfairSync中都重写了这个方法，所以看看这两个的不同。

通过上面源码截图，我们可以看到首先都是判断 AQS 中的 state 是否等于 0，0 表示目前没有其他线程获得锁，当前线程就可以尝试获取锁，如果队列中没有线程就利用 CAS 来将 AQS 中的 state 修改为1，也就是获取锁；

如果state大于0表示锁已经被获取了，那就判断下获取锁的线程是否是当前线程，如果是当前线程那么state+1这也表现出了ReentrantLock 的可重入性。

而公平锁和非公平锁不一样的地方是，在state=0的时候多了一个

hasQueuedPredecessors()的判断，我们查看它的代码分析；

这里的代码是用来来判断 AQS 的队列中是否有其他线程，如果有则不会尝试获取锁，这样也就保证了获取锁的线程的顺序执行。

下篇文章我们将介绍如何使用lock锁来获取锁、释放锁等操作。