El título resume prácticamente todo - podemos crear una instancia de java.util.Random(o SecureRandom) y usarlo cada vez que necesitamos un valor aleatorio o podemos crear una nueva instancia cada vez bajo demanda. Se pregunta cuál es la preferida forma y por qué?
Para dar una idea acerca del contexto: se genera el valor aleatorio dentro de un controlador de solicitudes HTTP, uno por cada solicitud, y yo estoy buscando la mejor combinación de seguridad y rendimiento teniendo en cuenta múltiples hilos.
Depende.
La creación de una instancia única es obviamente más simple y debe ser el comportamiento predeterminado. Tanto Randomy SecureRandomson multi-hilo, y por lo tanto va a funcionar muy bien. En primer lugar hacer lo simple y lo correcto que las obras, a continuación, medir el rendimiento en contra de su pico de contención / pico esperado Potencia del presupuesto, y analizar los resultados.
Random
Si está utilizando Randomy el enfoque de instancia única es demasiado lento, considere el uso ThreadLocalRandomsi es posible. El JavaDoc en Randomsugiere su uso muy bien:
Los casos de
java.util.Randomejecución en hebras. Sin embargo, el uso simultáneo de la mismajava.util.Randominstancia a través de hilos puede encontrarse con la contención y la consiguiente pobre rendimiento. Considere en lugar de utilizarThreadLocalRandomen los diseños de varios subprocesos.
Sólo se va a crear una instancia para cada hilo para acceder a él. El costo de la creación de un Random/ ThreadLocalRandominstancia no es una locura, pero es más alta que la creación de un objeto "normal", por lo que probablemente debería evitar la creación de una nueva instancia para cada petición entrante. La creación de una por hilo es generalmente un buen punto dulce.
Yo diría que en las aplicaciones modernas con hilos combinados, que casi siempre se debe usar ThreadLocalRandomen lugar de Random- la aleatoriedad es el mismo, pero el rendimiento de un solo hilo es mucho mejor.
SecureRandom
Si usted está utilizando SecureRandom, sin embargo, ThreadLocalRandomno es una opción. Una vez más, no adivine, medida! Tal vez utilizando una sola instancia compartida de un SecureRandomserá lo suficientemente bueno. Prueba con su afirmación de pico esperado, y si la instancia aleatoria seguro resulta ser un cuello de botella, sólo entonces pensar en maneras de mejorar la situación.
Creación de una SecureRandominstancia es muy costoso, por lo que a pesar de todo no desea crear uno para cada petición entrante.
Dependiendo de la aplicación, una ThreadLocal<SecureRandom>puede ser una opción. Sin embargo, creo que es una exageración, y un esquema similar a la Stripedclase (con X SecureRandominstancias creadas y se accede al azar para ayudar a prevenir la contención) pueden preferirse.