转载

Lock锁的详细实现(AQS及Future Task)

系列目录

浪费了一个周末啥都没学 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();
    }
}
复制代码
  1. 是可重入的,一个 线程 可以锁定多次
    1. 需要 unluck() 相同的次数
    2. 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等互斥锁效率低

  • Lock锁的详细实现(AQS及Future Task)

使用读锁效率高

可以多个线程同时读

Lock锁的详细实现(AQS及Future Task)

  • 读锁可以由多个读线程同时持有,写锁是排他的。
    • 写锁的时候可以读。
    • 读锁的时候不可写。

使用读写锁防止缓存雪崩

当没有读写锁时,大量请求在没有命中缓存的情况下,全部打到 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 去实现了。因为无论什么样的锁,都需要去等待。 Lock锁的详细实现(AQS及Future Task)

  • acquire、acquireShared
    • 定义了资源争用的逻辑,如果没拿到,则等待。
  • tryAcquire、tryAcquireShared
    • 实际执行占用资源的操作,如何判定一个由使用者具体去实现。
  • release、releaseShared
    • 定义释放资源的逻辑,释放之后,通知后续节点进行争抢。
  • tryRelease、tryReleaseShared
    • 实际执行资源释放的操作,具体的AQS使用者去实现。
  • state/exclusive owner/queue
    • state 不同场景下含义不同
    • 独享锁的 lock/unlock 记录了当前线程 lock 的次数
    • 共享锁的 acquireShare/releaseShare 表示当前已使用的资源数

Tips

  • 当前线程多次加锁
  • 公平与非公平只是区别于是否刚到的时候抢一下
  • 读写锁
    • 操作字段不同
  • AQS核心其实是 八大方法、三大主体
    • 通过八大方法去操作三大主体

读写锁流程

Lock锁的详细实现(AQS及Future Task)

AQS 资源占用流程

Lock锁的详细实现(AQS及Future Task)

Future Task

源码来一波

版权声明

Lock锁的详细实现(AQS及Future Task)

  • 本文作者: 留夕
  • 本文链接: www.yuque.com/diamond/ndv…
  • 版权声明: 本博客所有文章除特别声明外,均采用CC BY-SA 4.0 许可协议。转载请注明出处!
  • 首发日期: 2019年7月2日23:05:51
原文  https://juejin.im/post/5d25fd2d6fb9a07ef64006a4
正文到此结束
Loading...