一、现象描述
生产云平台监控发生Docker应用重启次数过多事故报警，经观察发现某些Docker应用不定期地出现重启现象，已严重影响服务正常提供，生产应用重启的判断条件：健康检查连续3次检查不通过，生产健康检查间隔时间设置为：5s，也就是说如果应用对健康检查请求在15s内未返回结果，则云平台自动重启应用。
二、重启现象分析
2.1、线程池泄漏问题
（1）方法一：pstree命令分析
第一步：使用ssh命令远程登录应用服务器，然后输入pstree查看各进程下的线程数，初步定位出现的进程和是否发生线程泄漏，效果如下：
第二步：然后输入命令：pstree -a，具体定位问题进程所在的工程
（2）方法二：jvisualvm监控
jvm参数增加jmx监控参数：
1.#JMX监控开启，端口号：280$SERVICE_PORT
2.JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote -Djava.rmi.server.hostname=应用所在机器IP -Dcom.sun.management.jmxremote.port=未使用的端口号 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"
打开终端工具，输入：jvisualvm 命令回车进入窗口界面，然后在在《远程》菜单上右击后点击《添加远程主机》，然后设置端口点击《确定》即可
（3）线程泄漏原因分析
问题一：线程池频繁创建导致线程泄漏
经代码分析得出消息监听器频繁创建线程池，导致的线程泄漏
因此，对init函数进行改造，防止线程池的频繁创建，改造代码如下：
问题二：线程池大小设置不合理
分析：
（1）线程池频繁创建
（2）应用程序高并发异步处理业务时，线程池中的线程大小设置过大，导致线程数大量创建去处理业务，从而导致正常的http请求响应过慢；例如hg-ws联名账户子系统线程池大小设置为：20000，在业务量大的情况下经常出现重启现象
（3）应用接收到大量客户请求并进行处理，前面请求未处理完成，后面有新的请求，从而导致后边请求一直处于排队状态，请求响应时间较慢
解决方案：
（1）线程池合理创建，线程池大小设置在合理的区间内
（2）用户发送请求响应，只需业务主流程是同步执行，非主流程可以异步执行，例如：用户下单支付完成后，向统计系统发送用户交易统计的行为可以异步执行，减少请求占用时间
2.2、Full GC期间，暂停所有应用线程执行，导致请求无响应
分析方法：gc日志分析
第一步：JVM参数配置GC日志收集和输出参数
第二步：分析gc日志，可以通过专门的分析工具GCViewer进行分析，也可以通过在https://gceasy.io/网址上进行分析（本人采用线上GC分析方式）
经过对生产子系统(jdk1.8环境)的gc日志分析，发现生产应用使用的老年代的回收算法（Full Collection）是：UseParallelGC并行处理期（使用多个线程同时进行垃圾回收，多核环境下充分利用CPU资源，减少回收时间，是Server模式下的默认回收器），但在回收期间暂停应用线程的执行；Full GC的大部分原因是：MetaSpace初始化空间不够
经上面总结得出：应用Full GC时间最长长达24s，而生产应用重启主要是因为Full GC时间过长导致
因此主要采取如下方法：
1）优化JVM参数配置；例如：持久区大小、新老生代比例、回收算法等
2）健康检查间隔时间延长
应用JVM参数新增：
-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=512m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:NewRatio=1 -XX:SurvivorRatio=8
转载链接：
https://blog.csdn.net/liuhuiteng/article/details/88081727
长按二维码，关注我们
新睿云，让云服务触手可及
云主机｜云存储｜云数据库｜云网络
点击“阅读原文”参与活动
