本文部分摘自《Java 并发编程的艺术》

重入锁

重入锁 ReentrantLock,顾名思义,就是支持重进入的锁,它表示该锁能够支持一个线程对资源的重复加锁。除此之外,该锁还支持获取锁时的公平和非公平性选择

所谓不支持重进入,可以考虑如下场景:当一个线程调用 lock() 方法获取锁之后,如果再次调用 lock() 方法,则该线程将会被自己阻塞,原因是在调用 tryAcquire(int acquires) 方法时会返回 false,从而导致线程阻塞

synchronize 关键字隐式的支持重进入,比如一个 synchronize 修饰的递归方法,在方法执行时,执行线程在获取锁之后仍能连续多次地获得该锁。ReentrantLock 虽然不能像 synchronize 关键字一样支持隐式的重进入,但在调用 lock() 方法时,已经获得锁的线程,能够再次调用 lock() 方法获取锁而不被阻塞

1. 实现重进入

重进入特性的实现需要解决以下两个问题:

  • 线程再次获取锁

    锁需要去识别获取锁的线程是否为当前占据锁的线程,如果是,则再次成功获取

  • 锁的最终释放

    线程重复 n 次获取锁,随后在第 n 次释放该锁后,其他线程能获取到锁。实现此功能,理应考虑使用计数

ReentrantLock 通过组合自定义同步器来实现锁的获取与释放,以非公平锁实现为例,获取同步状态的代码如下所示,主要是增加了再次获取同步状态的处理逻辑

final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
// 判断当前线程是否为获取锁的线程
else if (current == getExclusiveOwnerThread()) {
// 将同步值进行增加,并返回 true
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}

考虑到成功获取锁的线程再次获取锁,只是增加同步状态值,这也就要求 ReentrantLock 在释放同步状态时减少同步状态值,该方法代码如下:

protected final boolean tryRelease(int releases) {
// 减少状态值
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
// 当同步状态为0,将占有线程设为null,并返回true,表示释放成功
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}

2. 公平与非公平获取锁的区别

如果一个锁是公平的,那么锁的获取顺序就应该符合请求的绝对时间顺序,也即 FIFO。回顾上一节,非公平锁只要 CAS 设置同步状态成功,即表示当前线程获取了锁,而公平锁则不同,代码如下:

protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
/*
* 唯一不同的就是判断条件多了 hasQueuedPredecessors()
* 该方法用来判断当前节点是否有前驱节点
* 如果该方法返回 true,表示有线程比当前线程更早请求获取锁
* 因此需要等待前驱线程释放锁之后才能继续获取锁
*/
if (!hasQueuedPredecessors() && compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}

读写锁

之前提到的锁基本都是排它锁,同一时刻只允许一个线程访问,而读写锁在同一时刻可以允许多个线程访问,但在写线程访问时,所有的读线程和其他写线程均被阻塞。读写锁维护了一对锁,一个读锁和一个写锁,通过分离读锁和写锁,使得并发性相比一般的排它锁有了很大提升

1. 接口示例

下面通过缓存示例说明读写锁的使用方式

public class Cache {

    static Map<String, Object> map = new HashMap<>();
static ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
static Lock r = rwl.readLock();
static Lock w = rwl.writeLock(); /**
* 获取一个 key 对应的 value
*/
public static Object get(String key) {
r.lock();
try {
return map.get(key);
} finally {
r.unlock();
}
} /**
* 设置 key 对应的 value,并返回旧的 value
*/
public static Object put(String key, Object value) {
w.lock();
try {
return map.put(key, value);
} finally {
w.unlock();
}
} /**
* 清空所有的内容
*/
public static void clear() {
w.lock();
try {
map.clear();
} finally {
w.unlock();
}
}
}

2. 读写状态的设计

读写锁同样依赖自定义同步器来实现功能,而读写状态就是其同步器状态。读写锁的自定义同步器需要在同步状态(一个整型变量)上维护多个读线程和一个写线程的状态,为此需要读写锁将变量切分成两部分,高 16 位表示读,低 16 位表示写

上图表示一个线程已经获取了写锁,且重进入了两次,同时也连续两次获取了读锁。通过位运算可以迅速确定读和写各自的状态,假设当前同步状态值为 S,则:

  • 写状态等于 S & 0x0000FFFF(将高 16 位全部抹去)
  • 读状态等于 S >>> 16(无符号右移 16 位)
  • 当写状态增加 1 时,等于 S + 1
  • 当读状态增加 1 时,等于 S + (1<<6),也就是 S + 0x00010000

根据状态的划分能得出一个结论:S 不等于 0 时,当写状态(S & 0x0000FFFF)等于 0 时,则读状态(S >>> 16)大于 0,即读锁已被获取

