Centos環境下Tomcat啟動緩慢

標籤：設定   source   產生   偽隨機   unlock   資料   and   host   隨機   

最近項目上線部署的時候，發現一個問題。Tomcat在啟動過程中耗費了很長的時間。查看日誌，發現耗時最長的地方是：
INFO [localhost-startStop-1] org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID gener
ation using [SHA1PRNG] took [1,693,533] milliseconds.
在網上尋找資料後確定，該問題是由於tomcat的session id的產生主要通過java.security.SecureRandom產生隨機數來實現，隨機數演算法使用的是”SHA1PRNG”。在sun/oracle的jdk裡，這個演算法的提供者在底層依賴到作業系統提供的隨機資料，在linux上，與之相關的是/dev/random和/dev/urandom。有關它倆的描述如下：
/dev/random
在讀取時，/dev/random裝置會返回小於熵池雜訊總數的隨機位元組。/dev/random可產生高隨機性的公開金鑰或一次性
密碼本。若熵池空了，對/dev/random的讀操作將會被阻塞，直到收集到了足夠的環境雜訊為止。
/dev/urandom
dev/random的一個副本是/dev/urandom （”unlocked”，非阻塞的隨機數發生器），它會重複使用熵池中的資料
以產生偽隨機資料。這表示對/dev/urandom的讀取操作不會產生阻塞，但其輸出的熵可能小於/dev/random的。它
可以作為產生較低強度密碼的偽隨機數產生器，不建議用於產生高強度長期密碼。
在tomcat的文檔裡的建議，採用非阻塞的熵源(entropy source)，通過java系統屬性來設定：
-Djava.security.egd=file:/dev/./urandom
這個系統屬性egd表示熵收集守護進程(entropy gathering daemon)，但這裡值為何要在dev和random之間加一個點呢？是因為一個jdk的bug，在這個bug的串連裡有人反饋及時對 securerandom.source 設定為 /dev/urandom 它也仍然使用的 /dev/random，有人提供了變通的解決方案，其中一個變通的做法是對securerandom.source設定為 /dev/./urandom 才行。也有人評論說這個不是bug，是有意為之。

我的最終解決方案如下：
找到 $JAVA_HOME/jre/lib/security/java.security 這個檔案，找到裡面的
securerandom.source=file:/dev/random
或者
securerandom.source=file:/dev/urandom
修改為
securerandom.source=file:/dev/./urandom

原文詳情地址：http://www.roncoo.com/article/detail/125962

Centos環境下Tomcat啟動緩慢