在日誌中發現啟動慢的地方：

2016-11-14 09:31:30.522 [localhost-startStop-1] INFO  o.s.c.s.DefaultLifecycleProcessor - Starting beans in phase 2147483647
2016-11-14 09:31:30.556 [localhost-startStop-1] INFO  o.s.web.context.ContextLoader - Root WebApplicationContext: initialization completed in 12902 ms
2016-11-14 09:32:33.146 [localhost-startStop-1] INFO  o.a.c.util.SessionIdGeneratorBase - Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [62,587] milliseconds.
2016-11-14 09:32:33.214 [localhost-startStop-1] INFO  o.s.web.servlet.DispatcherServlet - FrameworkServlet ‘DispatcherServlet‘: initialization started

原因：

Tomcat 7/8都使用org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom類產生安全隨機類SecureRandom的實例作為會話ID，這裏花去了62秒，也即接近1分鐘，當然有時花費時間更長，達到5-10分鐘。

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

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

1）如果Java.security.egd 屬性或securerandom.source屬性指定的是”file:/dev/random”或”file:/dev/urandom”，那麽JVM 會使用本地種子產生器NativeSeedGenerator，它會調用super()方法，即調用 SeedGenerator.URLSeedGenerator(/dev/random)方法進行初始化。

2）如果java.security.egd屬性或securerandom.source屬性指定的是其它已存在的URL，那麽會調用SeedGenerator.URLSeedGenerator(url)方法進行初始化。

這就是為什麽我們設置值為”file:///dev/urandom”或者值為”file:/./dev/random”都會起作用的原因。

在這個實現中，產生器會評估熵池（entropy pool）中的噪聲數量。隨機數是從熵池中進行創建的。當讀操作時，/dev/random設備會只返回熵池中噪聲的隨機字節。/dev/random非 常適合那些需要非常高質量隨機性的場景，比如一次性的支付或生成密鑰的場景。

當熵池為空時，來自/dev/random的讀操作將被阻塞，直到熵池收集到足夠的環境噪聲數據。這麽做的目的是成為一個密碼安全的偽隨機數發生器，熵池要有盡可能大的輸出。對於生成高質量的加密密鑰或者是需要長期保護的場景，一定要這麽做。

那麽什麽是環境噪聲？

隨機數產生器會手機來自設備驅動器和其它源的環境噪聲數據，並放入熵池中。產生器會評估熵池中的噪聲數據的數量。當熵池為空時，這個噪聲數據的收集是比較花時間的。這就意味著，Tomcat在生產環境中使用熵池時，會被阻塞較長的時間。

解決：

有兩種解決辦法：

1）在Tomcat環境中解決

可以通過配置JRE使用非阻塞的Entropy Source。

在catalina.sh中加入這麽一行：

JAVA_OPTS="-Djava.security.egd=file:/dev/./urandom"

即可。

加入後再啟動Tomcat，整個啟動耗時迅速下降。

2）在JVM環境中解決

打開$JAVA_PATH/jre/lib/security/java.security這個文件，找到下面的內容：

securerandom.source=file:/dev/urandom

替換成

securerandom.source=file:/dev/./urandom

Tomcat 7/8 啟動非常慢的解決方法