Notes
Search…
⌃K

Lock & Condition

序言里面已经提到,Java 使用 Lock 和 Condition 来实现管程,Lock 解决互斥问题,Condition 解决同步问题。

Lock

为什么需要 Lock

在讲死锁时,提出破坏不可抢占条件方案,但这个方案 synchronized 没法解决。
synchronized 不能实现上述方案的原因是:synchronized 申请资源的时候,如果申请不到,线程直接进入阻塞状态了,而线程进入阻塞状态,啥都干不了,也释放不了线程已经占有的资源。
所以若要锁的实现能够解决上述问题,可以有如下方案:
  • 能够响应中断。如果阻塞状态的线程能够响应中断信号,也就是说当我们给阻塞的线程发送中断信号的时候,能够唤醒它,那它就有机会释放曾经持有的锁 A。
  • 支持超时。如果线程在一段时间之内没有获取到锁,不是进入阻塞状态,而是返回一个错误,那这个线程也有机会释放曾经持有的锁。
  • 非阻塞地获取锁。如果尝试获取锁失败,并不进入阻塞状态,而是直接返回,那这个线程也有机会释放曾经持有的锁。
这也是为什么 JDK 重新实现了套管程:
public interface Lock {
void lockInterruptibly() throws InterruptedException;
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
boolean tryLock();
}

Lock 怎么保证可见性

我们知道 Java 的 Happens-Before 原则有一条关于 synchronized 的,所以 synchronized 能够保证可见性。
但是 Lock 怎么保证可见性呢?Lock 内部持有一个 volatile 变量 state,获取和释放锁的时候都会读写 state,所以利用 顺序性规则volatile 变量规则传递性,Lock 就可以保证可见性。

ReentrantLock

Lock 有一个实现类 ReentrantLock,即可重入锁:线程可以重复获取同一把锁
底层基于 AQS,每当同一个线程获得一次这把锁,state 变量加1,释放一次 state 变量减1,最终当线程不持有锁时,state 为0。

公平锁与非公平锁

ReentrantLock 有一个有参构造函数,传入 fair 表示公平策略。
如果一个线程没有获得锁,就会进入等待队列,当有线程释放锁的时候,就需要从等待队列中唤醒一个等待的线程。公平锁:谁等待的时间长,就唤醒谁;非公平锁:有可能等待时间短的线程反而先被唤醒。

用锁的最佳实践

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

Condition

Condition 实现了管程模型里面的条件变量。一个 Lock 可以有多个条件变量,这个是与 synchronized 一个很大的区别。

利用两个条件变量实现阻塞队列

public class BlockedQueue<T>{
final Lock lock = new ReentrantLock();
// 条件变量:队列不满
final Condition notFull = lock.newCondition();
// 条件变量:队列不空
final Condition notEmpty = lock.newCondition();
// 入队
void enq(T x) {
lock.lock();
try {
while (队列已满){
// 等待队列不满
notFull.await();
}
// 省略入队操作...
// 入队后, 通知可出队
notEmpty.signal();
}finally {
lock.unlock();
}
}
// 出队
void deq(){
lock.lock();
try {
while (队列已空){
// 等待队列不空
notEmpty.await();
}
// 省略出队操作...
// 出队后,通知可入队
notFull.signal();
}finally {
lock.unlock();
}
}
}
由此可见:
  • Condition.await() 对应 Object.wait()
  • Condition.signal() 对应 Object.notify()
  • Condition.signalAll() 对应 Object.notifyAll()

ReadWriteLock

在生产中经常有读多写少的场景,比如缓存。针对这种情况,Java 提供了一个接口ReadWriteLock
  • 允许多个线程同时读共享变量。
  • 只允许一个线程写共享变量。
  • 当一个线程在写共享变量时,不允许其它线程读和写操作。

缓存实现

class Cache<K,V> {
final Map<K, V> m = new HashMap<>();
final ReadWriteLock rwl = new ReentrantReadWriteLock();
// 读锁
final Lock r = rwl.readLock();
// 写锁
final Lock w = rwl.writeLock();
// 读缓存
V get(K key) {
r.lock();
try { return m.get(key); }
finally { r.unlock(); }
}
// 写缓存
V put(String key, Data v) {
w.lock();
try { return m.put(key, v); }
finally { w.unlock(); }
}
}

缓存数据按需加载

