synchronize 多线程的基本原理及挑战

╰+哭是因爲堅強的太久メ 2024-03-26 23:20 87阅读 0赞

### 一、线程的基本概念 ###

线程是一个进程的组成部分，是一条顺序的执行流。

线程的执行过程会有以下状态：

*  new：新建状态
 *  runnable：就绪状态包含 running(运行中) 和 ready(准备状态)
 *  waiting/TimedWaiting：等待/超时等待状态
 *  blocking：阻塞状态
 *  teminated：终止状态

[![alt][]

![alt][]][alt_ _alt] 线程运行状态流程图

new Thread(()-> System.out.println("线程运行！！")).start();

以上线程执行 start 并不一定会马上运行，会先进行到就绪状态，等待有足够的 CPU 资源才会运行。

**start() 和 run() 的区别？**

*  run 方法执行相当于只会运行所编写的代码然后就不做任何操作了，start 方法运行会按照一个线程的正常的流程来执行

**sleep()、yield()、wait() 的区别？**

*  sleep 方法会释放当前线程所占用的 CPU 资源，不会释放当前线程所拥有的锁，实现当前线程的阻塞，属于 Thread 类的方法
 *  yield 方法会让出一部分的 CPU 资源让其他线程来优先执行，自身的线程会进入到 ready 准备状态，和其他线程一起竞争锁，不一定会真正的让其他线程执行到，属于 Thread 类的方法，yield() 默认的优先级为 5，最小为 0 ，最大为 10，优先级越大获得锁的几率就越大。
 *  wait 方法会释放当前线程所占用的 CPU 资源同时也会释放当前所拥有的锁，让并行的其他线程来执行，使用 wait 方法需要在我们的系统锁(synchronize)的代码块内使用，不然会报 java.lang.IllegalMonitorStateException 异常，属于 Object 类的方法，wait 方法还有和 Object 类下的 notify() 和 notifyAll() 来搭配使用的，notify() 用来唤醒等待队列中的其中一个线程来争夺锁，notifyAll() 用来唤醒所有等待队列中的线程一起来争夺这把锁。

[![alt][alt 1]

![alt 1][]][alt_alt 1_ _alt 1]

### 二、synchronize 的基本认识 ###

在多线程并发编程中 synchronize 一直被称为元老级的角色，很多人都会称呼它为重量级锁，但是，随着 Java SE 1.6 对 synchronize 的一系列优化之后，有些情况它不再那么重，Java SE 1.6 中为了减少获取锁和释放锁带来的性能优化而引入的偏向锁和轻量级锁的概念，下面再进行偏向锁和轻量级锁的详细解述。

#### 1.synchronize 的作用 ####

**多线程对于共享变量访问带来的安全性问题？**

一个变量 count .假如一个线程去访问这个变量进行修改，这个时候对于数据的修改和访问不存在任何问题，但是如果是多个线程同时去访问这个变量进行操作的时候，就会出现数据的不安全问题。

[![alt][alt 2]

![alt 2][]][alt_alt 2_ _alt 2]

对于线程安全性，本质上是管理对于数据**状态**的访问，而且这个状态通常是共享的、可变的，共享就是它可以被多个线程访问；可变指的是这个变量在它的生命周期是可以被改变的。

**线程不安全的代码演示：**

public class T implements Runnable {
    
    	private /*volatile*/ int count = 100;
    	
    	public /*synchronized*/ void run() {
    		count--;
    		System.out.println(Thread.currentThread().getName() + " count = " + count);
    	}
    	
    	public static void main(String[] args) {
    		T t = new T();
    		for(int i=0; i<100; i++) {
    			new Thread(t, "THREAD" + i).start();
    		}
    	}
    	
    }

运行结果(**理想结果应该是 count = 0**)：

[![alt][alt 3]

![alt 3][]][alt_alt 3_ _alt 3]

**如何保证线程并行的数据安全性：**

