修改 linux系統(tǒng)中 /usr/local/jdk1.8.0_11/jre/lib/security/java.security

?

借力

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

?

?原因：

JVM上的隨機(jī)數(shù)與熵池策略

7條回復(fù)

在apache-tomcat官方文檔：如何讓tomcat啟動(dòng)更快?里面提到了一些啟動(dòng)時(shí)的優(yōu)化項(xiàng)，其中一項(xiàng)是關(guān)于隨機(jī)數(shù)生成時(shí)，采用的“熵源”(entropy source)的策略。

他提到tomcat7的session id的生成主要通過(guò)java.security.SecureRandom生成隨機(jī)數(shù)來(lái)實(shí)現(xiàn)，隨機(jī)數(shù)算法使用的是”SHA1PRNG”

private String secureRandomAlgorithm = "SHA1PRNG";

在sun/oracle的jdk里，這個(gè)算法的提供者在底層依賴到操作系統(tǒng)提供的隨機(jī)數(shù)據(jù)，在linux上，與之相關(guān)的是/dev/random和/dev/urandom，對(duì)于這兩個(gè)設(shè)備塊的描述以前也見過(guò)討論隨機(jī)數(shù)的文章，wiki中有比較詳細(xì)的描述，摘抄過(guò)來(lái)，先看/dev/random?：

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

而?/dev/urandom?則是一個(gè)非阻塞的發(fā)生器:

dev/random的一個(gè)副本是/dev/urandom （”unlocked”，非阻塞的隨機(jī)數(shù)發(fā)生器），它會(huì)重復(fù)使用熵池中的數(shù)據(jù)以產(chǎn)生偽隨機(jī)數(shù)據(jù)。這表示對(duì)/dev/urandom的讀取操作不會(huì)產(chǎn)生阻塞，但其輸出的熵可能小于/dev/random的。它可以作為生成較低強(qiáng)度密碼的偽隨機(jī)數(shù)生成器，不建議用于生成高強(qiáng)度長(zhǎng)期密碼。

另外wiki里也提到了為什么linux內(nèi)核里的隨機(jī)數(shù)生成器采用SHA1散列算法而非加密算法，是為了避開法律風(fēng)險(xiǎn)(密碼出口限制)。

回到tomcat文檔里的建議，采用非阻塞的熵源(entropy source)，通過(guò)java系統(tǒng)屬性來(lái)設(shè)置：

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

這個(gè)系統(tǒng)屬性egd表示熵收集守護(hù)進(jìn)程(entropy gathering daemon)，但這里值為何要在dev和random之間加一個(gè)點(diǎn)呢？是因?yàn)橐粋€(gè)jdk的bug，在這個(gè)bug的連接里有人反饋及時(shí)對(duì) securerandom.source 設(shè)置為?/dev/urandom?它也仍然使用的?/dev/random，有人提供了變通的解決方法，其中一個(gè)變通的做法是對(duì)securerandom.source設(shè)置為?/dev/./urandom?才行。也有人評(píng)論說(shuō)這個(gè)不是bug，是有意為之。

我看了一下我當(dāng)前所用的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里，這個(gè)?/dev/urandom?也同那個(gè)bug報(bào)告里所說(shuō)的等同于?/dev/random；要使用非阻塞的熵池，這里還是要修改為/dev/./urandom?呢，還是jdk7已經(jīng)修復(fù)了這個(gè)問(wèn)題，就是同注釋里的意思，只好驗(yàn)證一下。

使用bug報(bào)告里給出的代碼：

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

然后設(shè)置不同的系統(tǒng)屬性來(lái)驗(yàn)證，先是在我的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?的執(zhí)行時(shí)間差不多，有點(diǎn)納悶，再仔細(xì)看一下wiki里說(shuō)的：

FreeBSD操作系統(tǒng)實(shí)現(xiàn)了256位的Yarrow算法變體，以提供偽隨機(jī)數(shù)流。與Linux的/dev/random不同，FreeBSD的/dev/random不會(huì)產(chǎn)生阻塞，與Linux的/dev/urandom相似，提供了密碼學(xué)安全的偽隨機(jī)數(shù)發(fā)生器，而不是基于熵池。而FreeBSD的/dev/urandom則只是簡(jiǎn)單的鏈接到了/dev/random。

盡管在我的mac上/dev/urandom并不是/dev/random的鏈接，但mac與bsd內(nèi)核應(yīng)該是相近的，/dev/random也是非阻塞的，/dev/urandom是用來(lái)兼容linux系統(tǒng)的，這兩個(gè)隨機(jī)數(shù)生成器的行為是一致的。參考這里。

然后再到一臺(tái)ubuntu系統(tǒng)上測(cè)試：

% 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

這回差異就完全體現(xiàn)出來(lái)了，阻塞模式的熵池耗時(shí)用了1.6秒，而非阻塞模式則只用了0.14秒，差了一個(gè)數(shù)量級(jí)，當(dāng)然代價(jià)是轉(zhuǎn)換為對(duì)cpu的開銷了。

// 補(bǔ)充，連續(xù)在ubuntu上測(cè)試幾次/dev/random方式之后，導(dǎo)致熵池被用空，被阻塞了60秒左右。應(yīng)用服務(wù)器端要避免這種方式。

轉(zhuǎn)載于:https://www.cnblogs.com/mike-mei/p/8329938.html

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。