线上故障分析： Memory cgroup out of memory: Kill process ...（结合dmesg 、jstack命令和jvisualvm工具综合分析）

柔光的暖阳◎ 2023-02-28 08:50 14阅读 0赞

1、在某一天时段，我生产上的程序突然宕机了，部署在linux 程序被Killed掉；

使用 dmesg -T >my.log 命令输出到my.log日志，查看系统日志，至于dmesg有什么用，参考这篇博客：

[https://blog.csdn.net/shuihupo/article/details/80905641?utm\_medium=distribute.pc\_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.nonecase&depth\_1-utm\_source=distribute.pc\_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.nonecase][https_blog.csdn.net_shuihupo_article_details_80905641_utm_medium_distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.nonecase_depth_1-utm_source_distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.nonecase]

2、根据dmesg -T的结果观察日志，发现如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70][]

查找到这条信息：Memory cgroup out of memory: Kill process 7187 (java) score 1007 or sacrifice child

为什么程序会被kill掉了？原来在Linux下， 允许应用可以预申请内存，预申请的内存如果超过了Linux最大剩余内存，由于系统的保护机制，就会停掉默认内存占用最大的应用进程；

参考这篇博客：[https://blog.csdn.net/renfufei/article/details/78178757?utm\_source=blogxgwz5][https_blog.csdn.net_renfufei_article_details_78178757_utm_source_blogxgwz5]

3、查看GC日志，发现一分钟内进行了3次Full GC

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 1][]

在哪些情况下，程序会进行Full GC呢，继续参考博客：

[https://blog.csdn.net/YHYR\_YCY/article/details/52566105?utm\_medium=distribute.pc\_relevant\_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase&depth\_1-utm\_source=distribute.pc\_relevant\_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase][https_blog.csdn.net_YHYR_YCY_article_details_52566105_utm_medium_distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase_depth_1-utm_source_distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase]

4、登录了生产的应用，发现除了宕机的其它机器上，其它机器都没有业务请求的日志，只有宕机的这一台有程序运行业务日志，是因为运维的nigix配置问题，把所有的请求都分到了宕机的这台机器上，另外的应用机器，虽然服务正常启动，但是没有接收到分发过来的用户请求；

所以我暂时把此问题理解成了运维的锅；

解决方案：给机器加内存，并且修改nigix配置，使用户请求均衡分发到每一台应用上；

5、以为问题就这样解决了，但是没有过多久，半个月以后，又发生了程序内存占用高，频繁报错的情况，虽然没有由于内存过高导致系统被Linux停掉，但很多用户的请求接口超时，无法正常使用；

先从logback中找到了这样的异常日志：Could not get a resource from the pool\#012\#011at redis.clients.util.Pool.getResource

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 2][]

查看代码，之前redisPool没有设置大小，默认为8，尝试修改一下，修改为配置文件中设置的100

spring.redis.pool.max-active=100

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 3][]

6、然后使用jstack -l pid，查看线程stack有什么异常：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 4][]

发现里面有大量的redisson  waiting（程序里面使用到的redis客户端）状态：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 5][]

其实在上面，我们看到已经使用了JedisPool来作为redis客户端连接，这里又引入了RedissonClient，显得有些重复多余了

（Redisson 不仅封装了 redis ，还封装了对更多数据结构的支持，以及锁等功能，相比于Jedis 的话功能更加强大）

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 6][]

7、继续分析jstack输出的线程stack日志，有很多 Mysql  TIMED\_WAITING（先关注，这个问题在下面继续分析）

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 7][]

8、这里logback还改了一下输出日志级别，之前只打印了info日志，现在BusinessException异常的改成error级别日志，看看还有哪些程序错误没有通过error日志抛出来：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 8][]

9、然后程序上线了一版，继续监控可能会出现的问题：

发现了mysql锁等待超时异常（也印证了上面第7步 jstack日志中，很多 Mysql  TIMED\_WAITING 状态的问题）：

