修改 linux系統中 /usr/local/jdk1.8.0_11/jre/lib/security/java.security

?

借力

好文章。
我們新的Linux系統，部署了多個 Tomca，同時重啟后t, 每次都阻塞差不多260秒左右。
修改之后總的啟動時間下降到6-8秒左右。
另外，不確定為什么，
修改 java.security 文件中的 securerandom.source=file:/dev/urandom 不生效。
修改啟動腳本中的 -Djava.security.egd=file:/dev/./urandom 就生效了。

?

?原因：

JVM上的隨機數與熵池策略

7條回復

在apache-tomcat官方文檔：如何讓tomcat啟動更快?里面提到了一些啟動時的優化項，其中一項是關于隨機數生成時，采用的“熵源”(entropy source)的策略。

他提到tomcat7的session id的生成主要通過java.security.SecureRandom生成隨機數來實現，隨機數算法使用的是”SHA1PRNG”

private String secureRandomAlgorithm = "SHA1PRNG";

在sun/oracle的jdk里，這個算法的提供者在底層依賴到操作系統提供的隨機數據，在linux上，與之相關的是/dev/random和/dev/urandom，對于這兩個設備塊的描述以前也見過討論隨機數的文章，wiki中有比較詳細的描述，摘抄過來，先看/dev/random?：

在讀取時，/dev/random設備會返回小于熵池噪聲總數的隨機字節。/dev/random可生成高隨機性的公鑰或一次性密碼本。若熵池空了，對/dev/random的讀操作將會被阻塞，直到收集到了足夠的環境噪聲為止

而?/dev/urandom?則是一個非阻塞的發生器:

dev/random的一個副本是/dev/urandom （”unlocked”，非阻塞的隨機數發生器），它會重復使用熵池中的數據以產生偽隨機數據。這表示對/dev/urandom的讀取操作不會產生阻塞，但其輸出的熵可能小于/dev/random的。它可以作為生成較低強度密碼的偽隨機數生成器，不建議用于生成高強度長期密碼。

另外wiki里也提到了為什么linux內核里的隨機數生成器采用SHA1散列算法而非加密算法，是為了避開法律風險(密碼出口限制)。

回到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，是有意為之。

我看了一下我當前所用的jdk7的java.security文件里，配置里仍使用的是/dev/urandom：

#
# Select the source of seed data for SecureRandom. By default an
# attempt is made to use the entropy gathering device specified by
# the securerandom.source property. If an exception occurs when
# accessing the URL then the traditional system/thread activity
# algorithm is used.
#
# On Solaris and Linux systems, if file:/dev/urandom is specified and it
# exists, a special SecureRandom implementation is activated by default.
# This "NativePRNG" reads random bytes directly from /dev/urandom.
#
# On Windows systems, the URLs file:/dev/random and file:/dev/urandom
# enables use of the Microsoft CryptoAPI seed functionality.
#
securerandom.source=file:/dev/urandom

我不確定jdk7里，這個?/dev/urandom?也同那個bug報告里所說的等同于?/dev/random；要使用非阻塞的熵池，這里還是要修改為/dev/./urandom?呢，還是jdk7已經修復了這個問題，就是同注釋里的意思，只好驗證一下。

使用bug報告里給出的代碼：

import java.security.SecureRandom;
class JRand {public static void main(String args[]) throws Exception {System.out.println("Ok: " +SecureRandom.getInstance("SHA1PRNG").nextLong());}
}

然后設置不同的系統屬性來驗證，先是在我的mac上：

% time java -Djava.security.egd=file:/dev/urandom  JRand
Ok: 8609191756834777000
java -Djava.security.egd=file:/dev/urandom JRand  
0.11s user 0.03s system 115% cpu 0.117 total% time java -Djava.security.egd=file:/dev/./urandom  JRand
Ok: -3573266464480299009
java -Djava.security.egd=file:/dev/./urandom JRand  
0.11s user 0.03s system 116% cpu 0.116 total

可以看到/dev/urandom和?/dev/./urandom?的執行時間差不多，有點納悶，再仔細看一下wiki里說的：

FreeBSD操作系統實現了256位的Yarrow算法變體，以提供偽隨機數流。與Linux的/dev/random不同，FreeBSD的/dev/random不會產生阻塞，與Linux的/dev/urandom相似，提供了密碼學安全的偽隨機數發生器，而不是基于熵池。而FreeBSD的/dev/urandom則只是簡單的鏈接到了/dev/random。

盡管在我的mac上/dev/urandom并不是/dev/random的鏈接，但mac與bsd內核應該是相近的，/dev/random也是非阻塞的，/dev/urandom是用來兼容linux系統的，這兩個隨機數生成器的行為是一致的。參考這里。

然后再到一臺ubuntu系統上測試：

% time java -Djava.security.egd=file:/dev/urandom  JRand
Ok: 6677107889555365492
java -Djava.security.egd=file:/dev/urandom JRand  
0.14s user 0.02s system 9% cpu 1.661 total% time java -Djava.security.egd=file:/dev/./urandom  JRand
Ok: 5008413661952823775
java -Djava.security.egd=file:/dev/./urandom JRand  
0.12s user 0.02s system 99% cpu 0.145 total

這回差異就完全體現出來了，阻塞模式的熵池耗時用了1.6秒，而非阻塞模式則只用了0.14秒，差了一個數量級，當然代價是轉換為對cpu的開銷了。

// 補充，連續在ubuntu上測試幾次/dev/random方式之后，導致熵池被用空，被阻塞了60秒左右。應用服務器端要避免這種方式。

轉載于:https://www.cnblogs.com/mike-mei/p/8329938.html

總結

以上是生活随笔為你收集整理的tomcat启动后 项目运行缓慢，要几十到几百秒不等 怎么样./startup.sh 运行加快的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。