jdk下载慢怎么办 jdk下载快速方法( 四 ) _云知道

环境中使用的arm jdk是从网上下载的，背后支持的厂商未知。

【jdk下载慢怎么办 jdk下载快速方法】关于第2点提到的这套环境中的另外一个Elasticsearch集群，我更关心的是它的GC日志中是否存在类似的现象。至于没有发生此类问题，容易理解，因为这类问题往往是业务负载特点与环境多重因素叠加下的系统性问题。现场同学配合打开了这个Elasticsearch集群的GC与JVM日志，现象同在，只是ForceSafepoint的频次低于出问题的集群。
至此，问题原因清晰的指向了arm环境与JDK版本。
后来，微服务平台TSF团队的臧琳同学介入，他提供了一个添加了debug信息的Kona JDK版本，尽管这个版本比正常版本慢了许多，更换以后，我们发现问题重现的周期明显变长。
拿到最新的JVM日志后，臧琳同学分析这些ForceSafepoint都与Inline Cache Buffer有关。当然，这可能是arm环境下所有JDK版本的共性问题，也可能仅仅是之前下载的JDK版本存在问题。
接下来，我们将环境中的JDK版本替换成正式Release的Kona JDK 。再后来，问题始终没有复现。也就是说，替换成Kona JDK后，问题解决了。
我统计了一下使用KonaJ DK后的STW中断次数与中断时间，发现有数量级的提升：

原JDK版本：每分钟STW中断5000次～18000次，每分钟中断总数据可能达到10秒～30秒。
Kona JDK：每分钟STW中断在个位数，每分钟中断总时间在100～200ms之间。

可见，Kona JDK比原来的问题JDK版本在性能上有了数量级的提升。
05 总结回顾
我们再来梳理一下整个问题的分析思路：
1. 通过堆栈分析，发现大量的线程都在做CPU计算，但 CPU资源较闲。关于大量Merge Threads的现象带有一定的迷惑性，但它是问题的“果”而非“因” 。
2. 通过GC日志分析，发现GC频次与GC时间都很低，但GC日志中存在大量的STW相关日志，需要确认关联的Safepoint类型。
3. 通过VM/Safepoint日志分析，确认了Safepoint的类型为ForceSafepoint 。通过不同环境与不同集群的现象对比，开始怀疑JDK版本存在问题。
4. 更换Kona JDK后，ForceSafepoints频次由每分钟5000多次降低到个位数，问题解决。
通过本次问题的分析，得到一个教训：问题分析初期应该认真调研集群环境。当然，最大的教训是：千万不要乱下载JDK啊！