Java并发编程(三) : synchronized底层原理、优化Monitor重量级锁、轻量级锁、自旋锁(优化重量级锁竞争)、偏向锁

浅浅的花香味﹌ 2022-12-29 02:27 236阅读 0赞

> [Java3yのsynchronized][Java3y_synchronized]

# 一、 Monitor 概念 #

### 1、 Java 对象头 `(重点)` ###

> **`对象头`**

**对象头包含两部分：`运行时元数据（Mark Word）`和`类型指针 (Klass Word)`**

1.  **`运行时元数据`**
    
     *  `哈希值（HashCode）`，可以看作是**堆中对象的地址**
     *  `GC分代年龄（年龄计数器）` (用于新生代from/to区晋升老年代的标准, 阈值为15)
     *  **锁状态标志** (用于JDK1.6对synchronized的优化 -> 轻量级锁)
     *  **线程持有的锁**
     *  **偏向线程ID** (用于JDK1.6对synchronized的优化 -> 偏向锁)
     *  偏向时间戳
2.  **`类型指针`**
    
     *  指向`类元数据InstanceKlass，确定该对象所属的类型`。指向的其实是**方法区中存放的类元信息**

说明：**如果对象是数组，还需要记录数组的长度**

*  以 32 位虚拟机为例,普通对象的对象头结构如下，其中的`Klass Word`为`类型指针`，指向`方法区`对应的`Class对象`；

![1583651065372][]

*  数组对象  
    ![1583651088663][]
 *  **其中 Mark Word 结构为: `无锁(001)、偏向锁(101)、轻量级锁(00)、重量级锁(10)`**  
    ![1583651590160][]
 *  所以一个对象的结构如下：  
    ![1583678624634][]

### 2、 Monitor 原理 (Synchronized底层实现-重量级锁) ###

> **多线程同时访问临界区: 使用重量级锁**
> 
>  *  JDK6对Synchronized的优先状态：`偏向锁–>轻量级锁–>重量级锁`

*  `Monitor`被翻译为`监视器`或者`管程`

###### `每个Java对象`都可以`关联一个(操作系统的)Monitor`，如果使用`synchronized`给`对象上锁（重量级）`，该`对象头的MarkWord`中就被设置为`指向Monitor对象`的`指针` ######

> 下图原理解释:
> 
>  *  当`Thread1`访问到`synchronized(obj)`中的`共享资源`的时候
>     
>      *  首先会将synchronized中的`锁对象`中`对象头`的`MarkWord`去尝试指向`操作系统`的`Monitor`对象. 让锁对象中的MarkWord和Monitor对象相关联. 如果关联成功, 将obj对象头中的`MarkWord`的`对象状态`从01改为10。
>      *  因为Monitor没有和其他的obj的MarkWord相关联, 所以`Thread1`就成为了该`Monitor`的Owner(所有者)。
>      *  又来了个`Thread1`执行synchronized(obj)代码, 它首先会看看能不能执行该`临界区`的代码; 它会检查obj是否关联了Montior, 此时已经有关联了, 它就会去看看该Montior有没有所有者(Owner), 发现有所有者了(Thread2); `Thread1`也会和该Monitor关联, 该线程就会进入到它的`EntryList(阻塞队列)`;
>      *  当`Thread2`执行完`临界区`代码后, Monitor的`Owner(所有者)`就空出来了. 此时就会`通知`Monitor中的EntryList阻塞队列中的线程, 这些线程通过`竞争`, 成为新的`所有者`  
>         ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70]

![1583652360228][]

*  刚开始时`Monitor`中的`Owner为null`
 *  **当Thread-2 执行synchronized(obj)\{\}代码时就会将Monitor的所有者Owner 设置为 Thread-2，上锁成功，Monitor中同一时刻只能有一个Owner**
 *  当Thread-2 占据锁时，如果线程Thread-3，Thread-4也来执行synchronized(obj)\{\}代码，就会进入`EntryList`中变成`BLOCKED状态`
 *  **Thread-2 执行完同步代码块的内容，然后唤醒 EntryList 中等待的线程来竞争锁，`竞争时是非公平的 (仍然是抢占式)`**
 *  `图中 WaitSet 中的Thread-0，Thread-1 是之前获得过锁，但条件不满足进入 WAITING 状态的线程，后面讲wait-notify 时会分析`

