Spring - 循环依赖

水深无声 2021-09-01 02:09 564阅读 0赞

### 循环依赖 ###

*  0. 声明
 *  1. 循环依赖简介
 *  2. 正文
 *   *  2.1 注解属性注入
     *  2.2 构造器注入
 *  3. 小结

# 0. 声明 #

循环依赖可谓是面试的重点，恰好看到这篇循环依赖讲解极为清楚的一篇文章，故转载。[Spring源码-循环依赖（附25张调试截图）][Spring_-_25]

# 1. 循环依赖简介 #

在介绍循环依赖之前，我们先介绍一下为什么会产生循环依赖？在`Spring`中，我们完成`Bean`的注入有三种方式.

1.  构造方法注入
2.  setter 注入
3.  注解注入

例如有两个`Bean`，分别为`A`和`B`。他们互相为对方的属性，彼此依赖，这就产生了循环依赖。`A`依赖`B`，但是`B`还没有完成实例化，不能注入给`A`。而`B`又依赖于`A`，`A`同样没有完成实例化，不能注入给`B`，由此彼此等待对方实例化的问题便是循环依赖。

需要注意的是，`Spring`可以解决属性注入的循环依赖，但是并不能解决构造方法的循环依赖问题。

# 2. 正文 #

`Spring` 在哪些情况下会出现循环依赖错误？哪些情况下能自身解决循环依赖，又是如何解决的？本文将介绍笔者通过本地调试 `Spring` 源码来观察循环依赖的过程。

## 2.1 注解属性注入 ##

首先本地准备好一份 `Spring` 源码，笔者是从 `Github` 上`Clone` 下来的一份，然后用 `IDEA` 导入，再创建一个 `module` 用于存放调试的代码。

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

本次调试有三个类，`A`、`B` 通过注解 `@Autowired` 标注在属性上构成循环依赖，`Main` 为主函数类。

@Component("A")
    public class A { 
     @Autowired
     B b;
    }

@Component("B")
    public class B { 
     @Autowired
     A a;
    }

public class Main { 
     public static void main(String[] args) { 
      ApplicationContext context =
        new ClassPathXmlApplicationContext("spring-config.xml");
      A a = (A) context.getBean("A");
      B b = (B) context.getBean("B");
     }
    }

可以先试着运行下，并不会报错，说明这种情况下的循环依赖能由`Spring`解决。

我们要观察如何解决循环依赖，首先需要知道 `@Autowired`标注的属性是如何注入的，如 `B`是怎么注入到 `A`中的。

由于 `A`、`B`的 scope 是 `single`，且默认 `non-lazy`，所以在 `ClassPathXmlApplicationContext`初始化时会预先加载`A`、`B`，并完成实例化、属性赋值、初始化等步骤。`ClassPathXmlApplicationContext`的构造方法如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 1]  
       其中 `refresh`是容器的启动方法，点进去，然后找到我们需要的那一步，即实例化 `A`、`B`的步骤：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 2]  
       `finishBeanFactoryInitialization`会先完成工厂的实例化，然后在最后一步实例化 `A`、`B`：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 3]  
       `preInstantiateSingletons` 将依次对 `non-lazy singleton`依次实例化，其中就有 `A`、`B`：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 4]  
       `A`、`B`不是工厂类，则直接通过 `getBean` 触发初始化。首先会触发 `A`的初始化。

`getBean` => `doGetBean` ，再通过 `getSingleton` 获取 `Bean`。注意在 `doGetBean` 中有两个 `getSingleton` 方法会先后执行，本文用 `getSingleton-C` 和 `getSingleton-F` 来区分。第一个是尝试从缓存中获取，这时缓存中没有 `A`，无法获得，则执行第二个，通过工厂获得。

protected <T> T doGetBean(final String name, @Nullable final Class<T> requiredType,
    			@Nullable final Object[] args, boolean typeCheckOnly) throws BeansException { 
    
    		// ...
    		Object bean;
    		// 首先从缓存中获取 Bean
    		Object sharedInstance = getSingleton(beanName);
    		if (sharedInstance != null && args == null) { 
    			// ...
    		}
    
    		else { 
    				// ...
    				// 缓存中获取不到，则在 BeanFactory 中获取
    				if (mbd.isSingleton()) { 
    					sharedInstance = getSingleton(beanName, () -> { 
    						try { 
    							return createBean(beanName, mbd, args);
    						}
    						catch (BeansException ex) { 
    							// Explicitly remove instance from singleton cache: It might have been put there
    							// eagerly by the creation process, to allow for circular reference resolution.
    							// Also remove any beans that received a temporary reference to the bean.
    							destroySingleton(beanName);
    							throw ex;
    						}
    					});
    					bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
    				}
    
    				// ... 
    		}
    		return (T) bean;
    	}

这里会执行 `getSingleton-F` 来获取单例 `Bean` `A`：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 5]  
       这里为 `getSingleton-F` 传入了个 `Lambda` 表达式给 `ObjectFactory` 接口类型的 `singletonFatory`。

public Object getSingleton(String beanName, ObjectFactory<?> singletonFactory)

