2-并发编程-Lock&AQS

原创

青龙小码农 2021-11-23 15:28:49 博主文章分类：JAVA ©著作权

文章标签 数据加锁 java sed 等待队列 文章分类 代码人生

©著作权归作者所有：来自51CTO博客作者青龙小码农的原创作品，请联系作者获取转载授权，否则将追究法律责任

设计同步器的意义

多线程编程中，有可能会出现多个线程同时访问同一个共享、可变资源的情况，这个资源我们称之其为临界资源；这种资源可能是：对象、变量、文件等。

共享：资源可以由多个线程同时访问
可变：资源可以在其生命周期内被修改

引出的问题：

由于线程执行的过程是不可控的，所以需要采用同步机制来协同对对象可变状态的访问

那么我们怎么解决线程并发安全问题？

实际上，所有的并发模式在解决线程安全问题时，采用的方案都是序列化访问临界资源。即在同一时刻，只能有一个线程访问临界资源，也称作同步互斥访问。

Java 中，提供了两种方式来实现同步互斥访问：synchronized（同步器的本质就是加锁）和 Lock

加锁作用与锁定义分类

加锁目的：序列化访问临界资源，即同一时刻只能有一个线程访问临界资源(同步互斥访问)

2-并发编程-Lock&AQS_数据

Java锁体系

2-并发编程-Lock&AQS_加锁_02

不过有一点需要区别的是：当多个线程执行一个方法时，该方法内部的局部变量并不是临界资源，因为这些局部变量是在每个线程的私有栈中，因此不具有共享性，不会导致线程安全问题。

synchronized

Wait Queue：哪些调用 wait 方法被阻塞的线程被放置在这里；
Contention List：竞争队列，所有请求锁的线程首先被放在这个竞争队列中；
Entry List：Contention List 中那些有资格成为候选资源的线程被移动到 Entry List 中；
OnDeck：任意时刻，最多只有一个线程正在竞争锁资源，该线程被成为 OnDeck；
Owner：当前已经获取到所资源的线程被称为 Owner；
!Owner：当前释放锁的线程。

synchronized内置锁是一种对象锁(锁的是对象而非引用)，作用粒度是对象，可以用来实现对临界资源的同步互斥访问，是可重入的。加锁的方式：【独占、悲观】

同步实例方法，锁是当前实例对象（this）
同步类方法，锁是当前类对象【当作用于静态方法时，锁住的是Class实例，又因为Class的相关数据存储在永久带PermGen（jdk1.8 则是 metaspace），永久带是全局共享的，因此静态方法锁相当于类的一个全局锁，会锁所有调用该方法的线程；】
同步代码块，锁是括号里面的对象

2-并发编程-Lock&AQS_sed_03

JVM 每次从队列的尾部取出一个数据用于锁竞争候选者（OnDeck），但是并发情况下，ContentionList 会被大量的并发线程进行 CAS 访问，为了降低对尾部元素的竞争，JVM 会将一部分线程移动到 EntryList 中作为候选竞争线程。
Owner 线程会在 unlock 时，将 ContentionList 中的部分线程迁移到 EntryList 中，并指定EntryList 中的某个线程为 OnDeck 线程（一般是最先进去的那个线程）。
Owner 线程并不直接把锁传递给 OnDeck 线程，而是把锁竞争的权利交给 OnDeck，OnDeck需要重新竞争锁。这样虽然牺牲了一些公平性，但是能极大的提升系统的吞吐量，在
JVM 中，也把这种选择行为称之为“竞争切换”。
OnDeck 线程获取到锁资源后会变为 Owner 线程，而没有得到锁资源的仍然停留在 EntryList中。如果Owner线程被wait方法阻塞，则转移到WaitSet队列中，直到某个时刻通过notify或者 notifyAll 唤醒，会重新进去 EntryList 中。
处于 ContentionList、EntryList、WaitSet 中的线程都处于阻塞状态，该阻塞是由操作系统来完成的（Linux 内核下采用 pthread_mutex_lock 内核函数实现的）。
Synchronized 是非公平锁。 Synchronized 在线程进入 ContentionList 时，等待的线程会先尝试自旋获取锁，如果获取不到就进入 ContentionList，这明显对于已经进入队列的线程是不公平的，还有一个不公平的事情就是自旋获取锁的线程还可能直接抢占 OnDeck 线程的锁资源。
每个对象都有个 monitor 对象，加锁就是在竞争 monitor 对象，代码块加锁是在前后分别加上 monitorenter 和 monitorexit 指令来实现的，方法加锁是通过一个标记位来判断的
synchronized 是一个重量级操作，需要调用操作系统相关接口，性能是低效的，有可能给线程加锁消耗的时间比有用操作消耗的时间更多。
Java1.6，synchronized 进行了很多的优化，有适应自旋、锁消除、锁粗化、轻量级锁及偏向锁等，效率有了本质上的提高。在之后推出的 Java1.7 与 1.8 中，均对该关键字的实现机理做了优化。引入了偏向锁和轻量级锁。都是在对象头中有标记位，不需要经过操作系统加锁。
锁可以从偏向锁升级到轻量级锁，再升级到重量级锁。这种升级过程叫做锁膨胀；
JDK 1.6 中默认是开启偏向锁和轻量级锁，可以通过-XX:-UseBiasedLocking 来禁用偏向

