一、現(xiàn)象描述

? ? ? ? 近期，生產(chǎn)云平臺監(jiān)控發(fā)生Docker應用重啟次數(shù)過多事故報警，經(jīng)觀察發(fā)現(xiàn)某些Docker應用不定期地出現(xiàn)重啟現(xiàn)象，已嚴重影響服務正常提供

生產(chǎn)應用重啟的判斷條件：健康檢查連續(xù)3次檢查不通過?
生產(chǎn)健康檢查間隔時間設置為：5s，也就是說如果應用對健康檢查請求在15s內(nèi)未返回結果，則云平臺自動重啟應用

二、重啟現(xiàn)象分析

2.1、線程池泄漏問題

（1）、方法一：pstree命令分析

? ? ? ?第一步：使用ssh命令遠程登錄應用服務器，然后輸入pstree查看各進程下的線程數(shù)，初步定位出現(xiàn)的進程和是否發(fā)生線程泄漏，效果如下：

? ? ? ? 第二步：然后輸入命令：pstree -a，具體定位問題進程所在的工程

? ?（2）、方法二：jvisualvm監(jiān)控

? ? ? ? jvm參數(shù)增加jmx監(jiān)控參數(shù)：

#JMX監(jiān)控開啟，端口號：280$SERVICE_PORT 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）、線程泄漏原因分析

問題一：線程池頻繁創(chuàng)建導致線程泄漏

經(jīng)代碼分析得出消息監(jiān)聽器頻繁創(chuàng)建線程池，導致的線程泄漏

? ? ? ? ? 因此，對init函數(shù)進行改造，防止線程池的頻繁創(chuàng)建，改造代碼如下：

private Object lock = new Object();public void init() {if (pool != null) {return;}//同步鎖機制，瞬間高并發(fā)場景防護synchronized (lock) {if (pool != null) {return;}int availableProcessors = Runtime.getRuntime().availableProcessors() * 2 + 1;pool = Executors.newFixedThreadPool(availableProcessors, new ThreadFactory() {public Thread newThread(Runnable r) {Thread thread = new Thread(r);String threadName = "MakeUpListener_Thread_" + threadCount.incrementAndGet();thread.setName(threadName);return thread;}});....代碼省略} }

問題二：線程池大小設置不合理

分析：

（1）、線程池頻繁創(chuàng)建

（2）、應用程序高并發(fā)異步處理業(yè)務時，線程池中的線程大小設置過大，導致線程數(shù)大量創(chuàng)建去處理業(yè)務，從而導致正常的http請求響應過慢；例如hg-ws聯(lián)名賬戶子系統(tǒng)線程池大小設置為：20000，在業(yè)務量大的情況下經(jīng)常出現(xiàn)重啟現(xiàn)象

（3）、應用接收到大量客戶請求并進行處理，前面請求未處理完成，后面有新的請求，從而導致后邊請求一直處于排隊狀態(tài)，請求響應時間較慢

解決方案：

（1）、線程池合理創(chuàng)建，線程池大小設置在合理的區(qū)間內(nèi)

（2）、用戶發(fā)送請求響應，只需業(yè)務主流程是同步執(zhí)行，非主流程可以異步執(zhí)行，例如：用戶下單支付完成后，向統(tǒng)計系統(tǒng)發(fā)送用戶交易統(tǒng)計的行為可以異步執(zhí)行，減少請求占用時間

2.2、Full GC期間，暫停所有應用線程執(zhí)行，導致請求無響應

分析方法：gc日志分析

第一步：JVM參數(shù)配置GC日志收集和輸出參數(shù)

JAVA_OPTS="$JAVA_OPTS -verbose:gc"JAVA_OPTS="$JAVA_OPTS -Xloggc:/apps/dbconfig/gc.log"JAVA_OPTS="$JAVA_OPTS -XX:NumberOfGCLogFiles=20"JAVA_OPTS="$JAVA_OPTS -XX:GCLogFileSize=30m"JAVA_OPTS="$JAVA_OPTS -XX:+UseGCLogFileRotation"JAVA_OPTS="$JAVA_OPTS -XX:+PrintVMOptions"JAVA_OPTS="$JAVA_OPTS -XX:+PrintGCDetails"JAVA_OPTS="$JAVA_OPTS -XX:+PrintGCTimeStamps"JAVA_OPTS="$JAVA_OPTS -XX:+PrintHeapAtGC"JAVA_OPTS="$JAVA_OPTS -XX:+PrintGCDateStamps"JAVA_OPTS="$JAVA_OPTS -XX:+PrintTenuringDistribution"JAVA_OPTS="$JAVA_OPTS -XX:+PrintAdaptiveSizePolicy"JAVA_OPTS="$JAVA_OPTS -XX:+PrintGCApplicationStoppedTime"JAVA_OPTS="$JAVA_OPTS -XX:+PrintGCApplicationConcurrentTime"JAVA_OPTS="$JAVA_OPTS -XX:+PrintConcurrentLocks"JAVA_OPTS="$JAVA_OPTS -XX:+TraceClassUnloading"

第二步：分析gc日志，可以通過專門的分析工具GCViewer進行分析，也可以通過在https://gceasy.io/網(wǎng)址上進行分析（本人采用線上GC分析方式）

? ? ? ? 經(jīng)過對生產(chǎn)子系統(tǒng)(jdk1.8環(huán)境)的gc日志分析，發(fā)現(xiàn)生產(chǎn)應用使用的老年代的回收算法（Full Collection）是：UseParallelGC并行處理期（使用多個線程同時進行垃圾回收，多核環(huán)境下充分利用CPU資源，減少回收時間，是Server模式下的默認回收器），但在回收期間暫停應用線程的執(zhí)行；Full GC的大部分原因是：MetaSpace初始化空間不夠

經(jīng)上面總結得出：應用Full GC時間最長長達24s，而生產(chǎn)應用重啟主要是因為Full GC時間過長導致
因此主要采取如下方法：
1）、優(yōu)化JVM參數(shù)配置；例如：持久區(qū)大小、新老生代比例、回收算法等
2）、健康檢查間隔時間延長
應用JVM參數(shù)新增：-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=512m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:NewRatio=1 -XX:SurvivorRatio=8

?

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結

以上是生活随笔為你收集整理的生产Docker应用重启排查经历的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。