关于Java中的随机数库

向右看齐 2022-03-20 11:38 199阅读 0赞

**一、Random**

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

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

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

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

**二、ThreadLocalRandom**

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

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

**三、SecureRandom**

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

**四、SplittableRandom**

JDK 8 新增的API，主要适用于Fork/join形式的跨线程操作喝并行Stream，其未继承java.util.Random类。

1、在seed生成和使用层面，实现与ThreadLocalRandom一致，但其并没有继承ThreadLocalRandom。

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

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

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

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

从Java 7开始，就不应该再使用Random了。现在选择随机数生成器，大多使用ThreadLocalRandom，它会产生更高质量的随机数，并且速度非常快，比Random快几倍是有的。