一、背景

今天部署專案到tomcat，執行./startup.sh命令之後，訪問專案遲遲載入不出來，檢視日誌又沒報錯（其實是我粗心了，當時tomcat日誌還沒列印完），一開始懷疑是阿里雲主機出現問題，訪問ip:80發現nginx執行正常。在我百思不得其解時，專案訪問正常了，檢視啟動日誌，發現如下：

15-Mar-2018 16:41:02.302 WARNING [main] org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [236,325] milliseconds.

可以看出例項化SecureRandom花了接近4分鐘！

二、調查

網上搜索到的資訊如下：

**********************************************************************************************

Tomcat 7/8/9 都使用 org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom 類產生安全隨機類 SecureRandom 的例項作為會話 ID。

Tomcat 使用 SHA1PRNG 演算法是基於 SHA-1 演算法實現且保密性較強的偽隨機數生成器。

在 SHA1PRNG 中，有一個種子產生器，它根據配置執行各種操作。

Linux 中的隨機數可以從兩個特殊的檔案中產生，一個是 /dev/urandom，另外一個是 /dev/random。他們產生隨機數的原理是利用當前系統的熵池來計算出固定一定數量的隨機位元，然後將這些位元作為位元組流返回。熵池就是當前系統的環境噪音，熵指的是一個系統的混亂程度，系統噪音可以通過很多引數來評估，如記憶體的使用，檔案的使用量，不同型別的程序數量等等。如果當前環境噪音變化的不是很劇烈或者當前環境噪音很小，比如剛開機的時候，而當前需要大量的隨機位元，這時產生的隨機數的隨機效果就不是很好了。

這就是為什麼會有 /dev/urandom 和 /dev/random 這兩種不同的檔案，後者在不能產生新的隨機數時會阻塞程式，而前者不會（ublock），當然產生的隨機數效果就不太好了，這對加密解密這樣的應用來說就不是一種很好的選擇。/dev/random 會阻塞當前的程式，直到根據熵池產生新的隨機位元組之後才返回，所以使用 /dev/random 比使用 /dev/urandom 產生大量隨機數的速度要慢。

SecureRandom generateSeed  使用 /dev/random 生成種子。但是 /dev/random 是一個阻塞數字生成器，如果它沒有足夠的隨機資料提供，它就一直等，這迫使 JVM 等待。鍵盤和滑鼠輸入以及磁碟活動可以產生所需的隨機性或熵。但在一個伺服器缺乏這樣的活動，可能會出現問題。

**********************************************************************************************

說得很清楚，就是隨機數生成問題。上述觀點在jdk中SecureRandom類的註釋得到了印證：

 * Note: Depending on the implementation, the {@code generateSeed} and
 * {@code nextBytes} methods may block as entropy is being gathered,
 * for example, if they need to read from /dev/random on various Unix-like
 * operating systems.

三、解決

方案有3個

方案1：通過rng-tools自動補充熵池（推薦）

yum install rng-tools      #安裝rngd熵服務

systemctl start rngd       #啟動服務

cp /usr/lib/systemd/system/rngd.service /etc/systemd/system

cd /etc/systemd/system/

vim rngd.service 
將 ExecStart=/sbin/rngd -f 改為 ExecStart=/sbin/rngd -f -r /dev/urandom

systemctl daemon-reload   #重新載入服務 

systemctl restart rngd    #重啟服務

重啟tomcat，檢視日誌，啟動時間1271 ms

15-Mar-2018 17:28:24.092 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 1271 ms

方案2：修改jvm引數

通過修改JRE中的java.security檔案securerandom.source=file:/dev/urandom


重啟tomcat，檢視日誌，啟動時間1271 ms

15-Mar-2018 17:22:27.363 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 84777 ms

可見啟動速度比原來快了一半多，但還是不理想

方案3：修改tomcat引數

通過修改Tomcat啟動檔案-Djava.security.egd=file:/dev/urandom（沒嘗試過）

四、小插曲

總算解決，但是這個問題之前沒有的啊，為什麼呢？

回想一下，這是我修改程式碼之後才出現的。所以我將一個繼承自HttpServlet的類中

private static final long serialVersionUID = 1L;

改為

private static final long serialVersionUID = -9135576688701595777L;

重啟tomcat，檢視日誌

15-Mar-2018 16:07:02.781 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 1267 ms

　tomcat恢復了往日的神速！可是serialVersionUID這個物件的序列化值為什麼會影響導致這個問題呢，在一篇《弄懂serialVersionUID》文獻中說到

使用預設序列號jvm會使用自身的演算法（演算法介紹），其中涉及到了SHA1，就我的理解用到了熵值演算法，熵池不夠所以例項化慢，實證的話要再去看jvm規範，能力有限，以後再爬坑。

以上