Error updating database.  Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Lock wait timeout exceeded; try restarting transaction\#012\#\#\# The error may involve com\*\*\*\*\*\*\*\*.dao.iface.SessionRecordMapper.updateByPrimaryKey

![20200724171904481.png][]

这里的异常可能之前日期就有发生过，由于上面第8步，之前的info日志输出，可能导致了忽略关注，现在才看到；

10、分析Mysql  Lock wait timeout exceeded异常:

com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Lock wait timeout exceeded：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 9][]

这里的一行sql语句，执行update \*\*\* where 的时候，报错；先看一下这个表结构：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 10][]

在表t\_sys\_session\_rec中，sessionId是作为主键，主键是默认走索引的，并且在innodb引擎下，是支持行锁的；这一行数据，相同sessionId的情况，sql执行的并发量也不是很大，为什么会频繁出现等待锁超时呢？

找到执行sql的代码，updateByPrimaryKey方法：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 11][]

找  updateSession调用的方法，在/ticket校验方法里面，用户每次过来校验ticket的时候，都会调用这个方法，更新updateSession：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 12][]

就是这里，发生mysql锁频繁超时的地方，是否还有其它地方去竞争这行数据，t\_sys\_session\_rec 这张表的资源呢？

11、发现定时任务在竞争表资源：

这个定时的大概思路是：每60秒执行一次，写一个线程监听，while(true)，然后一直轮询，查询数据库后台表t\_sys\_session\_rec，当前时间now()，比update字段时间值，计算出来大于 overTime 6个小时的session记录，逐条置为无效

（这种定时任务执行方式不推荐）：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 13][]

12，找到mapper.xml中的  sessionRecordMapper.selectAllWillExpireSession 方法：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 14][]

上面where条件里面的createIp字段和updateTime字段并没有加索引，导致全表扫描，并且随着表中数据越来越多的情况下，导致了锁表情况发生，所以上面的 sessionRecordMapper.updateByPrimaryKey()方法才会发生锁等待超时；

（其实根源问题在于这里，由于这个锁表操作，/ticket接口的其它请求线程，是先获取redis连接，并且获取以后没有释放redis连接，然后再去获取mysql锁，由于拿不到mysql锁，并且redis连接池默认连接数8，并且mysql连接池设置的是100，所以先是redis连接不够用，在上面第5、第6步抛出了异常Could not get a resource from the pool at redis.clients.util.Pool.getResource）

![20200727100124621.png][]

![20200727095825978.png][]

13、解决方案：

开始想了一种简单解决方案，清除表中记录，createIp字段和updateTime字段增加索引，那么就不需要重启应用程序，让用户正常继续使用程序，但是能解决问题吗？

updateTime经常被更新，如果字段值经常被修改，那么每次数据库重建索引的开销也很大，短期来看，可以临时解决现在的问题，就算加了索引以后，这里的where条件查询对updateTime使用了函数计算，表达式，也会导致查询索引失效；

为了验证这一点，在测试环境，先给updateTime字段加上索引，去掉其它几个字段的where条件检索，然后explain执行一下sql语句，发现扫描的type 是 all：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 15][]

（还有哪些情况会导致索引失效，可以参考这里：

