safety - thread safe method java

¿SecureRandom es seguro para subprocesos?

Question

¿ SecureRandom es SecureRandom subprocesos? Es decir, después de inicializarlo, ¿se puede confiar en que el acceso al siguiente número aleatorio sea seguro para la ejecución de subprocesos? Al examinar el código fuente parece mostrar que sí, y este informe de error parece indicar que su falta de documentación como hilo seguro es un problema de Javadoc. ¿Alguien ha confirmado que, de hecho, es seguro para subprocesos?

Answer 1

La implementación actual de SecureRandom es segura para subprocesos, específicamente los dos métodos de mutación nextBytes(bytes[]) y setSeed(byte[]) están sincronizados.

Bueno, por lo que he podido decir, todos los métodos de mutación finalmente se enrutan a través de esos dos métodos, y SecureRandom anula algunos métodos en Random para garantizarlo. Lo cual funciona, pero podría ser frágil si la implementación cambia en el futuro.

La mejor solución es sincronizar manualmente en la instancia de SecureRandom primero. Esto significa que cada pila de llamadas adquirirá dos bloqueos en el mismo objeto, pero eso suele ser muy barato en las JVM modernas. Es decir, no hay mucho daño en sincronizarse explícitamente. Por ejemplo:

    SecureRandom rnd = ...;

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

Answer 2

Sí lo es. Amplía Random , que siempre tuvo una implementación threadsafe de facto y, desde Java 7, garantiza explícitamente la seguridad de threadsafety.

Si muchos subprocesos usan un solo SecureRandom , puede haber una disputa que perjudica el rendimiento. Por otro lado, inicializar una instancia de SecureRandom puede ser relativamente lento. Si es mejor compartir un RNG global, o crear uno nuevo para cada hilo dependerá de su aplicación. La clase ThreadLocalRandom podría usar como un patrón para proporcionar una solución que admita SecureRandom .

Answer 3

Sí. Es totalmente seguro para subprocesos. En realidad, me quejaría de que el candado es demasiado agresivo. Todo el engineNextBytes() está sincronizado.

Para ser franco con usted, no sabría si no es seguro. El problema del enhebrado probablemente introduce más aleatoriedad :)