【解决】Linux Tomcat启动慢--Creation of SecureRandom instance for session ID generation using [SHA1PRNG] to

1、背景html

今天部署项目到tomcat,执行./startup.sh命令以后,访问项目迟迟加载不出来,查看日志又没报错(实际上是我粗心了,当时tomcat日志还没打印完),一开始怀疑是阿里云主机出现问题,访问ip:80发现nginx运行正常。在我百思不得其解时,项目访问正常了,查看启动日志,发现以下:java

15-Mar-2018 16:41:02.302 WARNING [main] org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [236,325] milliseconds.

能够看出实例化SecureRandom花了接近4分钟!nginx

2、调查算法

网上搜索到的信息以下:apache

**********************************************************************************************vim

Tomcat 7/8/9 都使用 org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom 类产生安全随机类 SecureRandom 的实例做为会话 ID。tomcat

Tomcat 使用 SHA1PRNG 算法是基于 SHA-1 算法实现且保密性较强的伪随机数生成器。安全

在 SHA1PRNG 中,有一个种子产生器,它根据配置执行各类操做。服务器

Linux 中的随机数能够从两个特殊的文件中产生,一个是 /dev/urandom,另一个是 /dev/random。他们产生随机数的原理是利用当前系统的熵池来计算出固定必定数量的随机比特,而后将这些比特做为字节流返回。熵池就是当前系统的环境噪音,熵指的是一个系统的混乱程度,系统噪音能够经过不少参数来评估,如内存的使用,文件的使用量,不一样类型的进程数量等等。若是当前环境噪音变化的不是很剧烈或者当前环境噪音很小,好比刚开机的时候,而当前须要大量的随机比特,这时产生的随机数的随机效果就不是很好了。session

这就是为何会有 /dev/urandom 和 /dev/random 这两种不一样的文件,后者在不能产生新的随机数时会阻塞程序,而前者不会(ublock),固然产生的随机数效果就不太好了,这对加密解密这样的应用来讲就不是一种很好的选择。/dev/random 会阻塞当前的程序,直到根据熵池产生新的随机字节以后才返回,因此使用 /dev/random 比使用 /dev/urandom 产生大量随机数的速度要慢。

SecureRandom generateSeed  使用 /dev/random 生成种子。可是 /dev/random 是一个阻塞数字生成器,若是它没有足够的随机数据提供,它就一直等,这迫使 JVM 等待。键盘和鼠标输入以及磁盘活动能够产生所需的随机性或熵。但在一个服务器缺少这样的活动,可能会出现问题。

**********************************************************************************************

说得很清楚,就是随机数生成问题。上述观点在jdk中SecureRandom类的注释获得了印证:

 * Note: Depending on the implementation, the {@code generateSeed} and
 * {@code nextBytes} methods may block as entropy is being gathered,
 * for example, if they need to read from /dev/random on various Unix-like
 * operating systems.

3、解决

方案有3个

方案1:经过rng-tools自动补充熵池(推荐)

yum install rng-tools      #安装rngd熵服务

systemctl start rngd       #启动服务
cp /usr/lib/systemd/system/rngd.service /etc/systemd/system cd /etc/systemd/system/

vim rngd.service
将 ExecStart=/sbin/rngd -f 改成 ExecStart=/sbin/rngd -f -r /dev/urandom
systemctl daemon-reload   #从新载入服务 

systemctl restart rngd #重启服务

重启tomcat,查看日志,启动时间1271 ms

15-Mar-2018 17:28:24.092 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 1271 ms

方案2:修改jvm参数

经过修改JRE中的java.security文件securerandom.source=file:/dev/urandom

重启tomcat,查看日志,启动时间1271 ms

15-Mar-2018 17:22:27.363 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 84777 ms

可见启动速度比原来快了一半多,但仍是不理想

方案3:修改tomcat参数

经过修改Tomcat启动文件-Djava.security.egd=file:/dev/urandom(没尝试过)

4、小插曲

总算解决,可是这个问题以前没有的啊,为何呢?

回想一下,这是我修改代码以后才出现的。因此我将一个继承自HttpServlet的类中

private static final long serialVersionUID = 1L;

改成

private static final long serialVersionUID = -9135576688701595777L;

重启tomcat,查看日志

15-Mar-2018 16:07:02.781 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 1267 ms

 tomcat恢复了往日的神速!但是serialVersionUID这个对象的序列化值为何会影响致使这个问题呢,在一篇《弄懂serialVersionUID》文献中说到

使用默认序列号jvm会使用自身的算法(算法介绍),其中涉及到了SHA1,就个人理解用到了熵值算法,熵池不够因此实例化慢,实证的话要再去看jvm规范,能力有限,之后再爬坑。

以上!

相关文章
相关标签/搜索