问题描述
（这是使用Java 8和Tomcat 8在SLES，FWIW上。）
我需要担心的是关于性能问题与 SecureRandom （特别是 SUN 提供者的 SHA1PRNG 算法 SecureRandom 实例时，初始播种？ SecureRandom 是线程安全的，这意味着一定程度的潜在争用？
我在Java中看不到任何东西对于 SecureRandom 讨论这个问题的Javadoc，虽然我看到 Random 的Javadocs特别提到了争用和性能下降的警告在线程中使用单个随机实例。
我们正在考虑使用单个 SecureRandom 实例，因为我们看到，在我们的 encrypt（） SecureRandom 实例是太贵了c $ c>方法（它使用 SecureRandom 用于IV代），因为如果您使用新的 SecureRandom
我们考虑使用静态 ThreadLocal< SecureRandom> 包含 encrypt（）方法的类的成员，以便单个每个线程使用SecureRandom 。我们将有意不调用 ThreadLocal.remove（），因为如果我们去了这条路线，我们实际上会希望这个实例在tomcat线程中活尽可能长（为了最小化新的 SecureRandom 实例的次数）。
从这里阅读内存泄漏我对此有一些担忧。但是，我们从不重新部署webapp。它在嵌入式系统中使用，当webapp升级时（这是整个系统升级的一部分，每年只会发生几次），Tomcat完全关闭，新的war文件下降，Tomcat重新启动。这似乎是使webapp相关的 ThreadLocal 泄漏。
那么有没有什么好的数据在那里关于有争议的 SecureRandom 是，并且有一个共识，如何最大程度地使用 SecureRandom -multithreaded环境？
查看 SecureRandom 的源代码，它使用同步的方法，所以在大量多线程环境中有关 synchronized 的任何讨论都将适用。 / p>
在 Random ，我想说你计划使用 ThreadLocal< SecureRandom> 是适当的：
您的实现不会有内存泄漏问题。这是特别真实的，因为存储在 ThreadLocal 中的对象来自系统ClassLoader，而不是您的webapp的ClassLoader。
(This is with Java 8 and Tomcat 8 on SLES, FWIW.)
How worried do I need to be about performance problems with SecureRandom (specifically the SHA1PRNG algorithm of the SUN provider) after the initial seeding when I am using a single SecureRandom instance in multiple threads? SecureRandom is thread-safe so that implies some level of potential contention?
I don't see anything in Java 8 Javadocs that discusses this for SecureRandom though I see that the Javadocs for Random do specifically warn about contention and performance degradation when using a single Random instance across threads.
We are considering using a single SecureRandom instance because from what we see it is way too expensive to get a new SecureRandom instance within our encrypt() method (which uses SecureRandom for IV generation) because of the seeding overhead kills you if you use a new SecureRandom very few times before you are done with it.
We are alternatively considering having a static ThreadLocal<SecureRandom> member of the class containing the encrypt() method so that a single SecureRandom is used per thread. We would intentionally not call ThreadLocal.remove() because if we went this route we would actually like the instance to "live" in the tomcat threads as long as possible (to minimize the number of times new SecureRandom instances are created).
From reading here about ThreadLocal memory leaks I have some concerns about that approach. However, we literally never redeploy the webapp. It is used in an embedded system and when the webapp is upgraded (which is part of an overall system upgrade and only happens a few times a year) Tomcat is completely shut down, the new war file dropped down, and Tomcat restarted. That would seem to be to make the webapp-related ThreadLocal leaks moot.
So, is there any good data out there on how "contentious" SecureRandom is, and is there consensus on how to most properly use SecureRandom in a heavily-multithreaded environment?
Looking at the source code of SecureRandom, it uses a synchronized method, so any discussion out there about synchronized in a heavily-multithreaded environment would be applicable.
Given this note (as you mentioned) in the Random javadoc, I'd say that your plan to use ThreadLocal<SecureRandom> is appropriate:
As you concluded yourself, you won't have memory leak issues with your implementation. This is especially true because the objects stored in the ThreadLocal are from the system ClassLoader, not your webapp's ClassLoader.
这篇关于最小化多线程环境中的SecureRandom性能问题？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！