juc--三大接口-CFANZ编程社区

文章目录

juc
一、为什么会有juc
二、juc--三大接口

1.lock
2.condition
3.ReadWriteLock

二、juc--的默认实现类

1.ReentrantLock--lock的默认实现类

公平锁,非公平锁

2. ReentrantReadWriteLock读写锁--ReadWriteLock的默认实现类

1 读写锁和排它锁
2 读写锁原则

总结

juc

juc: java.util.concurrent juc可太牛掰了,几乎完成里面所有的逻辑代码,都是老爷子一个人完成的;

一、为什么会有juc

因为synchronized在很多场景中是无法完美契合的,为了弥补这个缺陷,juc应运而生;说一个最简单的点:synchronized无法知道我是否获取锁成功,无法主动释放锁,当临界区的代码有问题的时候,就会一直阻塞!
synchronized就那么一无是处嘛? no , 例如: synchronized是肯定不会发生死锁的,但是juc中的可重入锁,当时用不当(加锁与解锁没有成对出现)的时候,就会发生死锁!

二、juc–三大接口

juc--三大接口_读锁

1.lock

juc--三大接口_java_02

源码中的示例代码如上:

加锁 lock.lock();
释放锁 lock.unlock(); 一般在finally 中; 目的是可以最终释放锁,不会导致发生意外后,一直阻塞
lock 一般不会单独使用

2.condition

juc--三大接口_公平锁_03

Condition源码示例代码如上:

与lock 配合使用
当使用lock 加锁解锁后, 可以用Condition来作为线程之间的通信
Condition中的线程通信方法和Object的wait/notify基本相似。其中，Condition的await方法对应的是Object的wait方法，而Condition的signal/signalAll方法则对应Object的notify/notifyAll()。但Condition类似于Object的等待/通知机制的加强版。

juc--三大接口_分布式_04

Condition 中有两种队列,分别为同步队列和等待队列

同步队列为一个双向队列

private transient volatile Node head;
  private transient volatile Node tail;

juc--三大接口_读锁_05

每次加入的时候,把线程包装成一个node(包含获取同步状态失败的线程引用、等待状态以及前驱和后继节点),每次都是根据tail 找到最后一个节点,然后加入,并将tail 指向最后加入的元素; 利用CAS保证安全;

调用了await之后,当前线程会进入等待队列 ,每次new 的Condition都是一个等到队列,等待队列是一个链式的单项队列,它会把同步队列中的头节点删除并移动到这个等待队列中

nextWaiter;

用Object的方式(wait notify)实际上是指在对象Object对象监视器上只能拥有一个同步队列和一个等待队列，而并发包中的Lock拥有一个同步队列和多个等待队列;
使用 Condition 的时候,多个线程必须获取的是同一把lock ,这样才能调用await 和 singal 等方法;

3.ReadWriteLock

这个可就牛掰了~~,读写锁;

juc--三大接口_读锁_06

可以获取到读锁和写锁; 适用于读多写少的情况;

读锁,允许多个线程同时访问
写锁,可以理解为是synchronized, 临界区的代码同一时间只能有一个线程访问;

二、juc–的默认实现类

1.ReentrantLock–lock的默认实现类

public ReentrantLock() {
        sync = new NonfairSync();
    }

    /**
     * Creates an instance of {@code ReentrantLock} with the
     * given fairness policy.
     *
     * @param fair {@code true} if this lock should use a fair ordering policy
     */
    public ReentrantLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
    }

这个锁默认是非公平的锁,且初始化之后无法改变,只能通过 isFair() 获取当前锁的属性;