问题的本质在于共享数据 count 存在并发访问，如果有一种方法可以实现多个线程的并行变成串行，那么线程安全问题就迎刃而解了。

按照常规的解决方案来说就是给对象进行加锁，常见的有悲观锁和乐观锁。

乐观锁的实现可以通过数据库的版本号机制和 CAS 操作来保证数据安全性，相关乐观锁实现的文章讲解：[https://www.vnjohn.com/java-lock-html/][https_www.vnjohn.com_java-lock-html]

本文介绍加锁的方式就是通过 **synchronize** 关键字来实现

synchronize 本身就是一种**悲观锁**的存在，默认是**非公平锁**，**没有公平锁**，内部自己实现了**互斥锁**(同一时刻只能有一个线程对其进行操作)和**可重入锁**(A 和 B 同时加锁，A 进入 B 自动会获取锁，不需要额外去争抢锁)

使用 synchronize 实现线程并发的数据安全性(**取消上述代码的注释**)，再运行结果如下：

[![alt][alt 4]

![alt 4][]][alt_alt 4_ _alt 4]

#### 2.synchronize 的基本语法 ####

synchronize 有三种方式来进行加锁，分别是：

*  修饰代码块，指定加锁对象，对给定对象加锁，进入同步代码块前要获得给定对象的锁

public class T {
    	private int count = 10;
    	public void m() {
    		// 其他业务代码
    		// ....
    		//任何线程要执行下面的代码，必须先拿到this的锁
    		synchronized(this) { 
    			count--;
    			System.out.println(Thread.currentThread().getName() + " count = " + count);
    		}
    	}
    }

*  修饰实例方法，作用于当前实例加锁，进入同步代码块前，要先获得当前实例的锁

public class T1 {
    	private int count = 10;
            //等同于在方法的代码执行时要synchronized(this)
    	public synchronized void m() { 
    		count--;
    		System.out.println(Thread.currentThread().getName() + " count = " + count);
    	}
    }

*  静态方法，作用于当前类对象加锁，进入同步代码前要获得当前类对象的锁

public class T {
    	private static int count = 10;
    
    	//这里等同于synchronized(T.class)
    	public synchronized static void m() { 
    		count--;
    		System.out.println(Thread.currentThread().getName() + " count = " + count);
    	}
    	
    	public static void mm() {
    		synchronized(T.class) {
    			//考虑一下这里写 synchronized(this) 是否可以？
    			// this 代码编译都不会通过,这边的作用域是在类下的
    			count --;
    		}
    	}
    }

不同的修饰类型，代表锁不同的控制粒度.

#### 3.synchronize 锁的存储 ####

从 synchronize 的整个语法来看，synchronize(lock) 是居于 lock 这个来控制锁的粒度的，下面让我们看看锁的实现。

##### **对象在内存中的存储布局** #####

在 Hotspot 虚拟机中，对象在内存中的存储布局，可以分为三个区域：对象头(MarkWord/class pointer)、实例数据、对齐填充三部分组成

[![alt][alt 5]

![alt 5][]][alt_alt 5_ _alt 5] 对象存储

MarkWord 记录了对象与锁相关的信息，当某个对象被 synchronize 关键字当成同步锁的时候，那么围绕这个锁的一系列操作都和 MarkWord 有关。MarkWord 在 32 位虚拟机的长度是 32bit，在 64 位虚拟机的长度是 64bit，MarkWord 里面存储的数据会随着锁标志位的变化而变化。

##### **引出一个新的问题，一个对象 (Object o = new Object();) 在虚拟机中存储多少个字节数？** #####

为了实践这个问题，需要做以下的准备工作

*  引入依赖

<dependency>
        <groupId>org.openjdk.jol</groupId>
        <artifactId>jol-core</artifactId>
        <version>0.14</version>
    </dependency>

*  示例代码

public class JustTest {// JOL = Java Object Layout
        private static class T {
        }
        public static void main(String[] args) {
            T t = new T();
            System.out.println(ClassLayout.parseInstance(t).toPrintable());
        }
    }

运行如下：

[![alt][alt 6]

![alt 6][]][alt_alt 6_ _alt 6]

一个 new 出来的普通对象不带任何实例数据类型总共占用字节数为 16 字节

<table> 
 <tbody> 
  <tr> 
   <td>数据类型</td> 
   <td>占用字节数</td> 
  </tr> 
  <tr> 
   <td>byte</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>boolean</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>char</td> 
   <td>2</td> 
  </tr> 
  <tr> 
   <td>short</td> 
   <td>2</td> 
  </tr> 
  <tr> 
   <td>float</td> 
   <td>4</td> 
  </tr> 
  <tr> 
   <td>int</td> 
   <td>4</td> 
  </tr> 
  <tr> 
   <td>double</td> 
   <td>8</td> 
  </tr> 
  <tr> 
   <td>long </td> 
   <td>8</td> 
  </tr> 
  <tr> 
   <td><strong><span>String/引用类型</span></strong></td> 
   <td><span>4</span></td> 
  </tr> 
 </tbody> 
</table>

八大基本数据所占字节数可能大家都能清楚，但是 String/引用类型就会有点疑惑了，64bit 虚拟机按理来说应该会占用 8 字节才对，这边来说是被虚拟机做了压缩指针的操作，将对应的 8 字节压缩成 4 字节数。

在上述的静态内部类里添加一个 **String 类型**测试即可：

[![alt][alt 7]

![alt 7][]][alt_alt 7_ _alt 7]

使用本机的 cmd 运行命令：

java -XX:+PrintCommandLineFlags -version

[![alt][alt 8]

![alt 8][]][alt_alt 8_ _alt 8]

\-XX:+UseCompressedClassPointers：使用**类型指针**压缩，原本类型指针所占字节数应该是 8 字节的，虚拟机这边压缩成了 4 字节

\-XX:+UseCompressedOops：使用**普通对象指针(Ordinary Object Pointer)**压缩，引用类型指针一般都会占用 8 字节，虚拟机这边也压缩成了 4 字节

可以修改服务的 VM Options 值来查看结果：

[![alt][alt 9]

![alt 9][]][alt_alt 9_ _alt 9]

run 结果如下：

[![alt][alt 10]

![alt 10][]][alt_alt 10_ _alt 10]

**压缩字节的好处简单来说就是节省空间**

MarkWord 会存储 hashcode/锁信息/GC 信息，可以通过观察 MarkWord 值的变化，有变化说明有存储对应的信息，**GC 信息不只存储它何时会被回收还存储它对象的分代年龄，GC 这边不做演示，在后续文章给出 GC 相关知识**

修改以上示例代码如下：

public class JustTest {// JOL = Java Object Layout
        private static class T {
    //        boolean a;
    //        char b;
    //        float c;
    //        int d;
    //        double e;
    //        long f;
    //        short g;
    //        byte h;
    //        String o;
        }
        public static void main(String[] args) {
            T t = new T();
            System.out.println(ClassLayout.parseInstance(t).toPrintable());
            System.out.println("==================== 存储锁信息 =========================");
            synchronized (t){
                System.out.println(ClassLayout.parseInstance(t).toPrintable());
            }
            System.out.println("==================== 存储 hashcode  =========================");
            t.hashCode();
            System.out.println(ClassLayout.parseInstance(t).toPrintable());
        }
    }

[![alt][alt 11]

![alt 11][]][alt_alt 11_ _alt 11]

##### **关于锁信息变化更详细的对比** #####

MarkWord 里面存储的数据会随着锁的标志位的变化而变化，MarkWord 变化可能存储以下五种情况：

[![alt][alt 12]

![alt 12][]][alt_alt 12_ _alt 12]

偏向锁下的 Epoch 字段介绍：

*  epoch 字段是用于辅助批量重偏向(`bulk rebiasing`)和批量偏向撤销(`bulk revocation`)操作
 *  **“批量偏向撤销”解释**：某些操作，例如生产者和消费者队列，线程之间的竞争是不可避免的，这时候就不适合使用偏向锁。 我们需要识别这些情况，然后有选择的禁用偏向锁。此时显然不是只有一个锁，而是一个类或者该类的多个对象作为锁，我们需要对这个类的所有对象都撤销偏向锁，这个优化操作，就叫做**批量撤销偏向**。换句话说，就是在某一阶段，某个类的对象频繁发生偏向撤销的操作，当次数超过预定的阈值(`threshold` 默认为 20) 时，就批量撤销该类所有对象的偏向。
 *  “**批量重偏向”解释**：在某些情况下，例如一个线程先分配了一定数量的对象(属于同一类型)，然后对这些对象执行同步操作，在该线程操作完成后，另一个线程接着执行同步操作，但是这两个线程的操作是顺序执行的，不交互，我们就可以将前一个线程拥有的偏向重偏向到后一个线程，这个优化操作，就叫做 **批量重偏向**。

##### 锁的获取 #####

线程在获取锁的时候，实际上就是获得一个监视器对象(monitor)，多个线程在访问同步代码块时，相当于去争抢对象监视器来修改对象中的标识，该对象有两条指令：monitorEnter/monitorExit，monitorEnter 表示已经获取锁准备要执行同步代码块了，monitorExit 表示同步代码块执行完准备释放锁，其中 wait/notify/notifyAll 也依赖于 monitorEnter。

#### 4.synchronize 锁的升级 ####

在分析 MarkWord 时，我们提到了偏向锁、轻量级锁，为什么在 Java SE 1.6 以后新增这两种锁呢？

*  Hotspot 虚拟机的作者通过调查发现，大部分情况下，加锁的代码不仅仅不存在多线程竞争，而且总是由同一个线程多次获得。所以基于这样一个概率，synchronize 做了一些优化，为了减少之前重量级锁带来的获取锁和释放锁开销，引入了偏向锁、轻量级锁的概念。因此，synchronize 锁存在四种状态：无锁、偏向锁、轻量级锁、重量级锁，根据竞争激烈的程度从低到高不断升级。

##### **偏向锁的基本原理** #####

当一个线程访问同步锁的代码块时，会在对象头上存储当前的线程ID，后续这个线程在进入和退出这段加了同步代码块时，不需要再次获取和释放锁。而是直接比较对象头里是否存储指向当前线程的偏向锁，如果相等表示当前线程是偏向于当前线程的，就不需要再次获取锁了。

**偏向锁的获取和撤销逻辑**

*  首先获取锁对象的 MarkWord，判断是否处于可偏向状态。(biased\_lock=1、且 ThreadId 为空)
 *  如果是可偏向状态，则通过 CAS 操作，将当前线程ID写入到 MarkWord 中
    
     *  如果 CAS 成功，表示已经获取到了偏向锁，接着执行同步代码块
     *  如果 CAS 失败，表示已经有线程获取到了偏向锁，这种情况说明当前锁存在竞争关系，需要撤销已经获取偏向锁的线程，并且把它持有偏向锁的线程升级为轻量级锁(这个操作需要等到全局安全点 safe point，也就是没有线程在执行字节码)才能执行。
 *  如果是已偏向的状态，需要检查 MarkWord 中存储的 ThreadId 是否等于当前的 ThreadId
    
     *  如果相等，不需要再次获取锁，可直接执行同步代码块的内容
     *  如果不相等，说明当前锁偏向于其他线程，需要撤销偏向锁并升级到轻量级锁

**偏向锁的撤销**

偏向锁的撤销并不是把对象恢复到无锁可偏向状态(因为偏向锁并**不存在锁释放**的概念)，而是在获取偏向锁的过程中，发现 CAS 失败也就是存在线程竞争的时候，**直接把被偏向锁对象升级到了被加了轻量级锁的状态**。

把原有持有偏向锁的线程进行撤销时，原获得偏向锁的线程有两种情况：

*  原获得偏向锁的线程如果已经退出了临界区，也就是同步代码块执行完，那么这个时候就把对象头设置成无锁状态，其他争抢锁的线程可以基于 CAS 操作偏向于当前线程
 *  如果原获得偏向锁的线程还没有执行完同步代码块，处于临界区之内，这个时候就把原获得偏向锁的线程升级为轻量级锁后再继续执行同步代码块

在我们的应用开发中，大部分都会存在多个线程之间的竞争关系，那么开启偏向锁，反而会提升获取锁的资源消耗。

偏向锁默认是开启的，但是会有一个时延，如果要观察偏向锁，应该要设定参数

*  开启或禁用偏向锁：
    
     *  开启：-XX:+UseBiasedLocking
     *  关闭：-XX:-UseBiasedLocking
 *  修改偏向锁延迟时间：
    
     *  \-XX:BiasedLockingStartupDelay=0

[![alt][alt 13]

![alt 13][]][alt_alt 13_ _alt 13] 偏向锁流程图分析

##### 轻量级锁的基本原理 #####

**轻量级锁的加速和解锁逻辑**

锁升级为轻量级锁以后，对象的 MarkWord 也会进行相对应的变化，升级为轻量级锁的过程：

*  线程在自己的栈帧中创建锁记录 LockRecord
 *  将锁对象的对象头中的 MarkWord 复制到线程刚刚创建的锁记录中
 *  将锁记录的 Owner 指针指向锁对象
 *  将锁对象的对象头中的 MarkWord 替换为指向锁记录的指针

**自旋锁**

轻量级锁在加锁过程中，使用到了自旋锁

所谓自旋，就是当有一个线程来竞争锁的时候，这个线程会在原地循环等待，而不是把该线程阻塞，直到那个获取到锁的线程释放锁之后，这个线程就能马上获得锁，注意：锁在原地循环的时候，是在消耗 CPU 的，就相当于在执行一个什么也没有的循环。

轻量级锁适用于那么同步代码执行很快的场景，这样，线程等待很短的时间就能获取到锁了，自旋锁也需要有一个条件去控制它，否则一个线程执行同步代码的时间很长，那么这个线程不断的循环会消耗 CPU 资源。默认情况下自旋的次数是 10 次，可以通过 JVM 参数：-XX:PreBlockSpin 来调节循环的次数。

在 JDK1.6 之后，引入了自适应自旋锁，自适应意味着自旋的次数不是固定不变的，而是根据前一次在同一个锁上的自旋时间以及锁的拥有者状态来决定。如果一个对象在自旋等待获取过锁，那么虚拟机就会认为它会再次成功，因此允许它在自旋等待更长的时间。

**轻量级锁的解锁**

轻量级锁的释放逻辑其实就是获得锁的反向逻辑，通过 CAS 操作把线程栈帧中的 LockRecord 替换回到的锁对象的 MarkWord 中，如果成功表示没有竞争。如果失败，表示当前锁存在竞争，那么轻量级锁就会膨胀成为重量级锁。

[![alt][alt 14]

![alt 14][]][alt_alt 14_ _alt 14] 流程图分析

##### 重量级锁的基本原理 #####

当轻量级锁膨胀为重量级锁的时候，意味着线程只能被挂起阻塞来等待被唤醒了。

**重量级锁的 monitor**

*  创建一个类如下：

public class Test {
        private static class T {
        }
        public static void main(String[] args) {
            T t = new T();
            synchronized (t) {
                System.out.println("反汇编 synchronize！！");
            }
        }
    }

*  先将 Test 类通过 javac 命令编译为 class 文件

[![alt][alt 15]

![alt 15][]][alt_alt 15_ _alt 15]

*  再将编译好的文件进行 javap -c 反汇编的命令得到以下内容：

[![alt][alt 16]

![alt 16][]][alt_alt 16_ _alt 16]

加入了同步代码块之后，在字节码中会看到一个 monitorEnter 和 monitorExit

每一个 Java 对象都会与一个监视器 monitor 关联，我们可以把它理解为一把锁，当一个线程想要执行一段被 synchronize 修饰的同步方法或代码块时，该线程得先获得 synchronize 修饰的对象对应的 monitor。

monitorEnter 表示去获得一个对象监视器，monitorExit 表示释放 monitor 监视器的所有权，使得其他的阻塞线程有机会去获得这个对象监视器。

monitor 依赖操作系统的 MutexLock(互斥锁)来实现的，线程被阻塞后便进入内核(Linux)调度状态，这个会导致系统在用户态和内核态之间来回切换，严重影响锁的性能，轻量级锁的自旋实现就是在用户态之间进行切换，不会像重量级锁这样显得比较重。

**重量级锁加锁的基本流程**

[![alt][alt 17]

![alt 17][]][alt_alt 17_ _alt 17]

任意线程对 Object (Object 由 synchronize 保护)的访问，首先要获得 Object 的监视器。如果获取失败，线程进入同步队列，线程状态变为 blocked。当访问 Object 的前驱(获得锁的线程)释放了锁，则该释放并唤醒阻塞在同步队列中的线程，使其重新尝试对监视器的获取。

##### **小结** #####

根据上面的介绍可以知道，synchronize 自从 JDK1.6 之后就进行了一系列的优化，由之前的重量级锁变成现在的锁升级理念，对于系统上的优化提升一个更大的空间，Lock 方面的加锁和原生的 synchronize 加锁各有自己的长处，适用于不同的场景。

**Lock 和 synchronize 的区别？**

*  原始构成
    
     *  synchronize 属于 JVM 层面
     *  Lock是具体类(java.util.concurrent.locks.Lock)是api层面的锁
 *  使用方法
    
     *  synchronize 不需要用户去手动释放锁，当 synchronize 执行完后系统会自动让线程释放对锁的占用。
     *  Lock 需要用户手动去释放锁，，若没有主动去释放锁，就会导致死锁现象，需要 lock() 和 unlock() 方法配合 try/finally 语句块来完成
 *  等待是否可被中断
    
     *  synchronize 不可中断，除非抛出异常或者正常运行完成
     *  Lock 可中断，设置超时方法 tryLock(timeout，unit)
 *  加锁是否公平
    
     *  synchronize 非公平锁
     *  Lock 两者都可以，默认是非公平锁，构造方法可以传入 boolean 值，true 为公平锁，false 为非公平锁
 *  锁绑定多个 condition
    
     *  synchronize 没有
     *  Lock 用来实现分组唤醒需要唤醒的线程们，可以精确唤醒，而不是像 synchronize 要么随机唤醒一个要么唤醒全部线程

#### 参考文献 ####

[https://www.cnblogs.com/twoheads/p/10150063.html][https_www.cnblogs.com_twoheads_p_10150063.html]

#### *相关* ####

[alt]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/081f9499126146e9b287848870845248.png
[alt_ _alt]: https://i0.wp.com/www.vnjohn.com/wp-content/uploads/2020/12/image-14-1024x559.png?ssl=1
[alt 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/9f88e7aa04014a088ff5f6707984838c.png
[alt_alt 1_ _alt 1]: https://i0.wp.com/www.vnjohn.com/wp-content/uploads/2020/12/1608718165.png
[alt 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/be8db2a47c3248a4a85209cc4f4de811.png
[alt_alt 2_ _alt 2]: https://i0.wp.com/www.vnjohn.com/wp-content/uploads/2020/12/image-19.png?ssl=1
[alt 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/747d3ad19b1c4f8b8bd29946b536b370.png
[alt_alt 3_ _alt 3]: https://i0.wp.com/www.vnjohn.com/wp-content/uploads/2020/12/image-21.png?ssl=1
[https_www.vnjohn.com_java-lock-html]: https://www.vnjohn.com/java-lock-html/
[alt 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/8c596bf5f4c14590a99d009079766981.png
[alt_alt 4_ _alt 4]: https://i0.wp.com/www.vnjohn.com/wp-content/uploads/2020/12/image-22.png?ssl=1
[alt 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/02a24757fc2847369e2765bd1e2fae42.png
[alt_alt 5_ _alt 5]: https://i0.wp.com/www.vnjohn.com/wp-content/uploads/2020/12/image-26-1024x309.png?ssl=1
[alt 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/7352baeb38c34c2391406f8ec321f1ee.png
[alt_alt 6_ _alt 6]: https://i0.wp.com/www.vnjohn.com/wp-content/uploads/2020/12/image-29-1024x259.png?ssl=1
[alt 7]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/3af202f5003d4193902fbef012cdb009.png
[alt_alt 7_ _alt 7]: https://i0.wp.com/www.vnjohn.com/wp-content/uploads/2020/12/image-31.png?ssl=1
[alt 8]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/6348a40fe7c94734bd4bfb154a961954.png
[alt_alt 8_ _alt 8]: https://i0.wp.com/www.vnjohn.com/wp-content/uploads/2020/12/image-32-1024x82.png?ssl=1
[alt 9]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/be733df98bcd45e5882d29c45457d089.png
[alt_alt 9_ _alt 9]: https://i0.wp.com/www.vnjohn.com/wp-content/uploads/2020/12/image-41.png?ssl=1
[alt 10]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/def0a41846544c85935ba49053353091.png
[alt_alt 10_ _alt 10]: https://i0.wp.com/www.vnjohn.com/wp-content/uploads/2020/12/image-39-1024x197.png?ssl=1
[alt 11]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/01d543397c694b8f9c81dbcd37330ec6.png
[alt_alt 11_ _alt 11]: https://i0.wp.com/www.vnjohn.com/wp-content/uploads/2020/12/image-44-1024x588.png?ssl=1
[alt 12]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/f864a972c4794d098c91fac88471c2ab.png
[alt_alt 12_ _alt 12]: https://i0.wp.com/www.vnjohn.com/wp-content/uploads/2020/12/image-45-1024x268.png?ssl=1
[alt 13]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/bcda6e6dd2644234a9a854bbc4cf3476.png
[alt_alt 13_ _alt 13]: https://i0.wp.com/www.vnjohn.com/wp-content/uploads/2020/12/image-46.png?ssl=1
[alt 14]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/2b12ab54cebb4cd297a029c2ba4fb14b.png
[alt_alt 14_ _alt 14]: https://i0.wp.com/www.vnjohn.com/wp-content/uploads/2020/12/image-47.png?ssl=1
[alt 15]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/4efa35c48d4940a897c4c0b5d9d97f3c.png
[alt_alt 15_ _alt 15]: https://i0.wp.com/www.vnjohn.com/wp-content/uploads/2020/12/image-56.png?ssl=1
[alt 16]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/e690806ea01848e2a80fe3c152618065.png
[alt_alt 16_ _alt 16]: https://i0.wp.com/www.vnjohn.com/wp-content/uploads/2020/12/image-52-1024x676.png?ssl=1
[alt 17]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/4cb23ab4012440ffa1bdc72d217b1bc7.png
[alt_alt 17_ _alt 17]: https://i0.wp.com/www.vnjohn.com/wp-content/uploads/2020/12/image-55.png?ssl=1
[https_www.cnblogs.com_twoheads_p_10150063.html]: https://www.cnblogs.com/twoheads/p/10150063.html