代码评审——随机数Random问题

问题描述：

为了获取唯一值，经常会依赖产生随机数来保证唯一性。在获取随机数时，如果使用错误的方法，会比较低效。

可以参考以下代码：

public static String geneRundomNo(){Random r=new Random();int num=r.nextInt(100000);return "" + num;
}

此时，使用静态代码扫描工具，会出现以下提示：
Save and re-use this “Random”.
在这里插入图片描述

原因分析：

可以看下来自静态代码扫描工具的说明：

Creating a new Random object each time a random value is needed is inefficient and may produce numbers which are not random depending on the JDK. For better efficiency and randomness, create a single Random, then store, and reuse it.
The Random() constructor tries to set the seed with a distinct value every time. However there is no guarantee that the seed will be random or even uniformly distributed. Some JDK will use the current time as seed, which makes the generated numbers not random at all.
This rule finds cases where a new Random is created each time a method is invoked and assigned to a local random variable.

简单的说就是每次需要一个随机值时创建一个新的Random对象是低效的，并且可能会根据JDK的版本不同产生非随机的数字。

解决方案：

首先看下静态代码扫描工具给出的建议。

private Random rand = SecureRandom.getInstanceStrong();  // SecureRandom is preferred to Randompublic void doSomethingCommon() {int rValue = this.rand.nextInt();//...

如果按照这个建议执行，那么会产生2个问题：

1、按照上述方式引入，还需要解决构建函数的问题。

当引入java.security.SecureRandom后，需要解决构造函数问题。
可以通过以下方式解决：

private static Random rand;
static {try {rand = SecureRandom.getInstanceStrong();} catch (NoSuchAlgorithmException e) {e.printStackTrace();}
}

2、使用SecureRandom.getInstanceStrong()会导致线程阻塞问题，这个问题也是最严重的。

原因：不同的系统环境执行的底层代码不相同，在linux系统中是通过底层NativePRNG方法，通过/dev/random方式读取随机数，/dev/random方式受系统环境的影响容易造成线程阻塞，在windows系统中通过generateSeed的native方法读取，不会阻塞线程。具体的分析过程可以参考《SecureRandom.getInstanceStrong()引发的线程阻塞问题分析》。这篇文章写的非常详细了。

解决方案：使用new SecureRandom()替换SecureRandom.getInstanceStrong()。
请注意：这种解决方案是伪随机。

其他相关知识点：

以下内容摘自文章《SecureRandom 引发的线程阻塞》

SecureRandom本身并不是伪随机算法的实现，而是使用了其他类提供的算法来获取伪随机数。
如果简单的new一个SecureRandom对象的话，在不同的操作平台会获取到不同的算法，windows默认是SHA1PRNG,Linux的话是NativePRNG。
Linux下的NativePRNG，如果调用generateSeed()方法，这个方法会读取Linux系统的/dev/random文件，这个文件在JAVA_HOME/jre/lib/securiy/java.security里面有默认定义。而/dev/random文件是动态生成的，如果没有数据，就会阻塞。也就造成了第一个现象。
可以使用-Djava.security.egd=file:/dev/./urandom （这个文件名多个u）强制使用/dev/urandom这个文件，避免阻塞现象。中间加个点的解释是因为某个JDK BUG，SO那个帖子有链接。
如果使用SecureRandom.getInstanceStrong()这种方法初始化SecureRandom对象的话,会使用NativePRNGBlocking这个算法，而NativePRNGBlocking算法的特性如下：
NativePRNGBlocking uses /dev/random for all of the following operations:
Initial seeding: This initializes an internal SHA1PRNG instance using 20 bytes from /dev/random
Calls to nextBytes(), nextInt(), etc.: This provides the XOR of the output from the internal SHA1PRNG instance (see above) and data read from /dev/random
Calls to getSeed(): This provides data read from /dev/random
可见这个算法完全依赖/dev/random，所以当这个文件随机数不够的时候，自然会导致卡顿了。
如果使用NativePRNGBlocking算法的话，4中的系统参数失效！！！
一般使用SecureRandom不需要设置Seed，不需要设置算法，使用默认的，甚至一个静态的即可，如果有需求的话可以在运行一段时间后setSeed一下