synchronized底层原理

synchronized是基于JVM内置锁实现，通过内部对象Monitor(监视器锁)实现，基于进入与退出Monitor对象实现方法与代码块同步，监视器锁的实现依赖底层操作系统的Mutex lock（互斥锁）实现，它是一个重量级锁，性能较低。当然，JVM内置锁在1.5之后版本做了重大的优化，如锁粗化（Lock
Coarsening）、锁消除（Lock Elimination）、轻量级锁（LightweightLocking）、偏向锁（Biased Locking）、适应性自旋（Adaptive Spinning）等技术来减少锁操作的开销，，内置锁的并发性能已经基本与Lock持平。synchronized关键字被编译成字节码后会被翻译成monitorenter 和monitorexit 两条指令分别在同步块逻辑代码的起始位置与结束位置。（汇编层级：lock compxchg）每个同步对象都有一个自己的Monitor(监视器锁)，加锁过程如下图所示：

2-并发编程-Lock&AQS_java_04

（笔者在面试中被问到过当时没答上来）
修饰不加static的方法，锁是加在单个对象上，不同的对象没有竞争关系；
修饰加了static的方法，锁是加载类上，这个类所有的对象竞争一把锁。

那么有个问题来了，我们知道synchronized加锁加在对象上，对象是如何记录锁状态的呢？

答案是锁状态是被记录在每个对象的对象头（Mark Word）中

对象的内存布局

对象头：比如 hash码，对象所属的年代，对象锁，锁状态标志，偏向锁（线程）ID，偏向时间，数组长度（数组对象）、类型指针等
对象实例数据：即创建对象时，对象中成员变量，方法等
对齐填充：对象的大小必须是8字节的整数倍

补充：

<dependency>
    <groupId>org.openjdk.jol</groupId>
    <artifactId>jol-core</artifactId>
    <version>0.10</version>
</dependency>
public static void main(String[] args) {
    //对象头8个字节，类型指针4个字节【经过压缩】 ，对其 4个字节
    //默认没开启压缩 就是 8 +8  
    //还是16
    Object o = new Object();
    System.out.printf(ClassLayout.parseInstance(o).toPrintable());
}

2-并发编程-Lock&AQS_数据_06

2-并发编程-Lock&AQS_加锁_07

2-并发编程-Lock&AQS_加锁_08

2-并发编程-Lock&AQS_sed_09

对象头

HotSpot虚拟机的对象头包括两部分信息，第一部分是“Mark Word”，用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等等，这部分数据的长度在32位和64位的虚拟机（暂不考虑开启压缩指针的场景）中分别为32个和64个Bits，官方称它为“Mark Word”。对象需要存储的运行时数据很多，其实已经超出了32、64位Bitmap结构所能记录的限度，但是对象头信息是与对象自身定义的数据无关的额外存储成本，考虑到虚拟机的空间效率，Mark Word被设计成一个非固定的数据结构以便在极小的空间内存储尽量多的信息，它会根据对象的状态复用自己的存储空间。例如在32位的HotSpot虚拟机中对象未被锁定的状态下，MarkWord的32个Bits空间中的25Bits用于存储对象哈希码（HashCode），4Bits用于存储对象分代年龄，2Bits用于存储锁标志位，1Bit固定为0，在其他状态（轻量级锁定、重量级锁定、GC标记、可偏向）下对象的存储内容如下表所示。

2-并发编程-Lock&AQS_java_10

2-并发编程-Lock&AQS_java_11

