最近使用阿里云 centos7 运行 Tomcat7 时，发现tomcat里面的项目已经提示success，但是还是不能访问，要过上大概快两分钟的时间才能访问，最初还以为是项目的问题，最后查看了下日志，才发现最后的两分钟时间主要是花在了实例化 SecureRandom 对象的操作上面了。
日志里面的信息大概是这样：
|
|
由日志上的这条信息可以看出，实例化该对象花去了253秒，导致原本只需要20秒左右就能启动完成的项目实际上花去了275秒左右的时间。
发生这种情况的根本原因是 SecureRandom 这个 jre 的工具类的问题。那为什么 SecureRandom generateSeed 这么慢呢，这是因为tomcat7、tomcat8都是用org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom 类产生安全随机类 SecureRandom 的实例作为会话 ID。
Tomcat 使用 SHA1PRNG 算法是基于 SHA-1 算法实现且保密性较强的伪随机数生成器。而在 SHA1PRNG 算法中，有一个种子产生器是根据配置来执行各种操作的。
linux中的随机数可以从两个特殊的文件中产生，一个是 /dev/urandom，另外一个是 /dev/random。 他们产生的随机数的原理是利用当前系统的熵池来计算出固定一定数量的随机比特，然后再将这些比特作为字节流返回。这里的熵池就是当前系统的环境噪音，熵指的是一个系统的混乱程度，系统跟噪音可以通过很多参数来评估，如内存的使用，文件的使用量，不同类型的进程的数量等等。如果当前的系统的环境噪音变化程度并不是很剧烈、反差不大，或者当前环境的噪音很小，比如刚开机的时候。而刚开机的时候需要大量的随机比特，这个时候产生随机数的随机效果就不是很理想了。
接下来解释一下 /dev/urandom 和 /dev/random 这两种不同的文件的区别， /dev/random 在不能产生新的随机数的情况下会阻塞程序，程序挂起便没法继续执行，直到熵池产生新的随机字节后才能返回，程序再接着执行，这就是 /dev/random 比 /dev/urandom 产生大量随机数的速度要慢的原因，也是为什么使用这个文件生成随机数时，tomcat启动的速度被拖慢的原因。而 /dev/urandom 这种方式在不能产生新的随机数时不会阻塞程序，当然了，这样的话生成随机数的效果没有 /dev/random 这种方式好，这对于加解密这样的应用来说并不是一个很好的选择。
SecureRandom generateSeed 使用 /dev/random 生成种子。但是 /dev/random 是一个阻塞数字生成器，如果它没有足够的随机数据提供，它就一直等，这迫使 JVM 等待（程序挂起/tomcat启动拖慢）。键盘和鼠标输入以及磁盘活动可以产生所需的随机性或熵。但在一个服务器缺乏这样的活动，可能会出现问题。
这种情况可以有两种方式来解决：
1. 在tomcat 环境中解决：
可以通过配置 JRE 使用非阻塞的方式，在 catalina.sh 中加入这么一行：-Djava.security.egd=file:/dev/./urandom 即可。
2. 在JVM 环境中解决：
打开 $JAVA_PATH/jre/lib/security/java.security 这个文件（在你安装jdk的目录下），找到下面的内容：
|
|
将其替换为：
|
|
这里值为何要在 dev 和 random 之间加一个点呢？是因为一个 JDK 的 bug，有人反馈即使对 securerandom.source 设置为 /dev/urandom 它也仍然使用的 /dev/random，有人提供了变通的解决方法，其中一个变通的做法是对 securerandom.source 设置为 /dev/./urandom 才行。也有人评论说这个不是 bug，是有意为之。
我自己是用第二种方式解决的，快三百秒的启动时间缩短为20秒左右，很有效。大家如果有相同情况需要解决的话，记得加那个点。
最后，文章也是我结合网友的方案和自己实际情况的解决过程的一个总结，如果有写得不好、不正确的地方望大家见谅，感谢网友的无私分享，谢谢~