Answers:
Java应用程序可以并且应该使用java.security.SecureRandom类通过使用加密强度高的伪随机数生成器（CSPRNG）来生成加密强度高的随机值。java.util.Random类的标准JDK实现在密码学上不强。
类似Unix的操作系统具有/dev/random特殊文件，该文件提供伪随机数，以访问从设备驱动程序和其他来源收集的环境噪声。但是，如果可用的熵少于请求的熵，它将阻塞。/dev/urandom即使自启动以来没有用熵完全初始化伪随机数生成器种子，通常也不会阻塞。还有一个第3个特殊文件，/dev/arandom该文件在启动后会阻塞，直到使用足够的熵安全地初始化了种子为止，然后再也不会阻塞。
默认情况下，JVM 使用来播种SecureRandom类/dev/random，因此 您的Java代码可能会意外阻止。-Djava.security.egd=file:/dev/./urandom用于启动Java进程的命令行调用中的选项告诉JVM /dev/urandom代替使用。
多余的东西/./似乎使JVM使用SHA1PRNG算法，该算法使用SHA-1作为PRNG（伪随机数生成器）的基础。它比/dev/urandom指定时使用的NativePRNG算法强。
最后，有一个神话/dev/urandom是伪随机数生成器PRNG，而又/dev/random是“真”随机数生成器。这是不正确的，这两个/dev/random和/dev/urandom由相同CSPRNG（密码安全伪随机数发生器）被馈送。根据一些估计，只有它们各自的池用尽了熵时的行为才不同：/dev/random块，而/dev/urandom没有。
熵低怎么办？没关系
事实证明，“看起来随机”是我们许多密码构造块的基本要求。而且，如果采用加密哈希的输出，则它必须与随机字符串不可区分，以便密码可以接受。这就是使用SHA1PRNG算法的原因，因为它使用哈希函数和计数器以及种子。
应该什么时候使用？
我总是说。
资料来源：
https
: //gist.github.com/svrc/5a8accc57219b9548fe1
https://www.2uo.de/myths-about-urandom
编辑04/2020：
评论提到Java 8中SecureRandom类的行为发生了变化。
SHA1PRNG和NativePRNG已修复，以正确遵守java.security文件中的SecureRandom种子源属性。（不再需要使用file：/// dev / urandom和file：/ dev /./ urandom的变通方法。）
上面“源”部分中引用的测试已经指出了这一点。额外/./需要改变所使用的算法SecureRanom在Java中8从NativePRNG到SHA1PRNG。
但是，我确实有一些要分享的新闻。根据JEP-273，从Java 9开始，SecureRandom类实现了NIST 800-90Ar1中描述的三种确定性随机位生成器（DRBG）机制。这些机制实现了强度高达SHA-512和AES-256的现代算法。
JDK有两种SecureRandom实现：
/dev/{u}random在Unix上阅读或在Windows上使用CryptoAPI。最新版本的Linux和Windows已经支持DRBG，但较早的版本和嵌入式系统可能不支持。同时，《Java 13安全开发人员指南》仍为
在Linux和macOS上，如果java.security中的熵收集设备设置为
file:/dev/urandom或file:/dev/random，则NativePRNG优于SHA1PRNG。否则，首选SHA1PRNG。
为了阐明新的DRBG机制如何与以前的PRNG一起使用，我使用AdoptOpenJDK（内部版本13.0.2 + 8）在macOS（达尔文）上运行了一些测试。结果如下：
文件：/ dev / random
提供者的优先顺序：
SecureRandom.NativePRNG
SecureRandom.DRBG
SecureRandom.SHA1PRNG
文件：/ dev / urandom
提供者的优先顺序：
SecureRandom.NativePRNG
SecureRandom.DRBG
SecureRandom.SHA1PRNG
文件：/ dev /./ urandom
提供者的优先顺序：
SecureRandom.DRBG
SecureRandom.SHA1PRNG
SecureRandom.NativePRNG
结论：
我建议使用-Djava.security.egd=file:/dev/./urandom，以确保无论使用什么平台，都可以利用最强大的SecureRandom实现，同时避免意外阻止代码。
/dev/urandom选择NativePRNG馈送通过/dev/urandom同时/dev/./urandom拾取SHA1PRNG起来（也通过进料/dev/urandom）使用Java 8.当从Java 9起，当DRBG优先/dev/./urandom指定源。
如果您使用的是JDK 8或更高版本，则不再需要
Java已解决此问题，这是一些链接
大纲
SHA1PRNG和NativePRNG已修复，以正确遵守java.security文件中的SecureRandom种子源属性。（不再需要使用file：/// dev / urandom和file：/ dev /./ urandom的变通方法。）
有关更多信息（在页面中搜索随机）：
https://docs.oracle.com/javase/8/docs/technotes/guides/security/enhancements-8.html
https://www.oracle.com/technetwork/java/javase/8-whats-new-2157071.html
这与linux /dev/random和/dev/urandom随机数生成器的区别有关。
取自此链接
Java Bug 6202721指出即使指定了/ dev / urandom，java.security.SecureRandom仍使用/ dev / random而不是/ dev / urandom，因为当时（大约在2004年）/ dev / urandom无法正常工作。由于/ dev / urandom可以很好地运行，因此该错误从未消失过。因此，您必须通过使用/dev/./urandom强制使用SHA1PRNG而不是/ dev / random来掩盖设置，从而伪造出来。
回答你的问题
应该什么时候使用？
基于上述链接，这是Java版本5所特有的，其后的原因是2004年Linux系统上的/ dev / urandom问题。