[https://blog.csdn.net/bless2015/article/details/84134361?utm\_medium=distribute.pc\_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-5.nonecase&depth\_1-utm\_source=distribute.pc\_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-5.nonecase][https_blog.csdn.net_bless2015_article_details_84134361_utm_medium_distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-5.nonecase_depth_1-utm_source_distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-5.nonecase]）

所以最后的解决方案：是删除t\_sys\_session\_rec记录表，把用户校验的ticket存取都用redis（这里涉及修改的代码就比较多了，不全贴出来）；

![20200721101108509.png][]

14、到这里还没有结束，由于还有内存占用过高的问题，继续从线上服务器导出堆dump文件分析：

jmap -dump:live,format=b,file=/data1/springBoot/heap.hprof  pid

![20200720213202921.png][]

（上面的命令，是实时导出dump文件，会影响系统运行性能；还有另外一种导出dump文件方式，在java进程启动参数配置：

加上 例如 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/heap.hprof，

完整启动参数：

JAVA\_OPTS="$JAVA\_OPTS -server -Xms3G -Xmx3G -Xss256k -XX:PermSize=128m -XX:MaxPermSize=128m -XX:+UseParallelOldGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/heap.hprof -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/usr/local/gc.log -XX:NewSize=1G -XX:MaxNewSize=1G"

这样在程序宕机之前，会给你生成一份dump文件，参考这篇博客：[https://www.cnblogs.com/m2492565210/p/7498438.html][https_www.cnblogs.com_m2492565210_p_7498438.html]）

15、使用jdk本地自带的jvisualvm工具，打开D:\\Program Files\\Java\\jdk1.8.0\_201\\bin\\jvisualvm.exe，分析dump出来的文件：点击文件，装入：![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 16][]

选择刚才dump出来的文件heap.hprof：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 17][]

16、发现如下些对象，占用比例是最多的：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 18][]

HashMap里面的Node对象内部类（HashMap$Node，HashMap底层其实就是Node对象组成的数组，Node是内部类），Hashtable对象里面的Entry内部类（Hashtable$Entry），还有char\[\]，byte\[\]，jdbc连接（Mysql  Lock wait timeout exceeded 产生的过多对象侧面在这里印证了）等等，这些是占用内存最高，或者实例创建最多的对象：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 19][]

17、结合代码再来看上面的堆内存分析问题：

这个系统，是一个单点集成登录功能，程序调用最多的就是 \*/ticket 票据校验接口，看接口入口的第50行代码，

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 20][]

仅仅是取参数，里面就创建了两个HashMap对象 ，为了就是把Map对象中的key和value全部遍历一遍然后去空格？这样的开销很大，本来HashMap对象就是用哈希算法存取对象的一种方式，以存储空间换时间的理念集合对象，HashMap会比其它集合更占用内存空间

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 21][]

退出这个方法，再回到刚才/ticket校验接口那里，52行代码处，paramMap = javaUtil.getMapForSync(request); 进方法：

里面又创建了HashMap：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 22][]

这样一来，每天/ticket 校验接口访问量在40~50w左右，那么光HashMap参数对象就会创建150w个左右。

还有程序其它有使用com.alibaba.fastjson.JSONObject地方：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 23][]

进入 com.alibaba.fastjson.JSONObject 对象中：在JSONObject对象的底层，也是基于Map实现的

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 24][]

所以也就解释了jvisualvm分析出来那么多Map对象的原因了；

所以除了上面mysql的 Lock wait timeout exceeded异常，这里的代码也是需要优化的地方；

18、继续看jvisualvm中String对象占用的问题：

代码这里，创建了好几个字符串对象，只是用来校验一下是否必填？（类似这样的写法，在其他地方也发现了）

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 25][]

String类的底层实现，其实是char\[\]数据，我们可以在源码中看到，常用构造方法：这里的this.value就是一个char\[\]数组：

this.value = original.value;

![20200720222453645.png][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 26][]

所以也就解释了，上图中用jvisualvm分享出来，那么多String和char\[\]对象了：

19、关于Hasstable$Entry 那么多对象，搜了一下，代码中并没有使用过Hashtable，

但是使用了Properties，Properties的底层就是一个Hashtable，但是程序中也没有使用太多Properties对象，所以为什么那么多Hashtable$Entry对象，也暂时不知道了

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 27][]

总结问题：主要还是之前系统设计不合理导致锁表，代码编写不规范，导致程序内存过高的问题；

在这里总结分析一下，如果有不对的地方，欢迎指出；

