jdk下载慢怎么办（jdk下载快速方法）

2022-07-23 03:34:30 浏览：318 作者：管理员

【商户信息】

类目：知识大全

联系人：

微信号：
Q Q 号：
手机号：
浏览量：

318

【货源详情】

导游词：

作者为了解决JDK的性能问题，从堆栈分析到GC分析，再到Safepoint原因分析，最终定位问题的根本原因与所使用的JDK版本有关。成文化后，与所有Java相关开发的同学分享这次的经验。

01发生了问题

笔者最近在工作中遇到了这样的问题。一位客户新上线了elastic search APP应用程序，运行一段时间后速度非常慢，导致呼叫超时。重新启动后服务会恢复，但每3-4小时就会出现一次问题。

对于这个问题，我身边的同事也帮着做了简单的分析，发现存在大量的Merge线程。我该怎么办？根据我以前的问题定位经验，一般通过Thread Dump日志分析，可以找到问题原因的正确方向，分析该问题反复的原因。如果按照这个思路，分析问题应该不会那么复杂。 But，之后剧本出现了波折。

02困惑的堆栈日志

由于网络隔离，客户只能合作获取Thread Dump日志。我们还向客户强调获取Thread Dump日志的技术，每个节点每隔几秒获取一次，并将其输出到独立的文件。集群涉及三个节点。这三个节点统称为39、158和211。问题再现后，得到了第一个Thread Dump文件：

根据文件的大小，可以看出39个节点是大概率的问题节点。那个Thread Dump日志明显出了很多。查询变慢或堵塞通常表现为大量的工作器热太忙。这意味着活动线程数显著增加。另一方面，对于ES(elasticsearch，以下简称es )的默认查询行为，如果一个节点有问题，则会影响整个查询。

首先，比较从三个节点中选择的一个Thread Dump文件的线程的整体情况。

节点名称

http://www.Sina.com/http://www.Sina.com /

366

341

282

264

221

162

http://www.Sina.com/http://www.Sina.com /

按线程池对统计信息进行分类：

http://www.Sina.com/http://www.Sina.com /

线程总数

进一步深入分析了39个节点的Thread Dump文件，发现的异常之处总结如下。

1. Lucene Merge Thread达到77个，其中一个线程的调用堆栈如下所示：

2.8个线程争用锁定了ExpiringCache :

3.8个线程进行HashMap#hash计算：

在现象1中，虽然叙述了同时进行Merge的线程有77个，但是不知道是这些Merge任务同时被触发，还是系统处理太慢而处于这种状态。RUNNABLE考虑到这是一个新上线的APP交易，环境信息与使用态度调查同样重要。

AITING

我开始怀疑这个特殊的使用方法。集群中存在多个写入活跃的索引，但每分钟的写入量很小，在KB到几MB的水平上。这意味着所有Flush都是周期性触发器，可能不会在超过默认阈值后触发。这种写入方式会生成大量的小文件。我试着从几个索引采样新生成的Segment文件，但我确信每次生成时它都是非常小的文件。

关于第二个症状，我仔细阅读了Java.io.UNIX文件系统的源代码：

IME_WAITING

多个线程正在冲突地调用ExpiringCache#put操作。该方面反映了文件列表的高频变化，表明系统中存在高频闪存和Merge操作。

这意味着在“小雨飘飘”的帖子中被动触发Flush，如果周期相同，则同时触发，多个Shard同时合并的概率变高，加剧了我对使用态度的怀疑。

因此，我们开始在测试环境中模拟这种用法，以创建相似的分片数并控制写入频率。计划至少运行一天测试程序，以观察是否可以再现此问题。程序运行的时候，我继续查Thread Dump日志。

当问题在现场再现时，客户协助获取CPU利用率和负载信息，结果发现CPU资源非常空闲。以前，同事也在调查IO资源，但是很闲。这样可以消除对系统资源的影响。此时，也请参阅LOCKED

一天过去后，在当地的测试环境中，问题无法再现。使用姿势虽然不优雅，但我不认为是问题的核心。

节点名称

如果使用jstack命令获取Thread Dump日志，则必须将JVM流程放入Safepoint中。这相当于整个过程都是先挂起的。获取的Thread Dump日志也是进程挂起时各线程的瞬间状态。

所有繁忙的线程都正好在做CPU计算，但CPU不忙。3

现场APP应用程序没有打开GC日志。考虑到问题还没有再现，用jstat工具看GC次数和GC统计时间的意义不大。通过将以下参数手动添加到jvm.options中，使现场人员打开GC日志：

8:-XX: PrintGCDetails

8:-xx:printgcdatestamps

8:-xx : printtenuringdistribution

8:-xx : printgcapplicationstoppedtime

8:-Xloggc:logs/gc.log

8:-xx :用户逻辑文件旋转

8:-xx : numberofgclogfiles=32

8:-xx : gclogfilesize=32m

追加

PrintGCApplicationStoppedTime用于在GC日志中记录每个JVM进程发生的停止-世界(STW )中断。通常，这种STW的中断起因于GC，也可能与偏转锁定有关。

刚重新启动，现场的人就发来了GC日志tail的结果。这是为了验证配置是否有效。奇怪的是，刚重新启动的进程继续打印STW日志：

STW日志(…totaltimeforwhichapplicationthreadswerestopped…)应在此简要说明。

JVM可能需要执行全局操作，如GC、偏转锁定回收等。在这种情况下，必须暂停所有正在运行的Thread。这必须依赖于JVM的Safepoint机制。 Safepoint就像设置在大街上的红灯一样。每次进入停止世界(STW )阶段时，JVM都会打印这样的日志行。

2020-09-10t 1:59336043.2100800336073032.559: totaltimeforwhichapplicationthreadswerestopped 3360.002853 seconds

