JFR 定位因为SSL导致CPU Load飚高的问题该怎么解决

JFR 定位因为SSL导致CPU Load飚高的问题该怎么解决，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。

问题场景

在某一时刻，某个微服务的某个实例 CPU 负载突然飚高

问题定位

由于建立了很多数据库链接，猜想可能是数据库比较慢，查看数据库这段时间的 SQL 统计，发现数据库并不慢。

其中这个微服务这段时间的热点 SQL，执行并不慢。那么问题出在了哪里呢？可能是由于 GC，可能是由于 safepoint，还有可能是获取锁时间过长（参考：Java 监控 JFR全解），我们 dump 一下 JFR 并查看其中的 safepoint，GC 以及 Monitor Blocked 相关事件。

首先查看GC，发现都是 Young GC, GC 暂停时间也可以接受。

然后是 safepoint，虽然有采集到 safepoint，但是暂停时间也没有很长。

最后查看 Java Monitor Block，发现有很多很长时间的锁等待。

堆栈显示，阻塞在：void sun.security.provider.SecureRandom.engineNextBytes(byte[])上面，这就是一个经典的问题，Java Random，参考代码：NativePRNG

// name of the *System* property, takes precedence over PROP_RNDSOURCEprivate static final String PROP_EGD = "java.security.egd";// name of the *Security* propertyprivate static final String PROP_RNDSOURCE = "securerandom.source";private static final boolean useLegacyDSA =    Boolean.parseBoolean(GetPropertyAction.privilegedGetProperty        ("jdk.security.legacyDSAKeyPairGenerator"));static final String URL_DEV_RANDOM = "file:/dev/random";static final String URL_DEV_URANDOM = "file:/dev/urandom";

涉及到两种随机数 seed 生成方式，一种是"file:/dev/random"，另一种是"file:/dev/urandom"，通过设置系统属性java.security.egd指定，默认是"file:/dev/random"

在熵池不够用的时候，默认的"file:/dev/random"会阻塞，"file:/dev/urandom"不会，继续用。对于我们来说，"file:/dev/urandom"够用，所以通过-Djava.security.egd=file:/dev/./urandom设置系统属性，使用 urandom 来减少阻塞。

看完上述内容，你们掌握JFR 定位因为SSL导致CPU Load飚高的问题该怎么解决的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注行业资讯频道，感谢各位的阅读！