但是如果对象是数组类型，则需要三个机器码，因为JVM虚拟机可以通过Java对象的元数据信息确定Java对象的大小，但是无法从数组的元数据来确认数组的大小，所以用一块来记录数组长度。对象头信息是与对象自身定义的数据无关的额外存储成本，但是考虑到虚拟机的空间效率，Mark Word被设计成一个非固定的数据结构以便在极小的空间内存存储尽量多的数据，它会根据对象的状态复用自己的存储空间，也就是说，Mark Word会随着程序的运行发生变化，变化状态如下（32位虚拟机）：

2-并发编程-Lock&AQS_sed_12

64位

2-并发编程-Lock&AQS_数据_13

（对象的年代最大15）

JDK1.6版本之后对synchronized的实现进行了各种优化，如自旋锁、偏向锁和轻量级锁，并默认开启偏向锁

开启偏向锁：-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0
关闭偏向锁：-XX:-UseBiasedLocking

2-并发编程-Lock&AQS_加锁_14

锁的膨胀升级过程

锁的状态总共有四种，无锁状态、偏向锁、轻量级锁（无锁、自旋锁、自适应自选）和重量级锁。随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁，但是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级。下图为锁的升级全过程：

2-并发编程-Lock&AQS_sed_15

偏向锁

偏向锁是Java
6之后加入的新锁（性能预计提高约10%），它是一种针对加锁操作的优化手段，经过研究发现，在大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，因此为了减少同一线程获取锁(会涉及到一些CAS操作,耗时)的代价而引入偏向锁。偏向锁的核心思想是，如果一个线程获得了锁，那么锁就进入偏向模式，此时Mark Word的结构也变为偏向锁结构，当这个线程再次请求锁时，无需再做任何同步操作，即获取锁的过程，这样就省去了大量有关锁申请的操作，从而也就提供程序的性能。所以，对于没有锁竞争的场合，偏向锁有很好的优化效果，毕竟极有可能连续多次是同一个线程申请相同的锁。但是对于锁竞争比较激烈的场合，偏向锁就失效了，因为这样场合极有可能每次申请锁的线程都是不相同的，因此这种场合下不应该使用偏向锁，否则会得不偿失，需要注意的是，偏向锁失败后，并不会立即膨胀为重量级锁，而是先升级为轻量级锁。下面我们接着了解轻量级锁（不会自动释放）。

import java.util.Vector;
public class Biaslock {
    public static Vector<Integer> vector = new Vector<Integer>();
    /**
     * 默认开启偏向锁
     * 开启偏向锁：-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0
     * 关闭偏向锁：-XX:-UseBiasedLocking
     */
    public static void main(String[] args){
        long begin = System.currentTimeMillis();
        int count = 0;
        int num = 0;
while(count < 10000000){
            vector.add(num);
            num = num + 5;
            count++;
        }
        long end = System.currentTimeMillis();
        System.out.println(end - begin);
    }
}

轻量级锁

倘若偏向锁失败，虚拟机并不会立即升级为重量级锁，它还会尝试使用一种称为轻量级锁的优化手段(1.6之后加入的)，此时Mark Word 的结构也变为轻量级锁的结构。轻量级锁能够提升程序性能的依据是“对绝大部分的锁，在整个同步周期内都不存在竞争”，注意这是经验数据。需要了解的是，轻量级锁所适应的场景是线程交替执行同步块的场合，如果存在同一时间访问同一锁的场合，就会导致轻量级锁膨胀为重量级锁。

自旋锁（1.6+自适用自旋）

轻量级锁失败后，虚拟机为了避免线程真实地在操作系统层面挂起，还会进行一项称为自旋锁的优化手段。这是基于在大多数情况下，线程持有锁的时间都不会太长，如果直接挂起操作系统层面的线程可能会得不偿失，毕竟操作系统实现线程之间的切换时需要从用户态转换到核心态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高，因此自旋锁会假设在不久将来，当前的线程可以获得锁，因此虚拟机会让当前想要获取锁的线程做几个空循环(这也是称为自旋的原因，默认是10次
-XX：PreBlockSpin 设置)，在经过若干次循环后，如果得到锁，就顺利进入临界区。如果还不能获得锁，那就会将线程在操作系统层面挂起，这就是自旋锁的优化方式，这种方式确实也是可以提升效率的。最后没办法也就只能升级为重量级锁了。

锁消除