> **注意：**
> 
>  *  synchronized 必须是进入同一个锁对象的monitor 才有上述的效果; —> 也就要使用同一把锁
>  *  不加 synchronized的锁对象不会关联监视器，不遵从以上规则  
>     ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 1]

> 它加锁就是依赖底层操作系统的 `mutex`相关指令实现, 所以会造成`用户态和内核态之间的切换`, 非常耗性能 !
> 
>  *  在JDK6的时候, 对synchronized进行了优化, 引入了`轻量级锁, 偏向锁`, 它们是在JVM的层面上进行加锁逻辑, 就没有了切换的消耗~

### 3、synchronized原理 ###

代码如下

static final Object lock = new Object();
    static int counter = 0;
    public static void main(String[] args) { 
        synchronized (lock) { 
            counter++;
        }
    }

*  反编译后的部分字节码  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 2]

> 注意：方法级别的 synchronized 不会在字节码指令中有所体现

### 4、synchronized 原理进阶 ###

*  小故事

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 3]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 4]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 5]

### 5、轻量级锁 (用于优化Monitor这类的重量级锁） ###

> 通过`锁记录`的方式, 场景 : **多个线程交替进入临界区**

*  **`轻量级锁的使用场景`: 如果一个对象虽然有多个线程要对它进行加锁，但是加锁的时间是错开的（也就是没有人可以竞争的），那么可以使用`轻量级锁来进行优化`。**
 *  轻量级锁对使用者是透明的，即语法仍然是`synchronized` (jdk6对synchronized的优化)，假设有两个方法同步块，利用同一个对象加锁
 *  **`eg:`** 线程A来操作临界区的资源, `给资源加锁,到执行完临界区代码,释放锁`的过程, 没有线程来竞争, 此时就可以使用`轻量级锁`; **如果`这期间`有线程来竞争的话, 就会`升级为重量级锁(synchronized)`**

static final Object obj = new Object();
    public static void method1() { 
         synchronized( obj ) { 
             // 同步块 A
             method2();
         }
    }
    public static void method2() { 
         synchronized( obj ) { 
             // 同步块 B
         }
    }

*  每次指向到`synchronized代码块`时，都会在`栈帧中`创建`锁记录（Lock Record）对象`，**`每个线程都会包括一个锁记录的结构`**，锁记录内部可以储存`对象的MarkWord`和`锁对象引用reference`  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 6]  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 7]

![1583755737580][]

*  让`锁记录`中的`Object reference指向锁对象地址`，并且尝试用`CAS(compare and sweep)`将`栈帧中的锁记录的(lock record 地址 00)`替换`Object对象的Mark Word`，将**Mark Word 的值(01)存入锁记录(lock record地址)中** \------`相互替换`
    
     *  01 表示 `无锁` `(看Mark Word结构, 数字的含义)`
     *  00表示 `轻量级锁`  
        ![1583755888236][]

**`重点:`**

*  如果`cas替换成功`, 获得了轻量级锁，那么`对象`的`对象头储存的就是锁记录的地址和状态00`，如下所示
    
     *  **线程中锁记录, 记录了锁对象的锁状态标志; 锁对象的对象头中存储了锁记录的地址和状态, 标志哪个线程获得了锁**
     *  此时`栈帧`中存储了`对象的对象头`中的`锁状态标志`,年龄计数器,哈希值等; `对象的对象头中`就存储了`栈帧中锁记录的地址和状态00`, 这样的话`对象`就知道了是`哪个线程锁住自己`。  
        ![1583755964276][]
 *  如果`cas替换失败，有两种情况` : **① 锁膨胀 ② 重入锁失败**
    
     *  1、如果是`其它线程`已经持有了`该Object的轻量级锁`，那么表示**有竞争**，将进入 **`锁膨胀阶段`**
        
         *  此时`对象Object`对象头中已经存储了别的线程的`锁记录地址 00`,指向了其他线程;
     *  2、如果是`自己的线程已经执行了synchronized进行加锁`，那么`再添加一条 Lock Record 作为重入锁的计数` – 线程多次加锁, 锁重入
        
         *  在上面代码中,`临界区中`又调用了`method2`, method2中又进行了一次`synchronized加锁操作`, 此时就会在`虚拟机栈`中再开辟一个method2方法对应的栈帧(栈顶), 该栈帧中又会存在一个`独立`的`Lock Record`, 此时它发现`对象的对象头中指向的就是自己线程中栈帧的锁记录`; 加锁也就失败了. 这种现象就叫做`锁重入`; 线程中有多少个锁记录, 就能表明该线程对这个对象加了几次锁 (锁重入计数)  
            ![1583756190177][]

