JFR 定位因为 SSL 导致 CPU Load 飚高的问题

问题场景

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

同时建立了很多数据库链接：

其他实例没有这个现象。

问题定位

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

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

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

其中这个微服务这段时间的热点 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

// name of the *System* property, takes precedence over PROP_RNDSOURCE
private static final String PROP_EGD = "java.security.egd";
// name of the *Security* property
private 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"

两种 Random 原理与解决

在 Linux 4.8 之前：

在 Linux 4.8 之后：

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