public interface ObjectFactory<T> { 
     T getObject() throws BeansException;
    }

所以将会创建一个 `ObjectFactory`的匿名类对象 `singletonFactory`，而其 `getObject`方法的实现将调用 `createBean`。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 6]  
       `getObject` => `createBean` => `doCreateBean`，创建 `A`的 Bean，关于 `doCreateBean`，在 《如何记忆 Spring 的生命周期》 中有进行介绍。主要有 4 个步骤：（1）实例化，（2）属性赋值，（3）初始化，（4）注册回调函数。下面看下 B 是在哪一步注入到 A 中。

首先看下是不是实例化。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 7]  
       在实例化完成后，`bean` 中的 `b` 仍为 `null`，说明不是实例化。那再看下一步，属性赋值。

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

在 `populateBean` 执行后，`bean` 中的 `b` 不再是`null`了，而已经是`B` 的对象了，而且 `b` 的 `a`属性也不是 `null`，是此时正在创建的 `bean`，说明已经成功完成了依赖注入。所以 "`@Autowired` 标注的属性是如何注入的" 和 “`Spring`如何解决循环依赖” 两个问题的答案都在`populateBean` 这一步中。那再重新进入`populateBean` 看下。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 9]  
       其中会依次调用`BeanPostProcessor` 的`postProcessProperties`方法。在 `getBeanPostProcessors` 返回的`List`中有 `AutowiredAnnotationBeanPostProcessor`，将负责 `@Autowired` 的注入。

`AutowiredAnnotationBeanPostProcessor` 的 `postProcessProperties` 方法如下所示：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 10]  
       先找到被 `@Autowired`标注的`b` 属性，再通过`inject`注入。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 11]  
       进入 `inject` 方法，由于`A` 依赖`B`，这里将通过 `beanFactory.resolveDependency`获得 `B` 的`bean`。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 12]  
       在成功获取`B`的`Bean` 后，再通过反射注入。

![在这里插入图片描述][20200721230749957.png]

现在需要关注的就是 `resolveDependency`，这里解决 `A => B`的依赖，需要去获取 `B`，将仍然通过 `getBean`获取，和之前说 `getBean` 获取 `A` 的过程类似，只是这次换成了`B`，调用栈如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 13]

仍然将通过 `doCreateBean` 来创建 `B`的 `bean`。

那么问题来了，之前说过 `doCreateBean` 会进行属性赋值，那么由于 `B` 又依赖 `A`，所以需要将 `A` 注入到 `B` 中，可是 `A` 也还正在进行 `doGetBean`。那么 `Spring` 是怎么解决的循环依赖，关注 `B` 的 `populateBean` 就能知道答案了。

由于 `B` 依赖于 `A`，所以需要将 `A` 注入`B`，该过程和前面说的 ”将 `B` 注入 `A`“类似，通过 `getBean` 来获得 `A`。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 14]  
       `getBean => doGetBean => getSingleton`，又是熟悉的步骤，但这次 `getSingleton-C`中发生了不一样的事，能够成功获得 `A` 的缓存。

![在这里插入图片描述][20200721231359217.png_x-oss-pro3dhbmdfemhhb18_size_16_color_FFFFFF_t_70]

首先尝试在 `singletoObjects` 中获取，失败。接着尝试从 `earlySingletonObjects` 中获取，失败。最后在 `singletonFactories` 中获取到 `singletonFactory`，并通过 `getObject` 获取到 `A` 的 `bean`。

这三者被称作三级缓存，在 `getSingleton-C` 方法中会依次从这三级缓存中尝试获取单例 `Bean`。当从第三级缓存获取到 `A` 后，会将其从第三级缓存中移除，加入到第二级缓存。

/** Cache of singleton objects: bean name to bean instance. */
    // 缓存单例Bean
    private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
    
    /** Cache of early singleton objects: bean name to bean instance. */
    // 缓存正在创建，还未创建完成的单例Bean
    private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);
    
    /** Cache of singleton factories: bean name to ObjectFactory. */
    // 缓存单例bean的工厂
    private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);

我们可以看到 `singletonFactories` 中存有 `A`和 `B`，它们是什么时候被加到三级缓存中的呢？就是在 `doCreateBean` 中做 `populateBean` 的前一步通过 `addSingeletonFactory` 把 `beanName` 和 `ObjectFactory` 的匿名工厂类加入到第三级缓存中。当调用 `singletonFactory.getObject` 方法时，将调用 `getEarlyBeanReference` 获取 `A` 的 `Bean`。

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

`getEarlyBeanReference` 会返回 `A` 的引用，虽然 `A`还在创建，未完成。

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

让我们想下后面会发生的事：

1.  `B` 成功获取到了 `A` 的引用，完成属性赋值；
2.  `B` 完成 `doCreateBean`，将返回，`A` 成功获取到 `B` 的 `Bean`，完成属性赋值，最后完成 `A` 的 `Bean` 的创建。

最后 `A`、`B` 的 `Bean` 都完成创建。

之所以通过注解属性注入不会存在循环依赖问题，是因为 `Spring` 记录了正在创建的 `Bean`，并提前将正在创建的 `Bean` 的引用交给了需要依赖注入的 `Bean`，从而完成闭环，让 `B` 创建成功，不会继续尝试创建 `A`。