**轻量级锁解锁流程 :**

*  当`线程退出synchronized代码块`的时候，**如果获取的是`取值为 null 的锁记录` ，表示有`锁重入`，这时重置锁记录**，`表示重入计数减一`  
    ![1583756357835][]
 *  当线程退出synchronized代码块的时候，如果`获取的锁记录取值不为 null`，那么使用cas将Mark Word的值恢复给对象, 将直接替换的内容还原。
    
     *  成功则解锁成功 (轻量级锁解锁成功)
     *  失败，表示有竞争, 则`说明轻量级锁进行了锁膨胀`或`已经升级为重量级锁`，**进入重量级锁解锁流程 (Monitor流程)**

### 6、锁膨胀 ###

*  如果在尝试`加轻量级锁`的过程中，`cas替换操作无法成功`，这是**有一种情况就是其它线程已经为这个对象加上了轻量级锁**，这是就要进行`锁膨胀(有竞争)`，**`将轻量级锁变成重量级锁。`**
 *  当 Thread-1 进行轻量级加锁时，Thread-0 已经对该对象加了轻量级锁, 此时发生`锁膨胀`  
    ![1583757433691][]
 *  这时Thread-1加轻量级锁失败，**进入锁膨胀流程**
    
     *  **因为`Thread-1`线程加轻量级锁失败, 轻量级锁没有阻塞队列的概念**, 所以此时就要`为对象申请Monitor锁(重量级锁)`，让`Object指向重量级锁地址 10`，然后`自己进入Monitor 的EntryList 变成BLOCKED状态`

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 8]

*  当`Thread-0 线程`执行完`synchronized同步块`时，**使用cas将Mark Word的值恢复给对象头**, 肯定恢复失败,因为对象的对象头中存储的是`重量级锁的地址,状态变为10了`之前的是00, 肯定恢复失败。那么会`进入重量级锁的解锁过程`，即按照`Monitor的地址找到Monitor对象，将Owner设置为null，唤醒EntryList中的Thread-1线程`

### 7、自旋锁优化 (优化重量级锁竞争) ###

*  当发生`重量级锁竞争的时候`，还可以使用`自旋来进行优化 (不加入Monitor的阻塞队列EntryList中)`，如果当前线程自旋成功（即在自旋的时候持锁的线程释放了锁），**那么当前线程就可以不用进行上下文切换`(持锁线程执行完synchronized同步块后,释放锁,Owner为空,唤醒阻塞队列来竞争,胜出的线程得到cpu执行权的过程)`** 就获得了`锁`
 *  优化的点: 不用将`线程`加入到阻塞队列, 减少cpu切换.

1.  `自旋重试成功的情况`  
    ![1583758113724][]
2.  `自旋重试失败的情况`，**自旋了一定次数还是没有等到 持锁的线程释放锁**, 线程2就会加入Monitor的阻塞队列(EntryList)  
    ![1583758136650][]

*  **自旋会`占用 CPU 时间`，单核 CPU 自旋就是浪费，多核 CPU 自旋才能发挥优势**。
 *  在 `Java 6 之后自旋锁是自适应`的，比如对象刚刚的一次自旋操作成功过，那么认为这次自旋成功的可能性会高，就多自旋几次；反之，就少自旋甚至不自旋，总之，比较智能。Java 7 之后不能控制是否开启自旋功能

### 8、偏向锁 (biased lock) (用于优化轻量级锁重入) ###

