idea启动tomcat卡着不动

2020-05-17 / tomcat idea

13-May-2020 13:05:31.134 信息 [Catalina-utility-1] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [G:\docker\tomcat\tomcat8080\apache-tomcat-9.0.31\webapps\manager] has finished in [2,332] ms

卡在这里不动。

解决办法

如果不存在jre目录，执行下面命令

bin\jlink.exe --module-path jmods --add-modules java.desktop --output jre

修改 java.security文件

jdk8.0 在 jre/lib/security 目录下

不同版本的jdk，位置不同，都在jre目录下

securerandom.source=file:/dev/./random

方法二

urandom

熵池太小熵池的大小是根据键盘鼠标之类的噪音产生的数然后/dev/random会根据熵池来生成随机数而生成需要有足够的熵池里的噪音数如果没有达到的话就会一直阻塞 tomcat启动的时候为了生成session id就会获取这个随机数来生成密匙所以才出现上面的情况一直阻塞在等待熵池里的数满足生成随机数的大小 3分钟以后熵池里的数够大了才开始部署所以我们可以使用rngd来增大熵池因为docker容器的熵池都是共享的宿主机的所以只要增大宿主机的熵池就可以了在容器内是没办法通过rngd修改熵池的因为没有权限修改宿主机的东西只能通过上面链接里提到的修改jre或者tomcat的方法
————————————————
版权声明：本文为CSDN博主「wwdwjm」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/wwdwjm/java/article/details/77840113

文章来源：

在apache-tomcat官方文档：如何让tomcat启动更快里面提到了一些启动时的优化项，其中一项是关于随机数生成时，采用的“熵源”(entropy source)的策略。

他提到tomcat7的session id的生成主要通过 java.security.SecureRandom生成随机数来实现，随机数算法使用的是”SHA1PRNG”

private String secureRandomAlgorithm = "SHA1PRNG";
 String secureRandomAlgorithm = "SHA1PRNG";
String secureRandomAlgorithm = "SHA1PRNG";
 secureRandomAlgorithm = "SHA1PRNG";
"SHA1PRNG";
;

在sun/oracle的jdk里，这个算法的提供者在底层依赖到操作系统提供的随机数据，在linux上，与之相关的是 /dev/random和 /dev/urandom，对于这两个设备块的描述以前也见过讨论随机数的文章，wiki中有比较详细的描述，摘抄过来，先看 /dev/random ：

在读取时，/dev/random设备会返回小于熵池噪声总数的随机字节。/dev/random可生成高随机性的公钥或一次性密码本。若熵池空了，对/dev/random的读操作将会被阻塞，直到收集到了足够的环境噪声为止

而 /dev/urandom 则是一个非阻塞的发生器:

dev/random的一个副本是/dev/urandom （”unlocked”，非阻塞的随机数发生器），它会重复使用熵池中的数据以产生伪随机数据。这表示对/dev/urandom的读取操作不会产生阻塞，但其输出的熵可能小于/dev/random的。它可以作为生成较低强度密码的伪随机数生成器，不建议用于生成高强度长期密码。

另外wiki里也提到了为什么linux内核里的随机数生成器采用SHA1散列算法而非加密算法，是为了避开法律风险(密码出口限制)。

回到tomcat文档里的建议，采用非阻塞的熵源(entropy source)，通过java系统属性来设置：

-Djava.security.egd=file:/dev/./urandom
/dev/./urandom
./urandom

这个系统属性egd表示熵收集守护进程(entropy gathering daemon)，但这里值为何要在 dev和 random之间加一个点呢？是因为一个jdk的bug，在这个bug的连接里有人反馈及时对 securerandom.source 设置为 /dev/urandom 它也仍然使用的 /dev/random，有人提供了变通的解决方法，其中一个变通的做法是对securerandom.source设置为 /dev/./urandom 才行。也有人评论说这个不是bug，是有意为之。

我看了一下我当前所用的jdk7的java.security文件里，配置里仍使用的是 /dev/urandom：