你知道jdk竟有4个random吗

你知道jdk竟有4个random吗

我们从jdk8说起。主要是四个随机数生成器。神马？有四个？

接下来我们简单说下这几个类的使用场景，来了解其中的细微差别，和api设计者的良苦用心。

java.util.Randomjava.util.concurrent.ThreadLocalRandomjava.security.SecureRandomjava.util.SplittableRandom

Random

最常用的就是Random。

用来生成伪随机数，默认使用48位种子、线性同余公式进行修改。我们可以通过构造器传入初始seed，或者通过setSeed重置（同步）。默认seed为系统时间的纳秒数，真大！

如果两个（多个）不同的Random实例，使用相同的seed，按照相同的顺序调用相同方法，那么它们得到的数字序列也是相同的。这看起来不太随机。  这种设计策略，既有优点也有缺点，优点是“相同seed”生成的序列是一致的，使过程具有可回溯和校验性（平台无关、运行时机无关）；缺点就是，这种一致性，潜在引入其“可被预测”的风险。

Random的实例是线程安全的。  但是，跨线程并发使用相同的java.util.Random实例可能会遇到争用，从而导致性能稍欠佳（nextX方法中，在对seed赋值时使用了CAS，测试结果显示，其实性能损耗很小）。请考虑在多线程设计中使用ThreadLocalRandom。同时，我们在并发环境下，也没有必要刻意使用多个Random实例。

Random实例不具有加密安全性。  相反，请考虑使用SecureRandom来获取加密安全的伪随机数生成器，以供安全敏感应用程序使用。

Random是最常用的随机数生成类，适用于绝大部分场景。

Random random = new Random(100);System.out.println(random.nextInt(10) + "," + random.nextInt(30) + "," + random.nextInt(50));random = new Random(100);System.out.println(random.nextInt(10) + "," + random.nextInt(30) + "," + random.nextInt(50));random = new Random(100);System.out.println(random.nextInt(10) + "," + random.nextInt(30) + "," + random.nextInt(50));

上述三个不同的random实例，使用了相同的seed。调用过程一样，其中产生的随机数序列http://也是完全一样的。多次执行结果也完全一致，简单而言，只要初始seed一样，即使实例不同，多次运行它们的结果都是一致的。这个现象与上面所说的一致。

如果Random构造器中不指定seed，而是使用默认的系统时间纳秒数作为主导变量，三个random实例执行的结果是不同的。多次执行结果也不一样。由此可见，seed是否具有随机性，在一定程度上，也决定了Random产生结果的随机性。

所以，在分布式或者多线程环境下，如果Random实例处于代码一致的tasks线程中，可能这些分布式进程或者线程，产出的序列值是一样的。这也是在JDK 7引入ForkJoin的同时，也引入了ThreadLocalRandom类。

ThreadLocalRandom

这个类的作用，使得随机数的生成器隔离到当前线程。此类继承自java.util.Random，与Math类使用的全局Random生成器一样，ThreadLocalRandom使用内部生成的种子进行初始化，否则可能无法修改。

在并发程序中使用ThreadLocalRandom，通常会有更少的开销和竞争。当多个任务（例如，每个ForkJoinTask）在线程池中并行使用随机数时，ThreadLocalRandom是特别合适的。

切记，在多个线程中不应该共享ThreadLocalRandom实例。

ThreadLocalRandom初始化是private的，所以无法通过构造器设定seed，此外其setSeed方法也被重写而不支持（抛出异常）。默认情况下，每个ThreadLocalRandom实例的seed主导变量值为系统时间（纳秒）：

private static long initialSeed() { String sec = VM.getSavedProperty("java.util.secureRandomSeed"); if (Boolean.parseBoolean(sec)) { byte[] seedBytes = java.security.SecureRandom.getSeed(8); long s = (long)(seedBytes[0]) & 0xffL; for (int i = 1; i < 8; ++i) s = (s << 8) | ((long)(seedBytes[i]) & 0xffL); return s; } return (mix64(System.currentTimeMillis()) ^ mix64(System.nanoTime()));}

根据其初始化seed的实现，我们也可以通过JVM启动参数增加“-Djava.util.secureRandomSeed=true”，此时初始seed变量将不再是系统时间，而是由SecureRandom类生成一个随机因子，以此作为ThreadLoalRandom的初始seed。

真是够绕的。

从源码中，我并没有看到Thread-ID作为变量生成seed，而且nextX方法中随机数生成算法也具有一致性。这意味着，如果多个线程初始ThreadLocalRandom的时间完全一致，在调用方法和过程相同的情况下，产生的随机序列也是相同的；在一定程度上“-Djava.util.secureRandom=true”可以规避此问题。

ThreadLocalRandom并没有使用ThreadLocal来支持内部数据存储等，而是直接使用UnSafe操作当前Thread对象引用中seed属性的内存地址并进行数据操作，我比较佩服SUN的这种巧妙的做法。