在这个过程中最关键的是 `Bean` 的引用，而要有`Bean` 的引用便必须完成 `doCreateBean` 中的第一步**实例化**。

我们这里是将 `@Autowired` 标注在属性上，而依赖注入发生在第二步**属性赋值**，这时才能成功获取到引用。

下面我们试下修改`A`、`B` 为构造器注入，让依赖注入发生在第一步实例化中。

## 2.2 构造器注入 ##

@Component("A")
    public class A { 
     B b;
    
     @Autowired
     public A(B b) { 
      this.b = b;
     }
    }

@Component("B")
    public class B { 
     A a;
    
     @Autowired
     public B(A a) { 
      this.a = a;
     }
    }

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 17]  
       构造器的注入将发生在`doCreateBean`的第一步 `createBeanInstance`，具体方法如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 18]  
       获取 `A` 的构造器，执行 `autowireConstructor` 。然后调用`ConstructorResolver` 的 `createArgument`方法处理构造函数的参数，由于构造器被 `@Autowired` 标注，将使用 `resolveAutowiredArgument`处理注入参数，接着又是熟悉的步骤，调用栈如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 19]  
       处理依赖注入，会通过 `getBean` 获得 `B`，在 `doCreateBean` 中进行`B`实例化。

那我们就再进入 `B` 实例化的第一步`createBeanInstance`方法，调用栈如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 20]  
       `B` 的构造方法依赖`A`，则尝试通过`doGetBean`获取 `A`。由于 `A` 没有在 `doCreateBean` 中完成实例化，所以 `getSingleton-C` 中无法获得 `A`的缓存，则只能通过`getSingleton-F`方法尝试获得`A`。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 21]  
       但在`getSingleton-F`中的`beforeSingletonCreation`方法将对循环依赖进行检查。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 22]  
       `singletonsCurrentlyInCreation` 是一个`set`，由于`A` 已经 都在 `getSingleton-F`中执行过一遍了，已经被添加到了 `singletonsCurrentlyInCreation`，所以这里第二次通过 `getSingleton-F` 获取 `A`时，`add` 返回`false`，将抛出`BeanCurrentlyInCreationException` 异常。

# 3. 小结 #

对比以上两种方式 “属性注入” 和 “构造器注入”，都是 `A => B => A`，区别在于 `B => A` 时，“属性注入” 在 `getSingleton-C` 中会通过缓存获取到 `A` 的引用，而 “构造器注入”，则由于不存在 `A` 引用，也自然无法通过缓存获得，便会尝试再次通过 `getSingleton-F` 获取，而及时被 `beforeSingletonCreation` 检查抛出循环依赖异常。

[Spring_-_25]: https://mp.weixin.qq.com/s/GqghXjMgdcTL9c1fPbfWUw
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70]: /images/20210813/2718d6cca5264641ac48ca46d8c31c36.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 1]: /images/20210813/cada499155a94a59903e4e120d4c6e49.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 2]: /images/20210813/3e51e6c418af4e909ba334bbcac3217e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 3]: /images/20210813/db68fc3bf642495da6c2b3e01220c56a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 4]: /images/20210813/873f26ab5ff14983ad6c786b09b8db9e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 5]: /images/20210813/aab60bc5f7334992be5c16c72e9557d2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 6]: /images/20210813/242503e522c94330a1f0b9d6c280e3cd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 7]: /images/20210813/37165f7623de444c8f058fc33373f902.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 8]: /images/20210813/6026b26e6bf14e3a8b8a23b2f91c085a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 9]: /images/20210813/7532b4dff1aa4385996af5b3ea38eb87.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 10]: /images/20210813/bc2ed7e6c660474c87bdf930789d97dd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 11]: /images/20210813/fafe1c59be7c48a4bd130816d5de4aaf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 12]: /images/20210813/7564c02c7b81464c8635f2c1e1f12130.png
[20200721230749957.png]: /images/20210813/a871dea1f7a5499fb027537ef09a051d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 13]: /images/20210813/355bdb0e09704c6bba7d395689d85b81.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 14]: /images/20210813/ddb1fd31657e4fd7a9b38500ebe14a5b.png
[20200721231359217.png_x-oss-pro3dhbmdfemhhb18_size_16_color_FFFFFF_t_70]: /images/20210813/d534296bf2f942f6ae3e712a1904080e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 15]: /images/20210813/d1c53d2b9f6a4eecaf9e1c1bc48416b6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 16]: /images/20210813/3f322d39a66046eeafe8eac23257fe21.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 17]: /images/20210813/de22f78a4284403691b96e88ea8e1003.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 18]: /images/20210813/50ad62860cff4ac2bf3f5dfa725ab146.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 19]: /images/20210813/2a18950f122b46c3884c0bc6d884a2a1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 20]: /images/20210813/003805f980dc48dfb9accb0a25dd60c1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 21]: /images/20210813/81b79c8658aa426e9be448edf01ad8cf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 22]: /images/20210813/2be3727c276f474886f3a60ef63d705f.png