首先我嘗試分析和實踐了一下，排除了專案**的原因，所以最終定位到tomcat。
但是一直很奇怪，為什麼會卡頓？
因為想不通，所以就去查詢資料答案，在網上找到了一些和自己與遇到相同問題的人，看了一下
原因分析：
tomcat 7/8都使用org.apache.catalina.util.sessionidgeneratorbase.createsecurerandom類產生安全隨機類securerandom的例項作為會話id，這裡花去了342秒，也即接近6分鐘。
sha1prng演算法是基於sha-1演算法實現且保密性較強的偽隨機數生成器。
在sha1prng中，有乙個種子產生器，它根據配置執行各種操作。
1）如果j**a.security.egd屬性或securerandom.source屬性指定的是」file:/dev/random」或」file:/dev/urandom」，那麼jvm會使用本地種子產生器nativeseedgenerator，它會呼叫super()方法，即呼叫seedgenerator.urlseedgenerator(/dev/random)方法進行初始化。
2）如果j**a.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中加入這麼一行：-dj**a.security.egd=file:/dev/./urandom 即可。
加入後再啟動tomcat，整個啟動耗時下降到server startup in 2912 ms。
2）在jvm環境中解決（*實測，真實好使）
開啟$j**a_path/jre/lib/security/j**a.security這個檔案，找到下面的內容：
securerandom.source=file:/dev/random
替換成securerandom.source=file:/dev/urandom
CentOS7下Tomcat啟動慢的原因及解決方案
原因 是session引起的隨機數問題導致的 tocmat的session id是通過sha1演算法計算得到的，計算session id的時候必須有乙個金鑰。為了提高安全性tomcat在啟動的時候回通過隨機生成乙個金鑰。主要原因是生成隨機數的時候卡住了,導致tomcat啟動不了。解決辦法 安裝rng...
tomcat7關鍵配置和執行緒
官方文件 配置檔案conf server.xml redirectport 8443 沒有指定executor，則使用internal executor，使用的是jdk的執行緒池。本文討論internal executor。maxthreads 預設200，最大執行緒數，為執行緒池最大大小 thre...
Tomcat6和Tomcat7配置SSL通訊的比較
在專案開發過程中，嚐嚐會遇到tomcat需要ssl通訊的需求。尤其是在需要安全web應用時，需要https協議的通訊。由於tomcat預設情況下沒有提供ssl通訊設定，因此必須明白如何在tomcat下配置ssl。更糟糕的是，tomcat的不同版本，其ssl配置有所不同。所以，本文將講述如何在tomc...