警告: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [567] milliseconds
警告: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [567] milliseconds.
一、背景
今天部署项目到tomcat，执行./startup.sh命令之后，访问项目迟迟加载不出来，查看日志又没报错（其实是我粗心了，当时tomcat日志还没打印完），一开始怀疑是阿里云主机出现问题，访问ip:80发现nginx运行正常。在我百思不得其解时，项目访问正常了，查看启动日志，发现如下：
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分钟！
二、调查
网上搜索到的信息如下：
**********************************************************************************************
Tomcat 7/8/9 都使用 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 等待。键盘和鼠标输入以及磁盘活动可以产生所需的随机性或熵。但在一个服务器缺乏这样的活动，可能会出现问题。
**********************************************************************************************
说得很清楚，就是随机数生成问题。上述观点在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个
安装rng服务并启动，然后修改它的配置文件
yum install rng-tools -y
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（没尝试过）
四、小插曲
总算解决，但是这个问题之前没有的啊，为什么呢？
回想一下，这是我修改代码之后才出现的。所以我将一个继承自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规范，能力有限，以后再爬坑。
