我有两个代码选项：
选项1
int myFunc() {
return new Random().nextInt();
}
或者：
选项2
private static final Random random = new Random();
int myFunc() {
return random.nextInt();
}
// For occasional tasks that just need an average quality random number
ExecutorService threadPool = Executors.newCachedThreadPool();
threadPool.execute( () -> {
ThreadLocalRandom.current().nextInt(); // Fast and unique!
} );
// For SecureRandom, high quality random number
final Random r = new SecureRandom();
ExecutorService threadPool = Executors.newCachedThreadPool();
threadPool.execute( () -> {
r.nextInt(); // sun.security.provider.NativePRNG uses singleton. Can't dodge contention.
} );
// Apache Common Math - Mersenne Twister - decent and non-singleton
int cpu = Runtime.getRuntime().availableProcessors();
ExecutorService executor = Executors.newFixedThreadPool( cpu );
Map<Thread, RandomGenerator> random = new WeakHashMap<>( cpu, 1.0f );
executor.execute( ()-> {
RandomGenerator r;
synchronized ( random ) { // Get or create generator.
r = random.get( Thread.currentThread() );
if ( r == null ) random.put( Thread.currentThread(), r = new MersenneTwister() );
}
r.nextInt( 1000 );
} );
解释：
理论上，每个线程中的new Random()不能保证不同的种子。
new Random由nanoTime和一个“唯一”数字种子。实际上，每个线程中的new Random()基本上总是获得不同的种子。
zapl 建议使用ThreadLocalRandom.current().nextInt()。很好的主意。
Random，但它也是一个线性同余生成器。SecureRandom静态种子化，可以产生更好的质量随机数。sun.misc.Unsafe存储种子，这在Java 9中可能被移除，迫使ThreadLocalRandom寻找一种新的方法来避免竞争。n 个高度相关的种子。我的问题是，我是否仍然能够保证均匀性（均匀性，而不是随机性）。 - Benjy Kessler public Random() { this(++seedUniquifier + System.nanoTime()); }
private static volatile long seedUniquifier = 8682522807148012L;
如果你按固定间隔创建Random实例，种子很可能会非常接近，因此选项#1生成的随机数序列容易自相关。
相比之下，Java 7和8做到了这一点：
public Random() {
this(seedUniquifier() ^ System.nanoTime());
}
private static long seedUniquifier() {
// L'Ecuyer, "Tables of Linear Congruential Generators of
// Different Sizes and Good Lattice Structure", 1999
for (;;) {
long current = seedUniquifier.get();
long next = current * 181783497276652981L;
if (seedUniquifier.compareAndSet(current, next))
return next;
}
}
private static final AtomicLong seedUniquifier
= new AtomicLong(8682522807148012L);
编号。
不能保证选项1生成的数字分布的属性。正如其他答案中所明确的那样，java.util.Random的构造器实现取决于系统时间。因此，为了对选项1生成的数字分布的属性做出保证，您需要能够对程序在任何平台上获取系统时间的调用所产生的数字分布做出保证。
然而，使用选项2，可以对程序的一次执行期间将生成的数字的分布做出数学保证。使用线性同余发生器（java.util.Random使用的伪随机数生成算法），一些随机性的属性不如其他算法好，但是分布保证相对均匀。
这并不一定意味着选项1不能满足您的需求。这取决于您要做什么。
Java使用System.nanoTime()和一个顺序计数器来初始化随机种子。这在某种程度上保证了每次调用的种子都不同，尽管我不会称其为具有密码学安全性。
从性能角度来看，您真的希望在选项1中锁定Random的内部状态比以下所有操作都要慢吗：
我的建议是对您的实际应用程序进行基准测试以找出答案，但我预计选项1将是三个选项中最慢的。
SecureRandom仍然是一样的。每次创建一个新的实例并从给定种子生成一个实例，是否仍然安全？还是它与种子的选择（函数调用的时间）如此相关，以至于随机性丢失了。 - Benjy Kessler
ThreadLocalRandom.current().nextInt()。另外，您关于同时生成随机数的说法是错误的，详情请参考https://dev59.com/lHnZa4cB1Zd3GeqPoErj#20060801，它不仅使用时间进行初始化。 - zapl