Распределение случайных чисел

Быстрый Код:

// 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 );
} );

---

Пояснение:

1. Два Random одного и того же семени дадут одинаковые числа.
   Таким образом, мы сосредоточимся на том, можем ли мы гарантировать различные семена.

В теории, new Random() в каждой нити не гарантирует различных семян.

1. новый случайный заполнена nanoTime и "уникальный" номер.
2. число не гарантировано уникальным, потому что его вычисление не является синхронизированный.
3. как для nanoTime, он обещает быть "по крайней мере хорошо, как currentTimeMillis"
4. currentTimeMillis ничего не гарантирует и может быть довольно грубый .
5. в реальной жизни два раза одинаковы только на старых системах linux и Win 98.

На практике new Random() в каждую нить в основном всегда попадают разные семена.

1. создание потока дорого. Мой создает 1 на 50 000 НС. И это не так. медленно .
[18]}50 мкс намного выше общих гранулометрических характеристик нанотайма вплоть до нескольких десятков НС.

вычисление уникального числа (1.2) также происходит быстро, поэтому получение одного и того же числа очень редко.

используйте исполнители для создания пула потоков, чтобы избежать больших накладных расходов на новые потоки.

Zapl предложил ThreadLocalRandom.current().nextInt(). Великая идея.

1. Это так не создать новый Random, но это также линейный конгруэнтный генератор.
2. он генерирует новый случайный для каждого потока вызова в качестве семени этого потока.
3. он построен, чтобы быть очень быстрым в многопоточности. (См. Примечания ниже.)
4. он статически засеян SecureRandom, которые производят более качественные случайные числа.

"равномерно распределенная" - это лишь малая часть случайности. тесты .

1. Random являетсянесколько однородным , и его результат может бытьпредсказан с учетом только двух значений.
2. SecureRandom гарантирует , что этого не произойдет. (то есть криптографически сильный)
3. нет никакого риска столкновения семян, Если вы создадите новый SecureRandom в каждом потоке.
4. но в настоящее время его источником является один поток в любом случае, параллельной генерации нет.
5. для хорошего ГСЧ, поддерживающего многопоточность, найдите внешнюю справку , например Apache Common's MT .

Примечание: детали реализации выведены из исходного кода Java 8. Будущая версия Java может измениться; например, ThreadLocalRandom использует sun.misc.Unsafe для хранения семян, который может быть удален в Java 9, заставляя ThreadLocalRandom найти новый способ работы без разногласий.

- нет.

Нет никаких гарантий относительно свойств распределения чисел, которое будет произведено вариантом 1. Как было ясно показано в других ответах, реализация конструктора для java.util.Random зависит от системного времени. Поэтому, чтобы гарантировать свойства распределения номеров, которые вы получаете с опцией 1, вам нужно будет иметь возможность гарантировать распределение номеров, произведенных вызовами, которые ваша программа делает, чтобы получить системное время на любой платформе, где будет работать программа.

Однако при использовании варианта 2 можно получить математические гарантии относительно распределения чисел, которые будут получены в ходе одного выполнения программы. С линейным конгруэнтным генератором (алгоритм генерации псевдослучайных чисел, используемый java.util.Random) некоторые свойства случайности не так хороши, как с другими алгоритмами, но распределение гарантировано относительно форма. Это не обязательно означает, что Вариант 1 не может служить вашим целям. Это зависит от того, что вы делаете.

Java инициализирует случайное семя с помощью System.nanoTime() и последовательного счетчика. Это дает некоторую гарантию, что семя будет отличаться для каждого вызова, хотя я бы воздержался от того, чтобы называть его криптографически безопасным.

С точки зрения производительности-действительно ли вы ожидаете, что блокировка внутреннего состояния Random в варианте 1 будет иметь более высокую производительность, чем все следующие:

• доступ и увеличение volatile long
• получение тока системное время (, которое довольно дорого )
• динамическое распределение
• Еще один объект для сбора мусора

Мое предложение будет заключаться в том, чтобы сделать бенчмарки вашего реального приложения, чтобы выяснить, но я ожидаю, что Вариант 1 будет самым медленным из всех трех.

По моему опыту, наилучший баланс между хорошим распределением и производительностью достигается с помощью чего-то вроде генератора "Messerne Twister" (см. В Apache Commons) . Еще более причудливое решение см. В разделеthis .