共計 1072 個字符，預計需要花費 3 分鐘才能閱讀完成。

springboot 應用基于 k8s 部署 pod 啟動緩慢排查的示例分析，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面丸趣 TV 小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

在 k8s 集群中部署 springboot 應用，應用啟動較慢，如圖：

如果基于 kubelet log -f pod 查看日志時，日志打印同樣較慢

調試改動后：

Linux 系統上的設備 /dev/random 和 /dev/urandom 是不同的。

/dev/random 設備提供的不是偽隨機數據，而是基于環境中的真實隨機因素（即背景噪聲作為熵源）的隨機數據。

所以，/dev/random 不像設備 /dev/urandom。后者是一個偽隨機數據生成器，能按照請求快速生成所需數量的數據。/dev/random 能生成多少內容由環境中的噪聲決定。數據不足時，/dev/random 只能等待。

所以，在內容不足時，/dev/random 會將讀操作阻塞，直至收集到足夠的隨機數據。這就是測試結果差異產生的原因，/dev/random 阻塞第二次的讀操作將近 1 分鐘時間。

所以，對于使用了 /dev/random 設備的而言，都有被阻塞的可能。被阻塞時，上層應用可能表現為啟動慢或者執行耗時不正常。因為 /dev/random 行為與環境背景有關，行為隨機。所以也導致上層應用因之引發的問題表現隨機，不易排查。

比如，在 Java 社區，/dev/random 設備引致的問題早在 jdk-1.4 版本時就已經有 bug 報告。但是還是有客戶不知道類似問題的致因和解決方案。

解決方案簡單說，就是除非有明確的理由，必須要使用 /dev/random 設備。否則，使用 /dev/urandom 設備即可。

對于 jdk 而言，需要的是把配置文件中 $JAVA_HOME/jre/lib/security/java.security 中的 securerandom.source=file:/dev/random 改為 securerandom.source=file:/dev/urandom

排查建議

對于 Java 程序啟動慢，或者進程耗時不正常，請優先排查是不是 /dev/random 的問題。步驟如下

確認是不是使用的是設備 /dev/random。這只要檢查 $JAVA_HOME/jre/lib/security/java.security 對應的配置就好。

如果是，則變更配置。

重啟 Java 程序確認是否問題解決。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注丸趣 TV 行業資訊頻道，感謝您對丸趣 TV 的支持。