Day116 并发编程之Lock体系

Lock体系

对比同步方法和同步块，Lock 接口提供了更具扩展性的锁操作。

常用实现类：Condition，Lock，ReadWriteLock，这些类的实现都是基于AQS的

基本概念

• 悲观锁：总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。
  • 应用场景：synchronized关键字和Lock的实现类都是悲观锁。
• 乐观锁：顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。
  • 应用场景：java.util.concurrent包中的原子类就是通过CAS来实现了乐观锁。
  • 实现方式1：为数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。
  • 实现方式2：CAS算法来比较主内存中的数据是否发生了更新，更新再采取操作。

AQS

• 概念：AQS(AbstractQueuedSynchronizer)，也就是队列同步器，这是 Lock子类实现的基础。
• 原理：（状态和队列）AQS的实现主要在于维护一个volatile int state（代表共享资源）和一个FIFO线程等待队列（多线程争用资源被阻塞时会进入此队列）。队列中的每个节点是对线程的一个封装，包含线程基本信息，状态，等待的资源类型等。AQS 有一个 state 标记位，值为1 时表示有线程占用，其他线程需要进入到同步队列等待，同步队列是一个双向链表。
  

ReentrantLock

• 概念：ReentrantLock重入锁，是JUC实现Lock接口的一个常用类，也是在实际编程中使用频率很高的一个锁，支持重入性，表示能够对共享资源能够重复加锁，即当前线程获取该锁再次获取不会被阻塞。

• 构造函数：可以设置公平和非公平锁，默认非公平锁，防止3s的进程要等一个3h的线程

• 使用方法：使用时最标准用法是在try之前调用lock方法，在finally代码块unlock释放锁

• 实现原理：ReentrantLock主要利用CAS+AQS队列来实现。
  https://blog.csdn.net/fuyuwei2015/article/details/83719444

• 公平锁和非公平锁

  • 公平锁：按照线程在队列中的排队顺序，先到者先拿到锁。
  • 非公平锁：当线程要获取锁时，无视队列顺序直接去抢锁，谁抢到就是谁的
  • 比较：公平锁为了保证时间上的绝对顺序，需要频繁的上下文切换，而非公平锁会降低一定的上下文切换，降低性能开销；非公平锁有可能刚释放锁的线程下次继续获取该锁，则有可能导致其他线程永远无法获取到锁，造成“饥饿”现象。
  • ReentrantLock的构造方法无参时是构造非公平锁，另外可传入一个boolean值，true时为公平锁，false时为非公平锁，源码为

• Lock与Synchronized的区别：总体来说Lock作为一个Java类比关键字Synchronized有更大的灵活性，Synchronized会自动释放锁，但无法获取锁的状态，如果一个线程阻塞，之后的线程会一直在等待状态，而 Lock 需要手动释放锁，可以判断是否获取到了锁，如果一个线程阻塞，之后的线程不一定会继续等待，两者都是可重入锁，默认非公平，但Lock锁可以设置是否为公平锁，总体来说Synchronized 适合锁少量的代码同步问题，Lock 适合锁大量的同步代码。

ReadWriteLock

Condition

概述： Lock替换synchronized方法和语句的使用， 比如 wait， notify 换成了Condition中的 await 和 signal。而用JUC的Condition完成线程之间的通讯可以达到精准的通知和唤醒。

CAS算法

• 概念：较并交换(compare and swap, CAS)，是原子操作的一种，可用于在多线程编程中实现不被打断的数据交换操作。cas 是一种基于锁的操作，而且是乐观锁。
• 原理：CAS 操作包含三个操作数 —— 内存位置（V）、预期原值（A）和新值(B)。如果内存地址里面的值和 A 的值是一样的，那么就将内存里面的值更新成 B。CAS是通过无限循环来获取数据的，若果在第一轮循环中，a 线程获取地址里面的值被 b 线程修改了，那么 a 线程需要自旋，到下次循环才有可能机会执行。
• 应用：JUC，java.util.concurrent.atomic 包下的类大多是使用 CAS 操作来实现的(AtomicInteger,AtomicBoolean,AtomicLong)，还有1.8版本的ConcurrentHashmap也使用该算法。
• 使用：USAFE类中的 CompareAndSwapXXX 相关方法。unsafe底层实际上是调用C代码，C代码调用汇编，最后生成出一条CPU指令cmpxchg，完成操作。这也就为啥CAS是原子性的，因为它是一条CPU指令，不会被打断。

// 第一和第二个参数代表对象的实例以及地址，第三个参数代表期望值，第四个参数代表更新值
public final native boolean compareAndSwapObject(Object var1, long var2, Object var4, Object var5);

public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);

public final native boolean compareAndSwapLong(Object var1, long var2, long var4, long var6);

• 问题：
  • ABA 问题：比如说一个线程 one 从内存位置 V 中取出 A，这时候另一个线程 two 也从内存中取出 A，并且 two 进行了一些操作变成了 B，然后 two 又将 V 位置的数据变成 A，这时候线程 one 进行 CAS 操作发现内存中仍然是 A，然后 one 操作成功。尽管线程 one 的 CAS 操作成功，但可能存在潜藏的问题。从 Java1.5 开始 JDK 的 atomic包里提供了一个类 AtomicStampedReference 来解决 ABA 问题。
  • 循环时间长开销大：对于资源竞争严重（线程冲突严重）的情况，CAS 自旋的概率会比较大，从而浪费更多的 CPU 资源，效率低于 synchronized。
  • 只能保证一个共享变量的原子操作：当对一个共享变量执行操作时，我们可以使用循环 CAS 的方式来保证原子操作，但是对多个共享变量操作时，循环 CAS 就无法保证操作的原子性，这个时候就可以用锁。

https://blog.csdn.net/u011521203/article/details/80186741
https://www.bilibili.com/video/BV1YE411D7nH?p=28