> 场景: 没有竞争的时候, 一个线程中多次使用`synchronized`需要重入加锁的情况; **(只有一个线程进入临界区)**
> 
>  *  在经常需要竞争的情况下就不使用偏向锁, 因为偏向锁是默认开启的, 我们可以通过JVM的配置, 将偏向锁给关闭
>  *  **将进入临界区的线程的ID, 直接设置给锁对象的Mark word, 下次该线程又获取锁, 发现线程ID是自己, 就不需要CAS了**

*  在`轻量级的锁`中，我们可以发现，如果同一个线程对同一个对象进行`重入锁`时，**也需要执行CAS替换操作，这是有点耗时。**
 *  那么java6开始引入了`偏向锁`，**将进入临界区的线程的ID, 直接设置给锁对象的Mark word, 下次该线程又获取锁, 发现线程ID是自己, 就不需要CAS了**
    
     *  **升级为轻量级锁的情况 (会进行偏向锁撤销)** : 获取偏向锁的时候, 发现线程ID不是自己的, 此时通过CAS替换操作, 操作成功了, 此时该线程就获得了锁对象。( `此时是交替访问临界区, 撤销偏向锁, 升级为轻量级锁`)
     *  **升级为重量级锁的情况 (会进行偏向锁撤销)** : 获取偏向锁的时候, 发现线程ID不是自己的, 此时通过CAS替换操作, 操作失败了, 此时说明发生了锁竞争。( `此时是多线程访问临界区, 撤销偏向锁, 升级为重量级锁`)

例如:

public class Test { 
        static final Object obj = new Object();
    
        public static void m1() { 
            synchronized (obj) { 
                // 同步块A
                m2();
            }
        }
    
        public static void m2() { 
            synchronized (obj) { 
                // 同步块B
                m3();
            }
        }
    
        public static void m3() { 
            synchronized (obj) { 
                // 同步块C
            }
        }
    }

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 9]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 10]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 11]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 12]

--------------------

##### 8.1、偏向锁状态 (了解) #####

*  `运行时元数据（Mark Word）`的结构如下:  
    ![1583762169169][]

###### \- `Normal：一般状态，没有加任何锁`，前面62位保存的是对象的信息，**最后2位为状态（01），倒数第三位表示是否使用偏向锁（未使用：0）** ######

###### \- `Biased：偏向状态，使用偏向锁`，前面54位保存的当前线程的ID，**最后2位为状态（01），倒数第三位表示是否使用偏向锁（使用：1）** ######

###### \- `Lightweight：使用轻量级锁`，前62位保存的是锁记录的指针，**最后2位为状态（00）** ######

###### \- `Heavyweight：使用重量级锁`，前62位保存的是Monitor的地址指针，**最后2位为状态(10)** ######

[![img][]][img 1]

*  如果开启了偏向锁（默认开启），在创建对象时，对象的Mark Word后三位应该是101
 *  但是偏向锁默认是**有延迟**的，不会再程序一启动就生效，而是会在程序运行一段时间（几秒之后），才会对创建的对象设置为偏向状态
 *  如果没有开启偏向锁，对象的Mark Word后三位应该是001

#### **一个对象的创建过程** ####

###### \- 如果开启了`偏向锁（默认是开启的）`，那么对象刚创建之后，**Mark Word 最后三位的值101**，并且这是它的`ThreadId`，`epoch`，`age(年龄计数器)`都是`0`，**在加锁的时候进行设置这些的值.** ######

###### \- `偏向锁默认是延迟`的，不会在程序启动的时候立刻生效，如果想避免延迟，可以添加虚拟机参数来禁用延迟：**`-XX:BiasedLockingStartupDelay=0`来禁用延迟** ######

###### \- **注意** : `处于偏向锁的对象解锁后，线程id仍存储于对象头中` ######

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 13]  
输出结果:  
![在这里插入图片描述][20201219230503664.png]

*  测试`禁用偏向锁`：如果`没有开启偏向锁`，那么对象创建后最后三位的值为`001`，这时候它的hashcode，age都为0，hashcode是第一次用到`hashcode`时才赋值的。在上面测试代码运行时在添加 VM 参数`-XX:-UseBiasedLocking`禁用偏向锁`（禁用偏向锁则优先使用轻量级锁）`，退出`synchronized`状态变回 **001**
    
     *  禁止偏向锁, 虚拟机参数`-XX:-UseBiasedLocking`; 优先使用`轻量级锁`
     *  输出结果: 最开始状态为001，然后加轻量级锁变成00，最后恢复成001

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 14]

