進入平臺組後，接觸linux服務器的場景大大增多了，以前沒有做過運維的活，現在能體會到運維的不易了，環境的不同，項目的版本不同都會涉及到不同的問題。
最近給項目增加監聽的時候，發現項目一直卡在某處啓動不起來，輸出的日誌信息如下：
Apr 09, 2019 4:27:12 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["ajp-bio-8009"]
Apr 09, 2019 4:27:12 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 766 ms
Apr 09, 2019 4:27:12 PM org.apache.catalina.core.StandardService startInternal
INFO: Starting service Catalina
Apr 09, 2019 4:27:12 PM org.apache.catalina.core.StandardEngine startInternal
INFO: Starting Servlet Engine: Apache Tomcat/7.0.91
Apr 09, 2019 4:27:12 PM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory /root/transform/tomcat-transform/webapps/ROOT
原因以爲是tomcat服務器破損了， 並換了新的tomcat容器環境，發現還是沒有效果，可能原因不在這，出現在jdk的設置上面。
解決方案是：在 JVM 環境中解決
打開 $JAVA_PATH/jre/lib/security/java.security 這個文件，找到下面的內容
securerandom.source=file:/dev/random
替換成
securerandom.source=file:/dev/./urandom
說一下這個random和urandom的區別：
tomcat啓動的時候會實例化SecureRandom對象，實例化對象使用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 等待。鍵盤和鼠標輸入以及磁盤活動可以產生所需的隨機性或熵。但在一個服務器缺乏這樣的活動，可能會出現問題。
目前tomcat7和tomcat8都是使用的這種方式來實例化SecureRandom對象的。