SecureRandom

它也继承自Random，该类提供加密强随机数生成器（RNG），加密强随机数最低限度符合FIPS 140-2“加密模块的安全要求”。此外，SecureRandom必须产生非确定性输出。因此，传递给SecureRandom对象的任何种子材料必须是不可预测的，并且所有SecureRandom输出序列必须具有加密强度。（官文，其实我也一知半解）

SecureRandom默认支持两种RNG加密算法实现：

”SHA1PRNG”算法提供者sun.security.provider.SecureRandom

”NativePRNG”提供者sun.security.provider.NativePRNG

默认情况下，是“SHA1PRNG”，即SUN提供的实现。此外可以通过

“-Djava.security=file:/dev/urandom”

（推荐）或者

“-Djava.security=file:/dev/random”

指定使用linux本地的随机算法，

即NativePRNG；

其中“/dev/random”与“/dev/urandom”在不同unix-*平台中实现有所不同，性能也有所差异，建议使用“/dev/urandom”。

/dev/random的一个副本是/dev/urandom （”unlocked”，非阻塞的随机数发生器），它会重复使用熵池中的数据以产生伪随机数据。这表示对/dev/urandom的读取操作不会产生阻塞，但其输出的熵可能小于/dev/random的。它可以作为生成较低强度密码的伪随机数生成器，不建议用于生成高强度长期密码。

算法的内部实现，比较复杂；本人测试，其实性能差不不太大（JDK 8环境）。SecureRandom也是线程安全的。

从输出结果上分析，无论是否指定SecureRandom的初始seed，单个实例多次运行的结果也完全不同 ；多个不同的SecureRandom实例无论是否指定seed，即使指定一样的初始seed，同时运行的结果也完全不同。

SecureRandom继承自Random，但是对nextX方法中的底层方法进行的重写覆盖，不过仍然基于Random的CAS且SecureRandom的底层方法还使用的同步，所以在并发环境下，性能比Random差了一些。

SplittableRandom

JDK 8 新增的API，主要适用于Fork/join形式的跨线程操作中。它并没有继承java.util.Random类。

具有相同seed的不同SplittableRandom实例或者同一个SplittableRandom，多次运行结果是一致的。这和Random是一致的。

非线程安全，不能被并发使用。 （不会报错，但是并发时可能多个线程同时得到相同的随机数）

同ThreadLocalRandom，对“-Djava.util.secureRandom=true”参数支持，但是只有使用默认构造器的时候，才会使用SecureRandom辅助生成初始seed。即不指定初始seed时，同一个SplittableRandom实例多次运行，或者不同的实例运行，结果是不同的。

其中有一个split()方法，用来构造并返回与新的实例，这个实例共享了一些不可变状态。需要注意，split产生的新SplittableRandom实例，与原实例并不存在内部数据的并发竞争，也不会交替或者延续原实例的随机数生成序列（即两个实例产出随机序列的一致性，与原实例没有关系，只是在统计值层面更加接近）；但是代码一致性的情况下，多次运行，其随机数序列的结果总是一致的（假如初始seed是指定的，而非默认），这一点与Random、ThreadLocalRandom表现相同。

public SplittableRandom split() { return new SplittableRandom(nextLong(), mixGamma(nextSeed()));}

样例代码。

System.out.println("第一段");SplittableRandom random = new SplittableRandom(100);Thread thread = new Thread(new Runnable() { @Override public void run() { SplittableRandom _random = random.split(); for (int i=0; i < 5; i++) { System.out.println("---" + _random.nextInt(100)); } }});thread.start();thread.join();for (int i=0; i < 5; i++) { System.out.println("+++" + random.nextInt(100));}System.out.println("第二段");SplittableRandom _random = new SplittableRandom(100);for (int i=0; i < 10; i++) { System.out.println("..." + _random.nextInt(100));}

执行结果。

第一段---71---85---10---60---98+++44+++87+++77+++67+++72第二段...92...30...44...87...77...67...72...23...9...64

从执行结果上看，split产生的random实例与原实例执行结果上没有相似之处；但是不同SplittableRandom实例（无论是否执行过split），其产出随机数序列是一致的。

性能检测

简析，基准：100000随机数，单线程

1、 Random ：2毫秒

2、 ThreadLocalRandom ：1毫秒

3、 SecureRandom

1）默认算法，即SHAR1PRNG：80毫秒左右。

2）NativePRNG：90毫秒左右。

4、 SplittableRandom ：1毫秒

End

平常使用Random，或者大多数时候使用，都是没有问题的，它也是线程安全的。SplittableRandom是内部使用的类，应用较少，即使它也是public的也掩饰不了偏门。ThreadLocalRandom是为了在高并发环境下节省一点细微的时间，追求性能的应用推荐使用。而对于有安全需求的，又希望更随机一些的，用SecureRandom再好不过了。

jdk竟然有这么多随机数生成器。有没有大吃一精？我反正是跪了。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。