共计 3032 个字符，预计需要花费 8 分钟才能阅读完成。
1. 前言
- 本文仅分享本人在工作中遇到的问题时的解决方案和思路，以及排查的过程。重点还是分享排查的思路，知识点其实曾经挺老了。如有疑难或形容不妥，欢送赐教。
2. 问题表象
- 在工程启动的时候，零碎的申请会有一波超时，从监控来看，JVM 的 GC（G1）稳定较大，CPU 稳定较大，各个业务应用的线程池稳定较大，内部 IO 耗时减少。
3. 先说论断
- 因为 JIT 的优化，导致系统启动时触发了热点代码的编译，且为 C2 编译，引发了 CPU 占用较高，进而引发一系列问题，最终导致局部申请超时。
4. 排查过程
其实知识点就放在那里，如何将理论遇到的问题和知识点分割到一起并能更粗浅的了解这部分常识，这或者就是排查和剖析的意义，而后积淀为教训，进而成长。
4.1 最后的排查
- 其实咱们的工程是一个算法排序工程，外面或多或少也加了一些小的模型和大大小小的缓存，而且从监控上来看，JVM 的 GC 突刺和 CPU 突刺工夫极为靠近（这也是一个监控平台工夫不够精准的起因）。所以在后期，我消耗了大量精力和工夫去排查 JVM，GC 的问题。
- 首先举荐给大家一个网站：https://gceasy.io/，真的剖析 GC 日志巨好用。配合以下的 JVM 参数打印 GC 日志：
-XX:+PrintGC 输入 GC 日志
-XX:+PrintGCDetails 输入 GC 的具体日志
-XX:+PrintGCTimeStamps 输入 GC 的工夫戳（以基准工夫的模式，你启动的时候相当于 12 点，跟实在工夫无关）-XX:+PrintGCDateStamps 输入 GC 的工夫戳（以日期的模式，如 2013-05-04T21:53:59.234+0800）-Xloggc:../logs/gc.log 日志文件的输入门路-
因为看到 YGC 重大，所以先后尝试了如下的办法：
- 调整 JVM 的堆大小。即 -Xms, -Xmx 参数。有效。
- 调整回收线程数目。即 -XX:ConcGCThreads 参数。有效。
- 调整冀望单次回收工夫。即 -XX:MaxGCPauseMillis 参数，有效，甚至更惨。
- 以上调整混合测试，均有效。
- 鸡贼的办法。在加载模型之后 sleep 一段时间，让 GC 安稳，而后再放申请进来，这样操作之后 GC 的确有些恶化，然而刚开始的申请依然有超时。（当然了，因为问题基本不在 GC 上）
4.2 换个思路
- 依据监控上来看，线程池，内部 IO，启动时都有显著的 RT 回升而后降落，而且趋势十分统一，这种个别都是系统性问题造成的，比方 CPU，GC，网卡，云主机超售，机房提早等等。所以 GC 既然无奈根治，那么就从 CPU 方面动手看看。
- 因为系统启动时 JVM 会产生大量 GC，无奈辨别是因为系统启动还没预热好就来了流量还是说无论启动了多久，流量一来就会出问题。而我之前排查 GC 的操作，即加 sleep 工夫，恰好帮我看到了这个问题，因为能显著的看出，GC 稳定的工夫，和超时的工夫，工夫点上曾经差了很多了，那就是说，与 GC 无关，无论 GC 曾经如许安稳，流量一来，还是要超时。
4.3 剖析利器 Arthas
不得不说，Arthas 真的是一个很好用的剖析工具，节俭了很多简单的操作。
- Arthas 文档：https://arthas.aliyun.com/doc…
- 其实要剖析的外围还是流量最开始到来的时候，咱们的 CPU 到底做了什么，于是咱们应用 Arthas 剖析流量到来时的 CPU 状况。其实这部分也能够应用 top -Hp pid , jstack 等命令配合实现，不开展叙述。
- CPU 状况，仅展现重要局部：
图中能够看出 C2 CompilerThread 占据了十分多的 CPU 资源。
4.4 问题的外围
- 那么这个 C2 CompilerThread 到底是什么呢。
- 《深刻了解 JAVA 虚拟机》其实有对这部分的叙述，这里我就大白话给大家解释一下。
- 其实 Java 在最开始运行的时候，你能够了解为，就是傻乎乎的依照你写的代码执行上来，称之为 ” 解释器 ”，这样有一个益处，就是很快，Java 搞成.class，很快就能启动，跑起来了，然而问题也很显著啊，就是运行的慢，那么聪慧的 JVM 开发者们做了一件事件，他们如果发现你有一些代码频繁的执行，那么他们就会在运行期间帮你把这段代码编译成机器码，这样运行就会飞快，这就是即时编译（just-in-time compilation 也就是 JIT）。然而这样也有一个问题，就是编译的那段时间，消耗 CPU。而 C2 CompilerThread，正是 JIT 中的一层优化（共计五层，C2 是第五层）。所以，罪魁祸首找到了。
5. 尝试解决
- 解释器和编译器的关系能够如下所示：
- 就像下面说的，解释器启动快，然而执行慢。而编译器又分为以下五个档次。
第 0 层：程序解释执行，默认开启性能监控性能（Profiling），如果不开启，可触发第二层编译；第 1 层：可称为 C1 编译，将字节码编译为本地代码，进行简略、牢靠的优化，不开启 Profiling；第 2 层：也称为 C1 编译，开启 Profiling，仅执行带办法调用次数和循环回边执行次数 profiling 的 C1 编译；第 3 层：也称为 C1 编译，执行所有带 Profiling 的 C1 编译；第 4 层：可称为 C2 编译，也是将字节码编译为本地代码，然而会启用一些编译耗时较长的优化，甚至会依据性能监控信息进行一些不牢靠的激进优化。- 所以咱们能够尝试从 C1，C2 编译器的角度去解决问题。
5.1 敞开分层编译
减少参数：-XX:-TieredCompilation -client（敞开分层编译，开启 C1 编译）- 成果稀烂。
- CPU 使用率继续高水位（相比于调整前）。的确没了 C2 thread 的问题，然而猜想因为代码编译的不够 C2 那么优良，所以代码继续性能低下。
- CPU 截图：
5.2 减少 C2 线程数
减少参数：-XX:CICompilerCount=8 复原参数：-XX:+TieredCompilation- 成果个别，依然有申请超时。然而会少一些。
- CPU 截图：
5.3 推论
- 其实从下面的剖析能够看出，如果绕不过 C2，那么必然会有一些抖动，如果绕过了 C2，那么整体性能就会低很多，这是咱们不愿看见的，所以敞开 C1，C2，间接以解释器模式运行我并没有尝试。
5.4 最终计划
- 既然这部分抖动绕不过来，那么咱们能够应用一些 mock 流量来接受这部分抖动，也能够称之为预热，在工程启动的时候，应用提前录制好的流量来使零碎热点代码实现即时编译，而后再接管真正的流量，这样就能够做到实在流量不抖动的成果。
后话
- 本文着重分享解决和剖析的过程，知识点没有重点剖析。更多知识点请看“参考文章”局部。
- 本文如有问题欢送各位校对。
参考文章
- 【对于 java：-XX：-TieredCompilation 到底做什么】https://www.codenong.com/3872…
- 【如同是下面那篇文章的原版】https://stackoverflow.com/que…
- 【C2 Compiler Thread】https://blog.csdn.net/chenxiu…
- 【C2 CompilerThread9 长时间占用 CPU 解决方案】https://blog.csdn.net/m0_3788…
- 《深刻了解 Java 虚拟机第二版》第四局部的“早期 (运行期) 优化”
- 【深入分析 JVM 中线程的创立和运行原理 || JIT（future）】https://www.cnblogs.com/silyv…
- 【HotSpot 虚拟机的分层编译（Tiered Compilation）】https://blog.csdn.net/u013490…
正文完
