Java 在多线程环境中最小化安全随机性能问题？

（这是针对SLES、FWIW上的Java 8和Tomcat 8的。）

当我在多个线程中使用单个

SecureRandom

实例时，在初始种子设定之后，我需要多担心

SecureRandom

（特别是

SUN

提供程序的

SHA1PRNG

算法）的性能问题

SecureRandom

是线程安全的，因此这意味着某种程度的潜在争用

我在Java8Javadocs中没有看到任何关于

SecureRandom

的讨论，尽管我看到

Random

的Javadocs在跨线程使用单个

Random

实例时明确警告争用和性能降低

我们正在考虑使用一个

SecureRandom

实例，因为从我们的角度来看，在

encrypt（）

方法中获得一个新的

SecureRandom

实例的成本太高（该方法使用

SecureRandom

生成IV）由于播种开销，如果在使用新的

SecureRandom

之前很少使用它，就会导致您死亡

或者，我们正在考虑使用包含

encrypt（）

方法的类的静态

ThreadLocal

成员，以便每个线程使用单个

SecureRandom

。我们有意不调用

ThreadLocal.remove（）

，因为如果我们这样做，我们实际上希望实例尽可能长时间地“驻留”在tomcat线程中（以减少创建新

SecureRandom

实例的次数）

通过阅读这里有关

ThreadLocal

内存泄漏的内容，我对这种方法有些担心。然而，我们从字面上看从不重新部署webapp。它用于嵌入式系统，当webapp升级时（这是整个系统升级的一部分，一年只发生几次），Tomcat完全关闭，新的war文件被删除，Tomcat重新启动。这似乎使与webapp相关的

ThreadLocal

leaks变得毫无意义

---

那么，有没有关于“有争议的”

SecureRandom

的好数据，有没有关于如何在高度多线程的环境中最恰当地使用

SecureRandom

的共识？

查看

SecureRandom

的源代码，它使用了一种

同步的方法，因此，任何关于在高度多线程环境中进行
同步
的讨论都是适用的

鉴于
Random
中的这一注释（如您所述），我认为您使用
ThreadLocal
的计划是合适的：

java.util.Random
的实例是线程安全的。但是，跨线程并发使用相同的
java.util.Random
实例可能会遇到争用，从而导致性能低下。在多线程设计中考虑使用<代码> TraceLoopRead < /COD>。
正如您自己总结的那样，您的实现不会有内存泄漏问题。这一点尤其正确，因为存储在
ThreadLocal
中的对象来自系统类加载器，而不是您的webapp的类加载器。
您确定播种开销会让您丧命吗？我希望它在使用/dev/uradom进行种子设定的Linux环境中会非常快。另外，在加密方法中加密的典型消息有多大？可能一个单一的SecureRandom实例并没有太多的争用。