Centos环境下Tomcat启动缓慢

最近项目上线部署的时候,发现一个问题。Tomcat在启动过程当中耗费了很长的时间。查看日志,发现耗时最长的地方是:java

INFO [localhost-startStop-1] org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID generlinux

ation using [SHA1PRNG] took [1,693,533] milliseconds.算法

在网上查找资料后肯定,该问题是因为tomcat的session id的生成主要经过java.security.SecureRandom生成随机数来实现,随机数算法使用的是”SHA1PRNG”。在sun/oracle的jdk里,这个算法的提供者在底层依赖到操做系统提供的随机数据,在linux上,与之相关的是/dev/random和/dev/urandom。有关它俩的描述以下:apache

/dev/randomtomcat

在读取时,/dev/random设备会返回小于熵池噪声总数的随机字节。/dev/random可生成高随机性的公钥或一次性session

密码本。若熵池空了,对/dev/random的读操做将会被阻塞,直到收集到了足够的环境噪声为止。oracle

/dev/urandomdom

dev/random的一个副本是/dev/urandom (”unlocked”,非阻塞的随机数发生器),它会重复使用熵池中的数据ide

以产生伪随机数据。这表示对/dev/urandom的读取操做不会产生阻塞,但其输出的熵可能小于/dev/random的。它操作系统

能够做为生成较低强度密码的伪随机数生成器,不建议用于生成高强度长期密码。

在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,是有意为之。


个人最终解决方法以下:

找到 $JAVA_HOME/jre/lib/security/java.security 这个文件,找到里面的

securerandom.source=file:/dev/random

或者

securerandom.source=file:/dev/urandom

修改成

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

原文详情:http://www.roncoo.com/article/detail/125962

相关文章
相关标签/搜索