【发布时间】：2017-03-13 10:06:48
【问题描述】：
通过论坛阅读，似乎SecureRandom 是线程安全的，但由于争用，它在多线程系统中遇到了困难，请参阅Is SecureRandom thread safe?
。初始化一个新的SecureRandom也是一项昂贵的操作。提高性能的一个建议是使用ThreadLocalRandom。
所以我改变了我的代码：
SecureRandom randomSecureRandom = SecureRandom.getInstance("SHA1PRNG");
到：
private final ThreadLocalRandom randomThreadLocal = ThreadLocalRandom.current();
我做了一些测试 - 100 次加密 10000 个字符串值，我可以看到明显的改进。
**With ThreadLocalRandom**
Thread #18New encryption service took on average: 66.44ms.
Thread #17New encryption service took on average: 64.79ms.
Thread #14New encryption service took on average: 70.77ms.
Thread #13New encryption service took on average: 72.33ms.
Thread #19New encryption service took on average: 73.42ms.
Thread #15New encryption service took on average: 74.21ms.
Thread #11New encryption service took on average: 76.79ms.
Thread #16New encryption service took on average: 78.72ms.
Thread #12New encryption service took on average: 78.95ms.
Thread #20New encryption service took on average: 78.99ms.
**With SecureRandom**
Thread #19New encryption service took on average: 87.26ms.
Thread #18New encryption service took on average: 93.65ms.
Thread #13New encryption service took on average: 93.1ms.
Thread #15New encryption service took on average: 95.81ms.
Thread #16New encryption service took on average: 96.9ms.
Thread #11New encryption service took on average: 97.0ms.
Thread #20New encryption service took on average: 94.93ms.
Thread #17New encryption service took on average: 96.63ms.
Thread #12New encryption service took on average: 97.41ms.
Thread #14New encryption service took on average: 99.08ms.
看来我确实提高了这里的速度，但是我降低了安全性，因为 ThreadLocalRandom 似乎不是加密安全的：
* <p>Instances of {@code ThreadLocalRandom} are not cryptographically
* secure. Consider instead using {@link java.security.SecureRandom}
* in security-sensitive applications
我的问题是 - 有没有办法创建加密安全的随机数，它是线程安全的并且在多线程系统中表现良好？
还有一个问题涉及这个主题，但答案是从SecureRandom 到ThreadLocalRandom 的相同转换，这不是加密安全的，请参阅Minimizing SecureRandom performance problems in multithreaded environment?。
【问题讨论】：
-
随机需要多少个线程？我知道您说过创建
SecureRandom的成本很高，但您可能仍想衡量最终是否为每个线程创建一个会带来更快的结果，因为没有争用。 -
还有其他产生随机值的方法，即通过使用硬件、听麦克风的噪声背景或使用外部磁力计，也可以从互联网上下载随机数据，但是这些方法非常在多线程环境中不太可能更快更有效。我建议坚持使用
SecureRandom，并确保在多个线程中重用相同的实例实例，然后调用.nextBytes(..)函数。最后，如果您想要加密的强值，您必须为性能付出代价。 -
因此，您每次通话节省了大约 30 毫秒。这几乎没有什么大的变化，这对整体性能有影响吗？你想要安全的随机数还是只是随机数？
-
@john16384 我将使用这个随机数进行加密，所以我想根据我的需要，最好是安全的随机数。
-
好吧，我想首先要测试的是两个线程是否真的比一个线程更快地生成数字。如果他们这样做了，那么为什么不让两个或更多线程都忙着让队列缓冲区充满随机数呢？我看不到任何其他更快的解决方案。当排队的数据变少时，让生成器进程添加更多线程甚至应该不是那么难。
标签： java multithreading security cryptography