##### 8.2、撤销偏向锁-hashcode方法 (了解) #####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 15]

*  测试 `hashCode`：当`调用对象的hashcode方法`的时候就会`撤销这个对象的偏向锁`，**因为使用偏向锁时没有位置存`hashcode`的值了**

--------------------

##### 8.3、撤销偏向锁-发生锁竞争 (升级为重量级锁) #####

> 小故事: 线程A门上刻了名字, 但此时线程B也要来使用房间了, 所以要将偏向锁升级为轻量级锁. (线程B要在线程A使用完房间之后`(执行完synchronized代码块)`,再来使用; 否则就成了竞争获取锁对象, 此时就要升级为`重量级锁`了)

> **偏向锁、轻量级锁的使用条件, 都是在于多个线程没有对同一个对象进行`锁竞争`的前提下, 如果有`锁竞争`,此时就使用重量级锁。**

*  这里我们演示的是`偏向锁`撤销, 变成`轻量级锁`的过程，**那么就得满足轻量级锁的使用条件，就是没有线程对同一个对象进行`锁竞争`**，我们使用`wait` 和 `notify` 来辅助实现
 *  虚拟机参数`-XX:BiasedLockingStartupDelay=0`确保我们的程序最开始使用了`偏向锁`

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 16]

*  输出结果，**最开始使用的是`偏向锁`**，**但是第二个线程尝试获取对象锁时(前提是: 线程一已经释放掉锁了,也就是执行完synchroized代码块)**，发现本来对象`偏向的是线程一`，那么偏向锁就会失效，加的就是`轻量级锁`  
    ![在这里插入图片描述][20201219234530954.png]

##### 8.4、撤销偏向锁 - 调用 wait/notify (只有重量级锁才支持这两个方法) #####

> **（调用wait方法会导致锁膨胀而使用重量级锁）**

*  **会使对象锁变成重量级锁**，因为`wait/notify方法之后重量级锁才支持`

### 9、批量重偏向 ###

*  如果`对象被多个线程访问，但是没有竞争 (上面撤销偏向锁就是这种情况: 一个线程执行完, 另一个线程再来执行, 没有竞争)`, 这时`偏向T1的对象仍有机会重新偏向T2`
    
     *  重偏向会重置Thread ID
 *  当`撤销偏向锁101 升级为 轻量级锁00`超过`20次后（超过阈值）`，JVM会觉得是不是偏向错了，这时会在`给对象加锁时，重新偏向至加锁线程 (T2)。`

##### 9.1、批量撤销偏向锁 #####

*  当 撤销偏向锁的阈值超过40以后 ，就会将整个类的对象都改为**不可偏向**的

##### 9.2、同步省略 (锁消除) #####

> **同步省略**

1.  **线程同步的代价是相当高的，同步的后果是`降低并发性和性能`**。
2.  在动态编译同步块的时候，`JIT编译器`可以`借助逃逸分析`来判断同步块所**使用的锁对象是否只能够被一个线程访问而没有被发布到其他线程。**
3.  如果没有，`那么JIT编译器在编译这个同步块的时候就会取消对这部分代码的同步。这样就能大大提高并发性和性能。`这个**取消同步的过程就叫同步省略，也叫锁消除**。

*  例如下面的智障代码，`根本起不到锁的作用`

public void f() { 
        Object hellis = new Object();
        synchronized(hellis) { 
            System.out.println(hellis);
        }
    }

*  代码中对hellis这个对象加锁，但是hellis对象的生命周期只在f()方法中，并不会被其他线程所访问到，所以在JIT编译阶段就会被优化掉，优化成：

public void f() { 
        Object hellis = new Object();
    	System.out.println(hellis);
    }

**字节码分析**

*  代码

public void f() { 
        Object hellis = new Object();
        synchronized(hellis) { 
            System.out.println(hellis);
        }
    }

*  注意：字节码文件中并没有进行优化，可以看到加锁和释放锁的操作依然存在，**`同步省略操作是在解释运行时发生的`**

![image-20200729103650309][]