缓存中的数据是需要初始化的,若数据量小,可以直接一次性全部加载;若数据量大,则要按需加载(懒加载),即当查询的时候再加载。
V get(K key) {
V v = null;
// 读缓存
r.lock();
try {
v = m.get(key);
} finally{
r.unlock();
}
// 缓存中存在,返回
if(v != null) {
return v;
}
// 缓存中不存在,查询数据库
w.lock();
try {
// 再次验证
// 其他线程可能已经查询过数据库
v = m.get(key);
if(v == null){
// 查询数据库
v= 省略代码无数
m.put(key, v);
}
} finally{
w.unlock();
}
return v;
}

读写锁升级与降级

把上面的代码改成如下是否可行?
// 读缓存
r.lock();
try {
v = m.get(key);
if (v == null) {
w.lock();
try {
// 再次验证并更新缓存
// 省略详细代码
} finally{
w.unlock();
}
}
} finally{
r.unlock();
}
答案是不行,会导致写锁永远等待。
  • 锁的升级:先获取了读锁,再获取写锁。这是不允许的。
  • 锁的降级:先获取了写锁,再获取读锁。这是允许的。

总结

  • 读写锁也支持公平和非公平模式。
  • 只有写锁支持条件变量,读锁不支持。

StampedLock

Java 1.8 提供,性能比 ReadWriteLock 更好。支持三种模式:
  • 写锁:与 ReadWriteLock的写锁类似,只允许一个线程获取。获取时返回一个 stamp,解锁时需要传入此 stamp。
  • 悲观读锁:与 ReadWriteLock 读锁类似,允许多个线程同时获取,与写锁互斥。获取时返回一个 stamp,解锁时需要传入此 stamp。
  • 乐观读:注意没加锁字,因为乐观读是无锁的。允许一个线程获取写锁。
class Point {
private int x, y;
final StampedLock sl = new StampedLock();
// 计算到原点的距离
int distanceFromOrigin() {
// 乐观读
long stamp = sl.tryOptimisticRead();
// 读入局部变量,
// 读的过程数据可能被修改
int curX = x, curY = y;
// 判断执行读操作期间,
// 是否存在写操作,如果存在,
// 则 sl.validate 返回 false
if (!sl.validate(stamp)){
// 升级为悲观读锁
stamp = sl.readLock();
try {
curX = x;
curY = y;
} finally {
// 释放悲观读锁
sl.unlockRead(stamp);
}
}
return Math.sqrt(
curX * curX + curY * curY);
}
}
上述代码首先乐观读,但是 x、y 可能被修改,因此需要验证一下,若验证不通过,升级为读锁。若不升级为读锁,需要在循环里面反复乐观读,浪费 CPU,所以最佳实践是升级为读锁

数据库的乐观锁

  • 先从数据库读一条带 version 字段的记录。
  • 然后在程序中对数据做业务修改。
  • 最后写入数据库时采用 update set version = version + where version = XX and id = XX的语句,若返回1,则说明更新成功,期间没有人修改这条数据;若返回0,则更新失败,说明有人修改过此数据。
可见,数据库乐观锁的 version 字段与 StampedLock 的 stamp 是同样的意义。

结论

StampedLock 的功能是 ReadWriteLock 的子集
  • StampedLock 不支持可重入;
  • StampedLock 的悲观读锁和写锁都不支持条件变量;
  • 若线程阻塞在 StampedLock 的 readLock() 或者 writeLock() 上时,一定不要调用中断操作;如果需要支持中断功能,一定使用可中断的悲观读锁 readLockInterruptibly() 和写锁 writeLockInterruptibly()
  • StampedLock 支持锁降级tryConvertToReadLock()升级tryConvertToWriteLock()
StampedLock 读模板:
final StampedLock sl = new StampedLock();
// 乐观读
long stamp = sl.tryOptimisticRead();
// 读入方法局部变量
......
// 校验 stamp
if (!sl.validate(stamp)){
// 升级为悲观读锁
stamp = sl.readLock();
try {
// 读入方法局部变量
.....
} finally {
// 释放悲观读锁
sl.unlockRead(stamp);
}
}
// 使用方法局部变量执行业务操作
......
StampedLock 写模板:
long stamp = sl.writeLock();
try {
// 写共享变量
......
} finally {
sl.unlockWrite(stamp);
}
Last modified 3yr ago