消除锁是虚拟机另外一种锁的优化，这种优化更彻底，Java虚拟机在JIT编译时(可以简单理解为当某段代码即将第一次被执行时进行编译，又称即时编译)，通过对运行上下文的扫描，去除不可能存在共享资源竞争的锁，通过这种方式消除没有必要的锁，可以节省毫无意义的请求锁时间【锁消除的主要判定依据来源于逃逸分析的数据支持】，如下StringBuffer的append是一个同步方法，但是在add方法中的StringBuffer属于一个局部变量，并且不会被其他线程所使用，因此StringBuffer不可能存在共享资源竞争的情景，JVM会自动将其锁消除。
/**

锁的消除锁的粗化
/
public void lockCoarsening(){
//线程安全 append使用synchronized 锁的粗化所有的 append加一个，不是每个都加
StringBuffer sb = new StringBuffer("");
sb.append(“1”);
sb.append(“2”);
sb.append(“3”);
}
/*
锁的消除
*/
public void lockEliminate(){
//jvm 的优化，不会对同步块进行加锁
synchronized (new Object()){
}
}

锁粗化

2-并发编程-Lock&AQS_java_16

锁降级

在gc的时候才发生，只能被VMTread访问，降级也就没有意义了

逃逸分析

使用逃逸分析，编译器可以对代码做如下优化：

一、同步省略。如果一个对象被发现只能从一个线程被访问到，那么对于这个对象的操作可以不考虑同步。
二、将堆分配转化为栈分配。如果一个对象在子程序中被分配，要使指向该对象的指针永远不会逃逸，对象可能是栈分配的候选，而不是堆分配。
三、分离对象或标量替换。有的对象可能不需要作为一个连续的内存结构存在也可以被访问
到，那么对象的部分（或全部）可以不存储在内存，而是存储在CPU寄存器中。

是不是所有的对象和数组都会在堆内存分配空间？不一定

ReentrantLock

2-并发编程-Lock&AQS_sed_17

ReentrantLock与synchronized相比增加了一些高级功能，主要有以下三项：

等待可中断
可实现公平锁（默认非公平）
锁可以绑定多个条件。

【ReentrantLock在功能上是synchronized的超集，在性能上又至少不会弱于synchronized(jdk1.6+) ,推荐优先使用synchronized：1.lock需要手动释放锁（finally中），2.synchronized还有优化空间, 3.ReentrantLock 相比 synchronized 的优势是可中断、公平锁、多个锁,这种情况下需要使用】

同步框架AbstractQueuedSynchronizer(AQS)

并发之父 Doug Lea

Java并发编程核心在于java.concurrent.util包而juc当中的大多数同步器实现都是围绕着共同的基础行为，比如等待队列、条件队列、独占获取、共享获取等，而这个行为的抽象就是基于AbstractQueuedSynchronizer简称AQS，AQS定义了一套多线程访问共享资源的同步器框架，是一个依赖状态(state)的同步器。AQS具备特性：

阻塞等待队列
共享/独占
公平/非公平
可重入
允许中断

Java.concurrent.util当中同步器的实现如Lock,Latch,Barrier等，都是基于AQS框架实现

一般通过定义内部类Sync继承AQS
将同步器所有调用都映射到Sync对应的方法

2-并发编程-Lock&AQS_java_18

不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源state的获取与释放方式即可，至于具体线程等待队列的维护（如获取资源失败入队/唤醒出队等），AQS已经在顶层实现好了。自定义同步器实现时主要实现以下几种方法：

isHeldExclusively()：该线程是否正在独占资源。只有用到condition才需要去实现它。
tryAcquire(int)：独占方式。尝试获取资源，成功则返回true，失败则返回false。
tryRelease(int)：独占方式。尝试释放资源，成功则返回true，失败则返回false。
tryAcquireShared(int)：共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
tryReleaseShared(int)：共享方式。尝试释放资源，如果释放后允许唤醒后续等待结点返回true，否则返回false。

同步等待队列

AQS当中的同步等待队列也称CLH队列，CLH队列是Craig、Landin、Hagersten三人发明的一种基于双向链表数据结构的队列，是FIFO先入先出线程等待队列，Java中的CLH队列是原CLH队列的一个变种,线程由原自旋机制改为阻塞机制。它维护了一个 volatile int state（代表共享资源）和一个 FIFO 线程等待队列（多线程争用资源被阻塞时会进入此队列）

2-并发编程-Lock&AQS_数据_19