我们从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。调用过程一样，其中产生的随机数序列也是完全一样的。多次执行结果也完全一致，简单而言，只要初始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竟然有这么多随机数生成器。有没有大吃一精？我反正是跪了。
到此这篇关于jdk竟有4个random的文章就介绍到这了,更多相关jdk有4个random内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
往往为了自己的不能失败，而处心积虑前怕狼后怕虎，
