Безопасно ли защищать поток SecureRandom?

Question

Безопасен ли SecureRandom поток? То есть, после его инициализации можно ли рассчитывать на доступ к следующему случайному числу, чтобы обеспечить безопасность потока? Изучение исходного кода, кажется, показывает, что это так, и этот отчет об ошибке , кажется, указывает на то, что отсутствие документации в качестве поточно-ориентированной является проблемой javadoc. Кто-нибудь подтвердил, что это на самом деле потокобезопасно?

Answer 1

Да, это так. Он расширяет Random, который всегда имел де-факто поточно-ориентированную реализацию, и, начиная с Java 7, явно гарантирует безопасность потоков.

Если многие потоки используют один SecureRandom, может возникнуть конфликт, который снижает производительность. С другой стороны, инициализация экземпляра SecureRandom может быть относительно медленной. Будет ли лучше разделить глобальный ГСЧ или создать новый для каждого потока, будет зависеть от вашего приложения. Класс ThreadLocalRandom может использоваться в качестве шаблона для предоставления решения, поддерживающего SecureRandom.

Answer 2

Текущая реализация SecureRandom является поточно-ориентированной, в частности синхронизируются два метода мутации nextBytes(bytes[]) и setSeed(byte[]).

Ну, насколько я могу судить, все методы мутации в конечном итоге направляются через эти два метода, и SecureRandom переопределяет несколько методов в Random, чтобы гарантировать это. Что работает, но может быть хрупким, если реализация изменится в будущем.

Лучшее решение - сначала вручную выполнить синхронизацию на экземпляре SecureRandom. Это означает, что каждый стек вызовов получает две блокировки для одного и того же объекта, но это обычно очень дешево на современных JVM. То есть нет особого вреда в явной синхронизации себя. Например:

    SecureRandom rnd = ...;

    byte[] b = new byte[NRANDOM_BYTES];
    synchronized (rnd) {
        rnd.nextBytes(b);
    }