最大限度地减少多线程环境中的 SecureRandom 性能问题？

Question

（这是 SLES 上的 Java 8 和 Tomcat 8，FWIW。）

当我在多个线程中使用单个实例时，在初始播种后我需要多么担心性能问题SecureRandom（特别是提供者SHA1PRNG的算法SUN） ？是线程安全的，因此这意味着一定程度的潜在争用？SecureRandomSecureRandom

我在 Java 8 Javadocs 中没有看到任何讨论这一点的内容，SecureRandom尽管我看到 Javadocs确实特别警告了跨线程Random使用单个实例时的争用和性能下降。Random

我们正在考虑使用单个实例，因为从我们看来，在我们的方法（用于IV 生成）中SecureRandom获取新实例的成本太高，因为如果您在使用新实例之前使用几次，那么播种开销就会杀死您。完成了。SecureRandomencrypt()SecureRandomSecureRandom

或者，我们正在考虑让ThreadLocal<SecureRandom>包含该encrypt()方法的类有一个静态成员，以便每个SecureRandom线程使用一个静态成员。我们故意不调用，因为如果我们走这条路线，我们实际上希望实例尽可能长时间地“存活”在 tomcat 线程中（以最小化创建ThreadLocal.remove()新实例的次数）。SecureRandom

从这里阅读有关ThreadLocal内存泄漏的内容后，我对这种方法有些担忧。然而，我们实际上从不重新部署 web 应用程序。它用在嵌入式系统中，当 webapp 升级时（这是整个系统升级的一部分，一年只发生几次）Tomcat 完全关闭，新的 war 文件被删除，Tomcat 重新启动。这似乎会让与 Web 应用程序相关的ThreadLocal泄漏变得毫无意义。

那么，是否有任何关于“有争议”程度的良好数据SecureRandom，以及对于如何SecureRandom在重度多线程环境中最正确地使用达成共识？

Answer 1

查看 的源代码SecureRandom，它使用了一种synchronized方法，因此任何有关synchronized重度多线程环境中的讨论都是适用的。

Random 鉴于javadoc中的这条注释（正如您所提到的），我想说您的使用计划ThreadLocal<SecureRandom>是合适的：

的实例java.util.Random是线程安全的。java.util.Random但是，跨线程并发使用同一实例可能会遇到争用，从而导致性能不佳。考虑ThreadLocalRandom在多线程设计中使用。

正如您自己得出的结论，您的实现不会出现内存泄漏问题。尤其如此，因为存储在 中的对象ThreadLocal来自系统 ClassLoader，而不是您的 web 应用程序的 ClassLoader。