java并发编程的艺术（三）---lock源码

 

本文来源于翁舒航的博客，点击即可跳转原文观看！！！（被转载或者拷贝走的内容可能缺失图片、视频等原文的内容）

若网站将链接屏蔽，可直接拷贝原文链接到地址栏跳转观看，原文链接：https://www.cnblogs.com/wengshuhang/p/10200992.html

 

jdk1.5以后，并发包中新增了lock接口，

它相对于synchronized，多了以下三个主要特性：尝试非阻塞地获取锁（尝试获取锁成功则持有）、能被中断地获取锁（锁的进程能响应中断）、超时获取锁（指定时间截止之前获取锁）。

我们看看它接口中定义的api:

获取锁

可中断地获取锁

尝试非阻塞地获取锁，能够获取则返回true，否则false

超时获取锁，三种返回情况：1、当前线程在超时时间内获得了锁。2、当前线程在超时时间内被中断。3、超时时间内没获得锁

释放锁

获取等待通知组件，该组件和当前的锁绑定，当前线程只有获得了锁，才能调用该组件的wait（）方法，而调用后，当前线程将释放锁。

java中lock的实现是ReentrantLock

 观测其源码，我们可以发现，lock接口的所有实现方法均是通过一个AbstractQueuedSynchronizer（同步器）的对象实现的

队列同步器是用来构建锁或者其他同步组件的基础框架，使用了一个int成员变量表示同步状态，通过内置的FIFO队列来完成资源获取线程的排队工作。

他有三个方法改变状态

getState()：获取当前同步状态

setState()：设置当前同步状态

compareAndSetState(): 使用CAS设置当前状态，保证原子性

同步器中的队列使用了一个双向队列来管理同步状态

 

每个队列元素都有三种状态： cancelled:1 等待的线程超时或者被中断，将取消等待变成该状态（已取消）

signal: -1 下一个节点处于等待状态，当前节点若是释放了同步状态或者被取消了，将通知后继节点得以运行

condition: -2 节点在等待队列中，等待在condition上，其他线程对condition调用了signal()方法后，该节点将从等待队列中转移到同步队列中，加入到对同步状态的获取中。

propagate: -3 传播共享式同步状态

initial: 0 初始状态

主要对象：

node prev:前驱节点

node next:后继节点

node nextWaiter: 等待队列中的后继节点。

Thread thread: 获取同步状态的线程

 

同步器中存储着头节点head跟尾节点tail。

同步器中读写锁状态通过32位的整形数据存储，前16位代表读状态，后16位代表写状态。

其中写状态表示state & 0x0000FFFF , 读状态为 state >>> 16

源码中实现lock的方法，是调用了同步器中的acquire(int arg)（独占式同步状态）方法

该方法尝试独占获取同步状态，成功则返回，否则进入同步队列等待

 

通过死循环来保证节点的正确添加（CAS）

 

节点进入同步队列后，进入一个自旋的过程，当获得同步状态则调用release从自旋退出，并唤醒头节点的后继节点

独占式同步状态总结： 获取同步状态失败的线程会进入到同步器队列中进行自旋，移除队列的条件是前驱节点为头节点且成功获取了同步状态，在释放同步状态时候，同步器会调用tryRelease()方法释放同步状态并且唤醒后继节点。

共享式同步状态：主要用在读写操作上，多线程可以同时读，但是写锁会排他。

同步器中的acquireShared（）方法就是以共享式地获取同步状态

我们可以看到在ReentrantReadWriteLock中的读锁ReadLock中的lock()方法

调用了同步器中的共享式获取同步状态，而写锁writeLock中则调用了独占式方法

 重入锁：支持线程对资源的重复加锁，reentrantLock中先判断当前线程是否为获取锁的线程，是则成功获取，锁获取成功时候计数器加1，释放时候减1，当获取n次并释放n次时候，计数器为0则表示当前锁已经释放，源码方法为nonfairTrAcquire()非公平锁Nonfairsync

公平锁的源码 FairSync 

两者的比较就是判断条件多了hasQueuedPredecessors()方法，就是加入了同步队列中当前节点是否有前驱节点的判断，如果方法返回true 则表示有线程更早请求获取锁，因此要等待前驱线程获取并释放锁之后才能获取。

为什么会有公平锁跟非公平锁呢：

其实非公平锁（默认）系统线程开销更低，公平锁按照队列fifo的原则，进行了大量的线程切换，而非公平锁，大部分是同一个线程又获取到了锁，进行了少量的线程切换，从而提升了性能。

读写锁中，写锁的获取 需判断读锁的状态是否为0，为了避免其他线程在读，读锁的获取， 只要写锁的16位标志位为0 或者是 当前线程获取了写锁 就可以获取读锁。

锁降级：

   锁降级是从写锁降级到读锁，但是在释放写锁之前，需要先获取读锁，否则当写锁释放，当其他进程竞争到写锁，原进程的读锁会获取失败。

 

LockSupport工具： 用于阻塞进程

Condition 接口 : 监视器方法 实现  等待/通知模式 

等待队列是一个FIFO的队列，当线程调用了Condition.await()方法，线程就将释放锁、构造成节点加入等待队列并进行等待状态，一个同步器可以拥有多个等待队列，做法就是lock.newCondition, 唤醒方法是Condition.signal()方法， 则唤醒节点的线程就会开始尝试去获取同步状态

isOnSyncQueued(node)方法判断了该节点是否是等待状态并且是否是等待队列的首节点，是则false跳出循环

 

signal方法先校验了当前线程是否是获取了锁的进程，接着获取等待队列的首节点，将其移动到同步队列并使用LockSupport唤醒节点中的线程，被唤醒的线程将从await()的while循环中退出进而调用同步器的acquireQueued()方法加入到获取同步状态的竞争中。

Condition是在java 1.5中才出现的，它用来替代传统的Object的wait()、notify()实现线程间的协作，相比使用Object的wait()、notify()，使用Condition1的await()、signal()这种方式实现线程间协作更加安全和高效。简单说，他的作用是使得某些线程一起等待某个条件（Condition），只有当该条件具备(signal 或者 signalAll方法被调用)时，这些等待线程才会被唤醒，从而重新争夺锁。