系列目录
浪费了一个周末啥都没学 QAQ
日期:2019年7月2日23:05:51
Lock
核心API
API
方法 | 描述 |
lock | 获取锁的方法,若锁被其他线程获取,则等待(阻塞) |
lockinterruptibly | 在锁的获取过程中可以中断当前线程 |
tryLock | 尝试非阻塞地获取锁,立即返回 |
unlock | 释放锁 |
Tips:
根据Lock接口的源码注释,Lock接口的实现, 具备和同步关键字同样的内存语义。
实例
可重入
public class ReentrantDemo1 {
private static final ReentrantLock lock = new ReentrantLock();
public static void main(String[] args) {
lock.lock(); // block until condition holds
try {
System.out.println("第一次获取锁");
System.out.println("当前线程获取锁的次数" + lock.getHoldCount());
lock.lock();
System.out.println("第二次获取锁了");
System.out.println("当前线程获取锁的次数" + lock.getHoldCount());
} finally {
lock.unlock();
lock.unlock();
}
System.out.println("当前线程获取锁的次数" + lock.getHoldCount());
// 如果不释放,此时其他线程是拿不到锁的
new Thread(() -> {
System.out.println(Thread.currentThread() + " 期望抢到锁");
lock.lock();
System.out.println(Thread.currentThread() + " 线程拿到了锁");
}).start();
}
}
- 是可重入的,一个 线程 可以锁定多次
- 需要 unluck() 相同的次数
- lock() n 次则需要 unlock 相同次数
可响应中断
中断只是标记线程应该被中断,但不是马上停止
// 可响应中断
public class LockInterruptiblyDemo1 {
private Lock lock = new ReentrantLock();
public static void main(String[] args) throws InterruptedException {
LockInterruptiblyDemo1 demo1 = new LockInterruptiblyDemo1();
Runnable runnable = new Runnable() {
@Override
public void run() {
try {
demo1.test(Thread.currentThread());
} catch (InterruptedException e) {
e.printStackTrace();
}
}
};
Thread thread1 = new Thread(runnable);
Thread thread2 = new Thread(runnable);
thread1.start();
Thread.sleep(500); // 等待0.5秒,让thread1先执行
thread2.start();
Thread.sleep(2000); // 两秒后,中断thread2
thread2.interrupt();
}
public void test(Thread thread) throws InterruptedException {
System.out.println(Thread.currentThread().getName() + ", 想获取锁");
lock.lockInterruptibly(); //注意,如果需要正确中断等待锁的线程,必须将获取锁放在外面,然后将InterruptedException抛出
try {
System.out.println(thread.getName() + "得到了锁");
Thread.sleep(10000); // 抢到锁,10秒不释放
} finally {
System.out.println(Thread.currentThread().getName() + "执行finally");
lock.unlock();
System.out.println(thread.getName() + "释放了锁");
}
}
}
lockInterruptibly()/lock() 区别
- lockInterruptibly 可以响应中断
- 即,阻塞时被中断,可以 throw exception
- lock() 不响应中断
- 被 interrupt 后不会立即中断,而是继续等待
ReentrantReadWriteLock 读写锁
读写锁定义
- 维护一对关联锁,一个用于只读操作,一个用于写入。
- 读锁可以由多个读线程同时持有,写锁是排他的。
- 写锁的时候可以读。
- 读锁的时候不可写。
- 适合读取线程比写入线程多的场景,改进互斥锁的性能。
- 示例场景:缓存组件、集合的并发线程安全性改造。
锁降级定义
- 锁降级指的是写锁降级成为读锁。
- 把持住当前拥有的写锁的同时,再获取到读锁,随后释放写锁的过程。
- 写锁是线程独占,读锁是共享,所以写->读是升级。(读->写, 是不能实现的)
实例
线程安全问题:变量没有满足 可见性 和 原子性。
读锁 -> 共享锁
写锁 -> 独享锁
- 适用于读多,写少的场景。如果这类场景加锁,就会导致资源利用率低下(读也被加锁了)
适用sync等互斥锁效率低
使用读锁效率高
可以多个线程同时读
- 读锁可以由多个读线程同时持有,写锁是排他的。
- 写锁的时候可以读。
- 读锁的时候不可写。
使用读写锁防止缓存雪崩
当没有读写锁时,大量请求在没有命中缓存的情况下,全部打到 db 上。
有可能出现数据不一致的情况。
// 缓存示例
public class CacheDataDemo {
// 创建一个map用于缓存
private Map<String, Object> map = new HashMap<>();
private static ReadWriteLock rwl = new ReentrantReadWriteLock();
public static void main(String[] args) {
// 1 读取缓存里面的数据
// cache.query()
// 2 如果换成没数据,则取数据库里面查询 database.query()
// 3 查询完成之后,数据塞到塞到缓存里面 cache.put(data)
}
public Object get(String id) {
Object value = null;
// 首先开启读锁,从缓存中去取
rwl.readLock().lock();
try {
if (map.get(id) == null) {
// TODO database.query(); 全部查询数据库 ,缓存雪崩
// 必须释放读锁
rwl.readLock().unlock();
// 如果缓存中没有释放读锁,上写锁。如果不加锁,所有请求全部去查询数据库,就崩溃了
rwl.writeLock().lock(); // 所有线程在此处等待 1000 1 999 (在同步代码里面再次检查是否缓存)
try {
// 双重检查,防止已经有线程改变了当前的值,从而出现重复处理的情况
if (map.get(id) == null) {
// TODO value = ...如果缓存没有,就去数据库里面读取
}
rwl.readLock().lock(); // 加读锁降级写锁,这样就不会有其他线程能够改这个值,保证了数据一致性
} finally {
rwl.writeLock().unlock(); // 释放写锁@
}
}
/* 在这里又进行了一系列操作,在操作过程中,有可能数据改变导致缓存内容改变
此时,要在写锁中加入读锁,防止类似于 幻读,脏读 等的产生
*/
} finally {
rwl.readLock().unlock();
}
return value;
}
}
- 缓存雪崩
- 在没有命中缓存的情况下,释放读锁,加写锁。防止多个线程同时读 db,导致雪崩
- 锁降级 写锁 -> 读锁
- 在读锁过程中,可以在释放前加写锁。
- 不会造成死锁!!!
HashMap 的线程安全改造
HashTable 是如何实现线程安全的
如何更高效的改造
实例
手动实现 reentrantLock
- wait()/notify() 必须要在同步代码块(monitor object)
- 所以要使用 pack/unpack
简单版本
/**
* 自己手动实现的一个 reentrantLock
*
*/
public class GzyLock implements Lock {
//需要 CAS 自旋的方式去实现
//模仿 monitor obj 的重量级锁 有一个 owner
private static AtomicReference<Thread> owner = new AtomicReference<>();
private static LinkedBlockingDeque<Thread> waiters = new LinkedBlockingDeque<>();
@Override
public void lock() {
boolean addQueue = true;
while (!tryLock()){
//第一次进来会放到queue
if(addQueue) {
//如果没有获取到锁,就先存到 queue
waiters.offer(Thread.currentThread());
addQueue = false;
}else {
//park 等待被唤醒。这里不能用 wait/notify 因为需要在同步代码块用
LockSupport.park();
}
//唤醒后尝试争抢,没抢到继续等
}
//抢到锁,移除掉
waiters.remove(Thread.currentThread());
}
@Override
public boolean tryLock() {
//适用当前线程尝试加锁
return owner.compareAndSet(null, Thread.currentThread());
}
@Override
public void unlock() {
//unlock 的时候,要唤醒等待线程
//如果释放锁成功了,才会唤起
//这里用 if 是因为,一定不会出现 循环
if (owner.compareAndSet(Thread.currentThread(), null)) {
//一次唤醒所有在等待队列的
for (Thread waiter : waiters) {
//唤起等待队列的线程
LockSupport.unpark(waiter);
}
}
}
public static void main(String[] args) throws InterruptedException {
Adder adder = new Adder();
for (int j = 0; j < 10; j++) {
Thread addThread = new Thread(() -> {
for (int i = 0; i < 1000; i++) {
adder.add();
}
});
addThread.start();;
}
Thread.sleep(1000L);
System.out.println(adder.i);
}
static class Adder{
Lock lock = new GzyLock();
int i = 0;
public void add(){
lock.lock();
try {
i++;
}finally {
lock.unlock();
}
}
}
}
- 注意几点,一定要在 unlock() 成功以后在进行 uppark
- 非公平的,有可能在 unlock 的 CAS 执行成功后,unpark waiter 之前,有新的线程进行了 lock
抽象队列同步器 AQS 的初步理解
结合源码的初步理解,具体的定义:抽象队列同步器
- 可以实现 公平 与 非公平
- 抽象队列同步器,实现了 线程的等待和唤醒 以及 资源的获取与释放
- 只是个同步队列,没有定义锁的获取与释放逻辑。
- 即,抽象了资源的获取与释放逻辑
- 只是持有锁、锁池(waiters)以及定义了 acquire/release 资源后的操作
- acquire/release 资源后的操作,即 线程的等待和唤醒逻辑
- 具体如何获取与释放,由不同的实现类去定义
- Lock
- Lock 改为持有 抽象队列同步器 ,不再持有 资源、锁池
- 不同的锁实现了不同的 队列同步器, 定义了不同的资源同步(acquire/release)逻辑
reentrantLock 源码梳理
锁的本质
- 同步的方式:独享锁-单个队列窗口,共享锁-多个队列窗口
- 抢锁的方式:插队抢(不公平锁)、先来后到抢锁(公平锁)
- 不公平锁:会先尝试抢锁,抢不到才会进入等待队列
- 没抢到锁的处理方式:快速尝试多次(CAS自旋锁)、阻塞等待
- 阻塞等待,一定会有一个等待队列。因为需要被唤醒
- 唤醒阻塞线程的方式(叫号器):全部通知、通知下一个
抽象队列同步器 AQS
简介
只有锁和锁池(waiters),定义了 锁(线程) 的获取和释放后的处理逻辑。
抽象了 获取和释放 锁(资源)的方法,需要根据具体的业务场景去实现。例如:同步锁、非同步锁;独享锁,共享锁。
等待/唤醒逻辑,都由 AQS 去实现了。因为无论什么样的锁,都需要去等待。
- acquire、acquireShared
- 定义了资源争用的逻辑,如果没拿到,则等待。
- tryAcquire、tryAcquireShared
- 实际执行占用资源的操作,如何判定一个由使用者具体去实现。
- release、releaseShared
- 定义释放资源的逻辑,释放之后,通知后续节点进行争抢。
- tryRelease、tryReleaseShared
- 实际执行资源释放的操作,具体的AQS使用者去实现。
- state/exclusive owner/queue
- state 不同场景下含义不同
- 独享锁的 lock/unlock 记录了当前线程 lock 的次数
- 共享锁的 acquireShare/releaseShare 表示当前已使用的资源数
Tips
- 当前线程多次加锁
- 公平与非公平只是区别于是否刚到的时候抢一下
- 读写锁
- 操作字段不同
- AQS核心其实是 八大方法、三大主体
- 通过八大方法去操作三大主体
读写锁流程
AQS 资源占用流程
Future Task
源码来一波
版权声明
- 本文作者: 留夕
- 本文链接: www.yuque.com/diamond/ndv…
- 版权声明: 本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 许可协议。转载请注明出处!
- 首发日期: 2019年7月2日23:05:51