Lock锁的详细实现(AQS及Future Task)
系列目录
浪费了一个周末啥都没学 QAQjava
日期：2019年7月2日23:05:51数据库
Lock
核心API
API
| 方法 | 描述 |
| lock | 获取锁的方法，若锁被其余线程获取，则等待(阻塞)缓存 |
| lockinterruptibly | 在锁的获取过程当中能够中断当前线程安全 |
tryLockbash |
尝试非阻塞地获取锁，当即返回并发 |
| unlock | 释放锁ide |
Tips：post
根据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 相同次数
可响应中断
中断只是标记线程应该被中断，但不是立刻中止ui
// 可响应中断
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
相关文章
- 1. AQS的傀儡之Lock锁
- 2. Lock显示锁实现类及实例
- 3. Java多线程--JUC-Lock锁（ReentrantLock、AQS）
- 4. Lock, AQS
- 5. AbstractQueuedSynchronizer AQS锁原理及ReentrantLock非公平锁的实现
- 6. Java并发-AQS及各类Lock锁的原理
- 7. Java并发-AQS及各种Lock锁的原理
- 8. JUC包(三) 锁与锁实现(AQS)
- 9. java并发编程 | 锁详解：AQS，Lock，ReentrantLock，ReentrantReadWriteLock
- 10. java中lock锁使用以及AQS理解
- 更多相关文章...
- • 现实生活中的 XML - XML 教程
- • Hibernate实现增删改查 - Hibernate教程
- • Flink 数据传输及反压详解
- • ☆基于Java Instrument的Agent实现
相关标签/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
最新文章
- 1. 外部其他进程嵌入到qt FindWindow获得窗口句柄 报错无法链接的外部符号 [email protected] 无法被([email protected]@[email protected]@@引用
- 2. UVa 11524 - InCircle
- 3. The Monocycle（bfs）
- 4. VEC-C滑窗
- 5. 堆排序的应用-TOPK问题
- 6. 实例演示ElasticSearch索引查询term,match,match_phase,query_string之间的区别
- 7. 数学基础知识 集合
- 8. amazeUI 复择框问题解决
- 9. 背包问题理解
- 10. 算数平均-几何平均不等式的证明,从麦克劳林到柯西
欢迎关注本站公众号,获取更多信息
相关文章
- 1. AQS的傀儡之Lock锁
- 2. Lock显示锁实现类及实例
- 3. Java多线程--JUC-Lock锁（ReentrantLock、AQS）
- 4. Lock, AQS
- 5. AbstractQueuedSynchronizer AQS锁原理及ReentrantLock非公平锁的实现
- 6. Java并发-AQS及各类Lock锁的原理
- 7. Java并发-AQS及各种Lock锁的原理
- 8. JUC包(三) 锁与锁实现(AQS)
- 9. java并发编程 | 锁详解：AQS，Lock，ReentrantLock，ReentrantReadWriteLock
- 10. java中lock锁使用以及AQS理解