--------------------

[Java3y_synchronized]: https://mp.weixin.qq.com/s?__biz=MzU4NzA3MTc5Mg==&mid=2247483980&idx=1&sn=c9b620834adb889ad8ccedb6afdcaed1&chksm=fdf0ea13ca8763058e59bde10f752264a5de6fb9dd087ca2a4290f90da4b2c2e78407613c5cd&scene=178&cur_album_id=1657204970858872832#rd
[1583651065372]: /images/20221120/c3479003b8dc45d8b733dfab33224ef7.png
[1583651088663]: /images/20221120/265cd5fb814440808df5f2eeb34d6515.png
[1583651590160]: https://img-blog.csdnimg.cn/img_convert/0ffaeb7ddf7d71801bfd3eeb00754162.png
[1583678624634]: https://img-blog.csdnimg.cn/img_convert/1844b5e3159baa3c8fb78478daa1580b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20201219192811839.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw,size_16,color_FFFFFF,t_70
[1583652360228]: https://img-blog.csdnimg.cn/img_convert/98c3189e41fd654fe34ead273ec76eba.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20201219200615817.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20201219201521709.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20201219202939493.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20201219203225659.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/202101191526347.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 6]: https://img-blog.csdnimg.cn/20201219205033458.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 7]: https://img-blog.csdnimg.cn/20210119153328743.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw,size_16,color_FFFFFF,t_70
[1583755737580]: https://img-blog.csdnimg.cn/img_convert/4d42844c6ddc19a6f94d954ae5a0cc79.png
[1583755888236]: https://img-blog.csdnimg.cn/img_convert/87f63c5373eed35d0bf65e0b510a7660.png
[1583755964276]: https://img-blog.csdnimg.cn/img_convert/68c40cfc17498b1514fe31af8a896eaf.png
[1583756190177]: https://img-blog.csdnimg.cn/img_convert/9e36f456637862001c9c58ded2651a3b.png
[1583756357835]: https://img-blog.csdnimg.cn/img_convert/6e5c1ae4a693ec26d8c629fda57737c3.png
[1583757433691]: https://img-blog.csdnimg.cn/img_convert/c3e0a92d418c70280fd2a0bb730eea82.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 8]: https://img-blog.csdnimg.cn/20201219214748700.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw,size_16,color_FFFFFF,t_70
[1583758113724]: https://img-blog.csdnimg.cn/img_convert/39ed180b2ab7eae1bc37ebba0a819c4c.png
[1583758136650]: https://img-blog.csdnimg.cn/img_convert/36162c78749df99fcd83560e3896aef0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 9]: https://img-blog.csdnimg.cn/20201219223917148.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 10]: https://img-blog.csdnimg.cn/20201219223934280.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 11]: https://img-blog.csdnimg.cn/20210202174407252.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 12]: https://img-blog.csdnimg.cn/20210202174448323.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw,size_16,color_FFFFFF,t_70
[1583762169169]: https://img-blog.csdnimg.cn/img_convert/4b3e8d91dabdf79eb0ab250835c6bbc0.png
[img]: https://img-blog.csdnimg.cn/img_convert/461b804dda9e6ee0737faf0519ca295c.png
[img 1]: https://nyimapicture.oss-cn-beijing.aliyuncs.com/img/20200608145101.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 13]: https://img-blog.csdnimg.cn/20201219230315160.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw,size_16,color_FFFFFF,t_70
[20201219230503664.png]: https://img-blog.csdnimg.cn/20201219230503664.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 14]: https://img-blog.csdnimg.cn/20201219231656738.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 15]: https://img-blog.csdnimg.cn/202012192322377.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 16]: https://img-blog.csdnimg.cn/20201219234125463.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw,size_16,color_FFFFFF,t_70
[20201219234530954.png]: https://img-blog.csdnimg.cn/20201219234530954.png
[image-20200729103650309]: https://imgconvert.csdnimg.cn/aHR0cDovL2hleWdvLm9zcy1jbi1zaGFuZ2hhaS5hbGl5dW5jcy5jb20vaW1hZ2VzL2ltYWdlLTIwMjAwNzI5MTAzNjUwMzA5LnBuZw?x-oss-process=image/format,png