java 慢:熵相关问题 [英] java slow : entropy related issue
问题描述
我遇到了一个问题，即通过 SSL 使用 java 时速度很慢.解决方法是在命令行中将
I am running into an issue where java is slow when used over SSL. The solution is to add
-Djava.security.egd=file:/dev/./urandom添加到 java 中.由于我有多个 JVM，我不想修改每个 JVM 以包含此字符串，因此希望将其添加到文件
to java at the command line. Since I have multiple JVM's, I dont want to modify every single JVM to contain this string and hence would like to add it to the file
$JAVA_HOME/jre/lib/security/java.security现在，java.security 文件已经包含
Now, the java.security file already contains
securerandom.source=file:/dev/urandom关于这个的两个问题:
- /dev/urandom"与/dev/./urandom"为何以及如何不同.为什么java不接受/dev/urandom"
- 对于我正在运行的 JVM，我如何判断它们是否使用了正确的 urandmon 设备(与随机设备)
推荐答案
这实际上是 1.3 或 1.4 天后引入 JVM 的一个 hack
This is actually a hack introduced into the JVM back in 1.3 or 1.4 days
http://bugs.sun.com/view_bug.do?bug_id=4705093
http:///bugs.sun.com/view_bug.do?bug_id=6202721
基本问题是，在原生 JVM 代码中，他们硬编码 /dev/urandom 以实际使用 /dev/random 来尝试确保足够的熵.由于 /dev/urandom 应该保证不会阻塞，如果没有足够的熵可用，这会产生意想不到的阻塞后果.
The basic issue is that in the native JVM code they hardcoded /dev/urandom to actually use /dev/random to attempt to ensure sufficient entropy. Since /dev/urandom is supposed to be guaranteed not to block, this has the unintended consequence of blocking if not enough entropy is available.
硬编码专门查找字符串 /dev/urandom，因此提供解析为相同内容但不匹配导致所需行为的内容.如果您编写 /dev/./urandom 代码，您将绕过硬编码别名并获得预期的 urandom 熵源.
The hardcoding looks specifically for the string /dev/urandom, so providing something that resolves to the same thing but doesn't match that causes the desired behavior. If you code /dev/./urandom you bypass the hardcoded aliasing and get to the intended urandom entropy source.
这篇关于java 慢:熵相关问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
