jdk下载快速方法 jdk下载慢怎么办( 四 )


从图中来看,似乎是ForceSafepoint逐步增多在先,后面的线程才逐步增多 。也就是说,STW中断变多在先,然后多个Merge任务线程才开始逐步积累,就好比,一条目录上突然增设了多个红绿灯,然后这条目录逐步变得拥堵 。
此时,开始请教Kona JDK团队的同学,我把GC日志以及thread dump日志分享给了他,并把我目前为止的发现都告诉了他,最大的怀疑点就是这些不正常的ForceSafepoints,我需要了解ForceSafepoints的原因 。
过了一段时间后,他回复我:这个是arm版本的jdk 。因缺乏arm编译机应急柜,暂时没法给我提供一个debug版本的arm jdk 。
突然明白,我犯了”先入为主”的错误,尽管一开始就意识到需要对环境进行调查 。
难怪在本地X86环境中始终无法复现 。难怪网上搜索ForceSafepoint时一无所获 。
接下来和客户电话会议沟通时,获知:

    类似的业务,在另外一套X86环境中,没有发现此类问题 。在这套arm环境中,还有另外一个Elasticsearch集群,请求量更低,但没有发现此类问题 。环境中使用的arm 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后,问题解决了 。
我统计了一下使用Ko

推荐阅读