3. 写锁的获取与释放

写锁是一个支持重进入的排它锁。如果当前线程已经获取了写锁,则增加写状态。如果当前线程在获取写锁时,读锁已被获取,或者该线程不是获取写锁的线程,则当前线程进入等待状态,获取写锁的代码如下:

protected final boolean tryAcquire(int acquires) {
Thread current = Thread.currentThread();
int c = getState();
// exclusiveCount 方法会用 c & 0x0000FFFF,即得出写状态个数
int w = exclusiveCount(c);
if (c != 0) {
// 根据上面提到的推论,c 不等于 0,而 w 等于 0,证明存在读锁
// 当前线程也不是获取了写锁的线程
if (w == 0 || current != getExclusiveOwnerThread())
return false;
if (w + exclusiveCount(acquires) > MAX_COUNT)
throw new Error("Maximum lock count exceeded");
setState(c + acquires);
return true;
}
if (writerShouldBlock() || !compareAndSetState(c, c + acquires))
return false;
setExclusiveOwnerThread(current);
return true;
}

写锁的每次释放均会减少写状态,当写状态为 0 时表示写锁已被释放,从而等待的读写线程能够继续访问读写锁,同时前次写线程的修改对后续读写线程可见

4. 读锁的获取与释放

读锁是一个支持重进入的共享锁,它能被多个线程同时获取,在没有其他写线程访问时,读锁总能被成功获取,这里对获取读锁的代码做了简化:

protected final int tryAcquireShared(int unused) {

    for(;;) {
int c = getState();
int nextc = c + (1<<16);
if(nextc < c) {
throw new Error("Maximum lock count exceeded");
}
// 如果其他线程已经获取写锁,则读取获取失败
if(exclusiveCount(c) != 0 && owner != Thread.currentThread()) {
return -1;
}
if(compareAndSetState(c, nextc)) {
return 1;
}
}
}

读锁的每次释放均减少读状态,减少的值是 1<<16

5. 锁降级

锁降级指的是写锁降级成为读锁。如果当前线程拥有写锁,然后将其释放,最后再获取读锁,这种分段完成的过程不能称之为锁降级。锁降级是指把持住写锁,再获取读锁,随后释放写锁的过程

public void processData() {
readLock.lock();
if(!update) {
// 必须先释放读锁
readLock.unlock();
// 锁降级从写锁获取到开始
writeLock.lock();
try {
if(!update) {
// 准备数据的流程(略)
update = true;
}
readLock.lock();
} finally {
writeLock.unlock();
}
}
try {
// 使用数据的流程(略)
} finally {
readLock.unlock();
}
}

上例中,当数据发生变更,则 update(使用 volatile 修饰)被设置为 false,此时所有访问 processData 方法的线程都能感知到变化,但只有一个线程能获取到写锁,其余线程会被阻塞在写锁的 lock 方法上。当前线程获取写锁完成数据准备之后,再次获取读锁,随后释放写锁,完成锁降级

最新文章

  1. HAVING用法详解
  2. Scut游戏服务器免费开源框架--快速开发(2)
  3. linux下的clock skew detected
  4. 剑指offer
  5. 使用jsoup进行网页内容抓取
  6. [039] 微信公众帐号开发教程第15篇-自定义菜单的view类型(访问网页)
  7. duck type鸭子类型
  8. SQL Server 性能优化
  9. MFC之窗体改动工具栏编程状态栏编程程序启动画面
  10. java nio 网络框架实现(转)
  11. zf-关于即将过期提示字符串的修改
  12. http://codeforces.com/contest/828
  13. 【安全性测试】利用反编译查看对应activity的方法采用hook技术绑定劫持_入门
  14. SQL SERVER中LIKE使用变量类型不同输出结果不一致解惑
  15. vs2010提取资源
  16. 架构师成长之路2.3-PXE+Kickstart无人值守大量部署Linux
  17. code review &amp; github
  18. django中使用POST方法 获取POST数据
  19. Oracle之plsql及游标
  20. h5聊天工具的开发过程及思路

热门文章

  1. Gome 高性能撮合引擎微服务
  2. Zabbix 监控项更多用法
  3. bnuoj-53073 萌萌哒身高差 【数学】【非原创】
  4. bzoj1013球形空间产生器sphere 高斯消元(有系统差的写法
  5. 7816协议时序和采用UART模拟7816时序与智能卡APDU指令协议
  6. Canvas &amp; encryption image src
  7. macOS &amp; Catalina vs Big Sur
  8. Angular 2 for 2017 web full stack development
  9. Python Coding Interview
  10. lua调用dll导出的函数