java - 最小化多线程环境中的 SecureRandom 性能问题？

Question

(这是 SLES 上的 Java 8 和 Tomcat 8，FWIW。)

我需要多担心 SecureRandom 的性能问题？ (特别是 SHA1PRNG 提供程序的 SUN 算法)在我使用单个 SecureRandom 的初始播种之后多线程中的实例？ SecureRandom是线程安全的，所以这意味着某种程度的潜在争用？

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

我们正在考虑使用单个 SecureRandom例如，因为据我们所知，获得新的 SecureRandom 太贵了。我们的实例 encrypt()方法(使用 SecureRandom 生成 IV)，因为如果您使用新的 SecureRandom，播种开销会杀死您在你完成它之前很少几次。

我们正在考虑使用静态 ThreadLocal<SecureRandom>包含 encrypt() 的类的成员方法使单个 SecureRandom每个线程使用。我们会故意不调用ThreadLocal.remove()因为如果我们走这条路，我们实际上希望实例尽可能长时间地“存在”在 tomcat 线程中(以尽量减少创建新 SecureRandom 实例的次数)。

从这里阅读关于 ThreadLocal内存泄漏 我对这种方法有些担忧。然而，我们确实从不重新部署网络应用程序。它用于嵌入式系统，当 webapp 升级时(这是整个系统升级的一部分，一年只发生几次)Tomcat 完全关闭，新的 war 文件下降，Tomcat 重新启动。这似乎是使 webapp 相关的 ThreadLocal泄漏没有实际意义。

那么，是否有任何关于“有争议”的好数据SecureRandom是，并且是否就如何最正确地使用 SecureRandom 达成共识？在大量多线程的环境中？

Answer 1

查看SecureRandom的源代码, 它使用 synchronized方法，所以关于 synchronized 的任何讨论在大量多线程的环境中是适用的。

鉴于 Random 中的这条注释(如您所述) javadoc , 我会说你计划使用 ThreadLocal<SecureRandom>是否合适:

Instances of java.util.Random are threadsafe. However, the concurrent use of the same java.util.Random instance across threads may encounter contention and consequent poor performance. Consider instead using ThreadLocalRandom in multithreaded designs.

正如您自己总结的那样，您的实现不会出现内存泄漏问题。尤其如此，因为存储在 ThreadLocal 中的对象来自系统 ClassLoader，而不是您的 webapp 的 ClassLoader。