Tomcat需要太多时间才能启动 – Java SecureRandom
请不要将其标记为重复。 对于这两个问题，这是一个后续问题。
- Tomcat7在Ubuntu 14.04 x64上启动太晚[Digitalocean]
- https://stackoverflow.com/a/2325109/6785908
我理解，替换
securerandom.source=file:/dev/urandom 同
securerandom.source=file:/dev/./urandom
在$JAVA_PATH/jre/lib/security/java.security中将解决这个问题。
我的问题是，在制作中这样做是否可以？ 这会对安全性产生什么影响（如会话ID变得可预测）？ 如果这不太安全，还有其他方法可以更快地提供足够的熵吗？
更新
我使用openstack进行部署（或者只是说，使用AWS或GCP或任何其他云提供商）。 因此，添加声卡等硬件设备对我来说不是一个选择。
经过一些广泛的谷歌搜索与正确的搜索术语，我在DigitalOcean上看到了这篇很好的文章。 我只是在这里引用相关部分。
Linux上有两个通用的随机设备：/ dev / random和/ dev / urandom。 最好的随机性来自/ dev / random，因为它是一个阻塞设备，并将等到有足够的熵可用于继续提供输出。 假设你的熵足够，你应该从/ dev / urandom看到相同的随机性质; 但是，由于它是一个非阻塞设备，它将继续产生“随机”数据，即使熵池耗尽也是如此。 这可能导致较低质量的随机数据，因为更可能重复先前的数据。 当生产服务器上的可用熵不足时，可能会发生很多不好的事情，特别是当此服务器执行加密function时。
因此，它存在潜在的安全风险。
填充熵池的解决方案
Linux已经从不同的硬件源获得了非常好的质量随机数据，但由于无头机器通常没有键盘或鼠标，因此产生的熵少得多。 磁盘和网络I / O代表这些机器的大多数熵生成源，并且这些生成非常稀疏的熵量。 由于很少有像服务器或云服务器/虚拟机这样的无头机器可以使用任何类型的专用硬件RNG解决方案，因此存在多种用户域解决方案，可以使用硬件中断来生成额外的熵，这些设备比硬盘（如video卡）更“嘈杂”。不幸的是，这再次被certificate是服务器的问题，因为它们通常不包含任何一个
解决方案：疯狂
基于HAVEGE原理，以及之前基于其关联的库，hasged允许基于处理器上的代码执行时间的变化来生成随机性。 由于一段代码几乎不可能花费相同的执行时间，即使在同一硬件上的相同环境中，运行单个或多个程序的时间也应该适合种子随机源。 在反复执行循环后，使用处理器的时间戳计数器（TSC）中的差异，伪造的实现会使系统的随机源（通常为/ dev / random）变为种子
如何安装hasged
请按照本文中的步骤操作。 https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged