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_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"

在熵池不夠用的時候，默認的"file:/dev/random"會阻塞，"file:/dev/urandom"不會，繼續用。對于我們來說，"file:/dev/urandom"夠用，所以通過-Djava.security.egd=file:/dev/./urandom設置系統屬性，使用 urandom 來減少阻塞。

看完上述內容，你們掌握JFR 定位因為SSL導致CPU Load飚高的問題該怎么解決的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！