系统是基于springboot开发的系统，java -jar启动过程中发现经常会卡住6分钟左右，才能启动完成，全程没有发现任何WANR和ERROR级别的日志（其实早看看DEBUG和INFO日志，可能问题早就解决了，惯性思维害人啊），再去查看/var/log/message系统日志，也没发现任何和该进程相关的系统日志；
无奈，初步怀疑服务器虚拟机有问题，让运维排查下，也没发现任何异常；
将同样的jar包程序放到其它虚拟机上跑，也有卡顿，但是10秒，20秒的样子就结束了，虽然快了，但是也有卡顿，同样的排查还是没发现问题；
最后反复启停，反复查看，也是巧合在日志里有了发现，
[18-12-19 21:01:13:222][INFO ][org.apache.catalina.util.SessionIdGeneratorBase][localhost-startStop-1]Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [99,677] milliseconds.
发现了意外，这里耗时简直了
最后的解决方案就是在JVM启动参数里加上如下一串：
-Djava.security.egd=file:/dev/./urandom在tomcat的wiki上也有解释 https://wiki.apache.org/tomcat/HowTo/FasterStartUp#Entropy_Source
Tomcat 7+ heavily relies on SecureRandom class to provide random values for its session ids and in other places. Depending on your JRE it can cause delays during startup if entropy source that is used to initialize SecureRandom is short of entropy. You will see warning in the logs when this happens.
There is a way to configure JRE to use a non-blocking entropy source by setting the following system property: -Djava.security.egd=file:/dev/./urandom
在读取时，/dev/random设备会返回小于熵池噪声总数的随机字节。
/dev/random可生成高随机性的公钥或一次性密码本。
若熵池空了，对/dev/random的读操作将会被阻塞，直到收集到了足够的环境噪声为止
而/dev/urandom则是一个非阻塞的发生器:
dev/random的一个副本是/dev/urandom （”unlocked”，非阻塞的随机数发生器），它会重复使用熵池中的数据以产生伪随机数据。
这表示对/dev/urandom的读取操作不会产生阻塞，但其输出的熵可能小于/dev/random的。
它可以作为生成较低强度密码的伪随机数生成器，不建议用于生成高强度长期密码。
https://bugs.openjdk.java.net/browse/JDK-6202721
另外wiki里也提到了为什么linux内核里的随机数生成器采用SHA1散列算法而非加密算法，是为了避开法律风险(密码出口限制)。
还有一篇文章专门解释/dev/urandom
https://www.2uo.de/myths-about-urandom/
最后总结下：
其实还是虚拟机的CPU差了点，跟其它环境的虚拟机10秒，20秒的差了几十倍，可见CPU差了很多啊。