2020-09-10T13:59:43.210 0800: 73032.559: Total time for which application threads were stopped: 0.0002853 seconds, Stopping threads took: 0.0000217 seconds 在这行日志中，提示了STW阶段持续的时间为0.0002853秒，而叫停所有的线程(Stopping threads)花费了0.0000217秒，前者包含了后者 。通常，Stopping threads的时间占比极小，如果过长的话可能与代码实现细节有关，这里不过多展开 。
回到问题，一开始就打印大量的STW日志，容易想到与偏向锁回收有关 。直到问题再次复现时，拿到了3个节点的完整的GC日志，发现无论是YGC还是FGC，触发的频次都很低，这排除了GC方面的影响 。
出现的大量STW日志，使我意识到该现象极不合理 。有同学提出怀疑，每一次中断时间很短啊？写了一个简单的工具，对每一分钟的STW中断频次、中断总时间做了统计：
统计结果显示：
正常每分钟都有5秒左右的中断 。在11:29～11:30之间，中断频次陡增，这恰恰是问题现象开始出现的时间段 。每分钟的中断总时间甚至高达20～30秒 。这就好比，一段1公里的马路上，正常是遇不见任何红绿灯的，现在突然增加了几十个红绿灯，实在是让人崩溃 。这些中断很好的解释了“所有的线程都在做CPU计算，然而CPU资源很闲”的现象 。
04 关于Safepoint的调查
Safepoint有多种类型，为了确认Safepoint的具体类型，继续让现场同学协助，在jvm.options中添加如下参数，打开JVM日志：
-XX: PrintSafepointStatistics 等待问题再次复现的过程中，我基于ES运行日志中统计了每一分钟的读写请求频次：
-XX:PrintSafepointStatisticsCount=10
-XX: UnlockDiagnosticVMOptions
-XX:-DisplayVMOutput
-XX: LogVMOutput
-XX:LogFile=
读写请求次数是相对平稳的，这排除了用户请求陡增方面的原因 。
拿到JVM日志时，看到大量的Safepoint类型为ForceSafepoint：
而偏向锁回收相关的Safepoint却应该是长这样的：
这让我疑惑了 。开始在网上搜索ForceSafepoint的触发原因，结果，一无所获 。
查看hotspot的源码，发现至少有5种相关场景：
可见，ForceSafepoint是一个“杂烩”，就像统计图中的“Others”一项 。从这里开始，我将JDK加入到了“重点嫌疑人”清单中 。
继续分析JVM日志 。在每一条Safepoint日志中，同时记录了当时的线程总数(threads: total一列)：
回顾一下，出现问题时，三个节点的线程总数有明显出入，问题发生后，线程总数是增多的，尤其是Lucene Merge Threads 。
“多个Lucene Merge任务”与“陡增的ForceSafepoint/STW中断”，哪个是“因”哪个是“果”？
依据JVM日志中统计了每一分钟的ForceSafepoint次数，以及线程总数的变化 。将两条曲线叠加在一起，得到下图：
推荐阅读
- 云图人力资源中心app下载 云图下载安装
- 9个日常快速减肥好方法 什么减肥方法最快
- 教大家键盘突然失灵Windows10如何快速开启屏幕键盘的方法
- 用什么办法能让白菜快速包心 莲花白不包心怎么办
- 学兔兔标准免费下载网 免费标准下载网
- 2021免费下载音乐软件 想听歌下载什么软件好
- 蔬菜园土壤如何松土 菜地土壤板结如何快速改良问题
- 教你一分钟抠出头发丝 ps快速抠头发丝教程
- 学生如何能快速赚钱，身无分文最快赚钱方法
- 白醋加姜片三天祛斑 快速去掉老年斑