该行的日志显示，停止所有线程需要0.0000217秒，而STW阶段的持续时间为0.0002853秒，而停止所有线程需要0.0000217秒，前者包括后者。通常，Stopping threads的时间占有率极小，如果太长，可能会涉及代码实现的细节，但这里很少展开。

回到问题，很容易认为从一开始就打印大量的STW日志会导致偏向锁定回收。在问题再次再现之前，拿到3个节点的完整GC日志时，发现无论是YGC还是FGC的触发频率都很低，排除了GC方面的影响。

9同学怀疑，每次中断时间都很短吧？编写简单的工具，对每分钟的STW中断频率、中断总时间进行统计：

根据统计结果：

通常每分钟有5秒左右的中断。

在11:29~11:30之间，中断频率急剧增加。这正是问题现象开始发生的时间段。每分钟的中断时间长达20~30秒。

这是因为，比如说，一公里的道路上，一般没有任何信号，但现在突然多了几十个信号，真的崩溃了。1

有几种类型的Safepoint，为了验证Safepoint的具体类型，请继续与现场同学合作，在jvm.options中添加以下参数以打开JVM日志：

- xx :打印safepointstatistics

- xx : printsafepointstatisticscount=10

- xx :解锁诊断程序vmoptions

-XX:-DisplayVMOutput

-XX: LogVMOutput

-XX:LogFile=vm_log_path

在等待问题再现的过程中，我根据ES运行日志统计了每分钟的读写要求频率：

读写请求数量相对平稳，消除了用户请求激增的原因。

检索JVM日志时，发现大量的Safepoint类型为ForceSafepoint :

与偏转锁定回收相关的Safepoint应该是这样的：

这让我很困惑。我开始在互联网上搜索ForceSafepoint的触发原因，但没有得到任何结果。

查看hotspot的源代码，至少有五个相关场景。

可以看出ForceSafepoint像统计图的“Others”一项一样是“大杂烩”。从这里开始，我把JDK添加到了“重点嫌疑人”列表中。

继续分析JVM日志。每个Safepoint日志同时记录了当时的线程总数。 (threads: total系列)。

回顾一下，出现问题时，三个节点的线程总数有明显的差异，出现问题后，线程总数增加了。特别是Lucene Merge Threads。

“多个Lucene Merge任务”和“急剧增加的ForceSafepoint/STW中断”，哪个是“原因”，哪个是“结果”？

基于JVM日志，统计了每分钟ForceSafepoint次数和线程总数的变化。将两条曲线重叠后，如下图所示。

从图中可以看出，在ForceSafepoint逐渐增加之前，后面的线程似乎在逐渐增加。也就是说，STW中断先增多，然后多个Merge任务线程开始逐渐累积。例如，一个目录突然有多个红绿灯，这个目录就会变得堵塞。

这个时候，我开始向Kona JDK队的同学请教。我把GC日志和thread dump日志分享给他，并告诉了他至今为止的发现。最大的疑点是这些异常的ForceSafepoints。我需要知道ForceSafepoints的原因。

过了一会儿，他对我说：“这是arm版本的jdk。 arm编译机器上的紧急文件柜不足，暂时无法提供调试版本的arm jdk。

突然明白了。我犯了“成见”的错误。尽管从一开始就意识到有必要对环境进行调查。

难怪不能在本地X86环境中再现。难怪在网上搜索ForceSafepoint一无所获。

下次在与客户的电话会议上交谈时，发现了以下内容。

类似的业务在另一个X86环境中没有发现这样的问题。

此arm环境具有另一个Elasticsearch群集，请求较少，但未发现此类问题。

环境中使用的arm jdk是从互联网下载的，背后支持的制造商不清楚。

对于此环境中的另一个Elasticsearch群集，我们更关心的是GC日志中是否存在类似现象。关于没有发生这样的问题，因为多是业务负荷的特征和环境的多因素重叠的系统性问题，所以很容易理解。现场的同学合作打开了这个Elasticsearch集群的GC和JVM日志。现象相同，只是ForceSafepoint的频率低于问题集群。

http://www.Sina.com/http://www.Sina.com /

随后，微服务平台TSF团队的臧琳介入，他提供了添加了debug信息的Kona JDK版本。我们发现，尽管该版本比普通版本慢了很多，但更换后问题的再现周期明显延长了。

拿到最新的JVM日志后，臧琳分析说这些ForceSafepoint都与Inline Cache Buffer有关。当然，这可能是arm环境中所有JDK版本共有的问题，也可能只是以前下载的JDK版本有问题。

然后，将环境中的JDK版本替换为正式发行版中的Kona JDK。在那之后，问题一直没有再现。也就是说，用Kona JDK替换后，问题解决了。

在统计使用KonaJ DK后的STW中断次数和中断时间时，发现位数上升：

原始JDK版本：每分钟STW中断5000次~18000次，每分钟中断总数据可能达到10秒~30秒。

Kona JDK :每分钟STW中断为一位数，每分钟中断的总时间在100~200ms之间。

试着整理一下分析整个问题的想法：

1 .通过堆栈分析，发现大量线程进行CPU计算，但CPU资源空闲。虽然对大量有关Merge Threads的现象存在一定的困惑，但它是问题的“果”，而不是“因”。

2.GC日志分析显示GC频率和GC时间均较低，但GC日志中存在大量STW相关日志，需要确认相关的Safepoint类型。

通过VM/Safepoint日志分析，验证了Safepoint的类型为ForceSafepoint。通过比较不同环境和不同集群的现象，人们开始怀疑JDK的版本存在问题。

更换Kona JDK后，ForceSafepoints频率为Luc，问题得到解决。

通过对这次问题的分析，得出了在问题分析初期应该认真调查集群环境的教训。当然最大的教训是ene Merge Thread！