[https_blog.csdn.net_shuihupo_article_details_80905641_utm_medium_distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.nonecase_depth_1-utm_source_distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.nonecase]: https://blog.csdn.net/shuihupo/article/details/80905641?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.nonecase&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.nonecase
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70]: /images/20230209/c63bc9b2820c437daec445a5b024cb34.png
[https_blog.csdn.net_renfufei_article_details_78178757_utm_source_blogxgwz5]: https://blog.csdn.net/renfufei/article/details/78178757?utm_source=blogxgwz5
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 1]: /images/20230209/4f55c2b667de45b78a95bc2a6cae707c.png
[https_blog.csdn.net_YHYR_YCY_article_details_52566105_utm_medium_distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase_depth_1-utm_source_distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase]: https://blog.csdn.net/YHYR_YCY/article/details/52566105?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 2]: /images/20230209/d65851e2f4c34d7b8995959892a25b85.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 3]: /images/20230209/14263f61ec4a43c9b047c0791453dacd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 4]: /images/20230209/7e9d8c757f0141988f38c04edf11b902.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 5]: /images/20230209/a4ca5646cbf441cc9f5aea2c352759af.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 6]: /images/20230209/28f65eba772d42f691ffba2e5d43d911.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 7]: /images/20230209/33de49358a9f45dcbc290f5e3007b448.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 8]: /images/20230209/2b8eed9766b841edaf7abac73fc75500.png
[20200724171904481.png]: /images/20230209/af4059defd9c49f59c9939e3f0cfafd0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 9]: /images/20230209/5d12dc52a6934070bb4b51eb9298c53d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 10]: /images/20230209/afe48786187d46bb929296eb178c4790.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 11]: /images/20230209/d2205099df3b411ea5e8971d288b464f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 12]: /images/20230209/d95d4f96915343ada13aead92b1ff095.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 13]: /images/20230209/22eabbdc991c41a69b3332c318d916d4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 14]: /images/20230209/a0d69a9fb3e24389b0a37d0f7bd7efe9.png
[20200727100124621.png]: /images/20230209/3153c22a307a43a6b7455af91c6992b2.png
[20200727095825978.png]: /images/20230209/d389bbeab7564bd98917c336f617eb8b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 15]: /images/20230209/1b87396a5afc466a8f9cfe5326530b55.png
[https_blog.csdn.net_bless2015_article_details_84134361_utm_medium_distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-5.nonecase_depth_1-utm_source_distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-5.nonecase]: https://blog.csdn.net/bless2015/article/details/84134361?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-5.nonecase&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-5.nonecase
[20200721101108509.png]: /images/20230209/322604e711a7421a83a2a442fd7ed7d4.png
[20200720213202921.png]: /images/20230209/73c035eac9014e83a0af1de0d8d9825d.png
[https_www.cnblogs.com_m2492565210_p_7498438.html]: https://www.cnblogs.com/m2492565210/p/7498438.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 16]: /images/20230209/6bbb684870b74f9fbedab619b0fe89ec.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 17]: /images/20230209/f0125142a00842b186ce5888ce675b97.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 18]: /images/20230209/f29e8b029de94fb9a2da36e7beff6cea.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 19]: /images/20230209/fe69ba2d5f204f4c913613fc7b16ec71.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 20]: /images/20230209/3147462d3fcf42619be131175c5894bd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 21]: /images/20230209/d2b80fdaeff246808eee9b2e09340921.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 22]: /images/20230209/1d60bf0696a6414b9ebd8a50f1f0abda.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 23]: /images/20230209/ad5e8eda87c74d4f9fe9f1c493f9cdcc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 24]: /images/20230209/dbf0b2f2054f44a6afb14b1e9e0af73d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 25]: /images/20230209/f073bff9ad8542e8b76548fde6f0b871.png
[20200720222453645.png]: /images/20230209/dfb06b9d7c4a4dffb68b479f7a78a690.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 26]: /images/20230209/7bbab3fdf7dc453cbec9b7c8a50f22ce.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlanVzdGRvaXQ_size_16_color_FFFFFF_t_70 27]: /images/20230209/99061afae2d1489a9ddf2df3654365bb.png