js 随机1-10随机数
本文将介绍我的工作。 我将概述我的旅程，以便真正找到正在发生的事情的根本原因。 我在本文中的目标是突出显示可以使用的技术示例，以实际跟踪奇怪的和随机的错误。
最后，我找到了一个非常清楚的解释，说明问题发生的原因和原因。 本文标题中存在“随机性”并非巧合。
开始–问题出在哪里
问题是，在遵循使用开发虚拟机的指南时，有时启动应用程序会花费很长时间，然后失败。 在两次启动应用程序后，我马上遇到了问题。 其他人也有同样的问题。
有人告诉我，没有人真正知道它为什么会以这种方式运行-但是重新启动VM可能会修复它。 它不适合我。
但是我喜欢深入研究问题-所以我想知道出了什么问题。
将档案耙到Solr
运行rake app:run 有时会发生错误。 通过使用--trace --verbose （调试选项）运行rake，我可以看到，该应用程序正在等待黑子启动Apache Solr搜索服务。
所以问题是，该过程始终花在哪里？ 开始的好处是，rake和sunspot用Ruby编写。 因此，我阅读了代码并添加了一些输出语句，以查看哪个语句花费了很长时间。 原来，这是Java进程启动了Solr。
挖掘Java
Apache Solr将一些输出发送到sdtout-但黑子将其隐藏在您的面前。 但是由于调试时任何输出都非常有用，因此我想查看输出。
我使用ps -aux查找了ps -aux发出的确切命令行参数，并从命令行手动启动了该过程。 幸运的是，它仍然花费了一些时间-所以我知道问题不在Ruby代码中。
通过端口映射器nmap，我发现启动该服务需要2秒钟到2分钟以上的时间。 但是耙任务只等待了10秒。
现在有了控制台输出，我可以看到，Solr在内部使用Jetty- 在版本6.1.3中是Jetty ，这花了很多时间- 在这种情况下，它花了时间。 因此，我从源代码管理下载了6.1.3版的标签，并查看了代码。
我发现了一个名为DEBUG的系统属性，它会增加输出。 我启用了它，并看到最后的调试输出（花了很长时间）与启动会话服务有关（不幸的是，我失去了指向代码的指针）。
这并没有真正帮助我。 我没有尝试使Jetty日志与log4j一起使用以最终看到更多内容，但是我失败了，不得不放弃当晚（第二个）。
调试Java代码
因此，如果您没有从日志中得到任何东西，您仍然可以使用调试器。 但是，代码在VM（Ubuntu盒）上失败了，但在我的本地计算机上却失败了。 但是幸运的是Java有一个远程调试器 。
我使用远程调试参数启动Java进程，并使用SVN中的Jetty代码在IntelliJ中附加了一个侦听器。 我试图使执行在最后一个日志输出附近的断点处停止，但是这种方法经常被调用，而我没有在正确的时机到达断点。
但是，当事情花费很长时间时，仅停止正在运行的进程并查看堆栈跟踪会很有用。 因此，我停止了执行并搜索了调用JDK的Jetty的最后一个方法框架-在这里，我发现了以下注释：
//This operation may block on some systems with low entropy. See this page
//for workaround suggestions:
//http://docs.codehaus.org/display/JETTY/Connectors+slow+to+startup
Log.debug('Init SecureRandom.');
_random=new SecureRandom();
解决方案
最后–我确实转到了引用的Jetty Wiki页面 。 我发现，Java的java.util.SecureRandom使用了来自操作系统的真实熵-当没有可用的熵时，它将阻塞。
仅使用普通的java.util.Random的方法，来自Wiki页的解决方案将很困难，因为配置文件位于sunspot和Solr内部。 但是行“ NB一些解决方法报告使用/dev/./urandom而不是/ dev / urandom”给了我一个提示，那就是另找。
我用Google搜索解决方案并在Stack Overflow上发现，可以在Java进程/dev/./urandom /dev/urandom随机替换为/dev/./urandom 。 这可以通过使用命令行参数-Djava.security.egd=file:/dev/./urandom或通过将其替换为文件/usr/lib/jvm/java-6-openjdk/jre/lib/security/java.security （在Ubuntu机器上）。
那怎么了？ Java的安全随机数将不接受/dev/urandom作为随机数的源 。 /dev/urandom是无阻塞的，这意味着它将在没有可用的实际熵的情况下返回可以猜测的随机数。 因此，Java默认为/dev/random ，它将阻塞并等待，直到出现熵为止。
这就是为什么在生产或开发机器上极不可能发生阻塞的原因-但是在使用虚拟机时，它确实发生了，因为虚拟机的网络流量和IO并不多。 当您经常重启应用程序时（尤其是在某些情况下无法正常工作时），这种情况尤其常见。
解决方法有点有趣。 Java根据字符串拒绝/dev/urandom 。 它不会拒绝/dev/./urandom ，它当然指向同一个可能不安全的随机数生成器。
最后的话
该修复程序会带来潜在的安全风险–但是在开发虚拟机上，这不是问题。
如您所见，在系统中查找错误或问题涉及使用技术，这些技术使您更接近根本原因。 但是，没有黄金路。 有时，一种技术将无法为您提供更多信息。 因此，您将不得不尝试另一种技术。 有时候，您的直觉也会对您有所帮助。
到达这里后，您对这个故事有何看法？
参考：在Johannes Thones博客博客上，我们的JCG合作伙伴 Johannes Thones 狩猎随机的错误-一个真实的故事 。
翻译自: https://www.javacodegeeks.com/2012/10/hunting-random-bug-true-story.html
js 随机1-10随机数
