引言
最近弄了个服务器再部署了个javaweb项目，但是再启动时候 发现Tomcat启动非常非常的慢，导致再部署完成以后 觉得项目像 没有起来一样， 这就很郁闷了，因为每次不熟需要等10多分钟，这是不能 忍受的，在查看通Tomcat启动日志的时候发现：
org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [253,251] milliseconds.
，通过查看日志，发现时间主要花在实例化 SecureRandom 对象上了。
原理解释
根本原因是 SecureRandom 这个 jre 的工具类的问题。那为什么 SecureRandom generateSeed 这么慢，甚至挂在 Linux 操作系统呢？
Tomcat 7/8 都使用 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 等待。键盘和鼠标输入以及磁盘活动可以产生所需的随机性或熵。但在一个服务器缺乏这样的活动，可能会出现问题。
解决方案1：
问题的原因是由于熵池不够大，所以增大它是最彻底的方法。我们可以通过软件的方法实现，下面是软件的安装和配置流程。
1.安装熵服务
yum install rng-tools
2.启动熵服务
systemctl start rngd
3.如果你的 CPU 不支持 DRNG 特性或者像我一样使用虚拟机，可以使用/dev/unrandom来模拟。
cp /usr/lib/systemd/system/rngd.service /etc/systemd/system vim /etc/systemd/system/rngd.service
#以下是编辑内容
ExecStart=/sbin/rngd -f -r /dev/urandom
4.重新载入服务
systemctl daemon-reload systemctl restart rngd
解决方案2：
1. 在Tomcat环境中解决：
可以通过配置 JRE 使用非阻塞的 Entropy Source：
在 catalina.sh 中加入这么一行：-Djava.security.egd=file:/dev/./urandom 即可。
2. 在 JVM 环境中解决：
打开 $JAVA_PATH/jre/lib/security/java.security 这个文件117行的位置，找到下面的内容：
securerandom.source=file:/dev/random
替换成：
securerandom.source=file:/dev/./urandom
这里值为何要在 dev 和 random 之间加一个点呢？是因为一个 JDK 的 bug，有人反馈即使对 securerandom.source 设置为 /dev/urandom 它也仍然使用的 /dev/random，有人提供了变通的解决方法，其中一个变通的做法是对 securerandom.source 设置为 /dev/./urandom 才行。也有人评论说这个不是 bug，是有意为之。这种方法亲测可用！
在 JDK 7 的 java.security 文件里，配置里的是：
# 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
但这个 /dev/urandom 也同那个 bug 报告里所说的等同于 /dev/random；要使用非阻塞的熵池，这里还是要修改为 /dev/./urandom。经测试，貌似 JDK 7 并没有同注释里的意思修复了这个问题。
