Действительно ли SecureRandom ориентирован на многопотоковое исполнение?
Другая опция для нескольких дополнительных аргументов состоит в том, чтобы передать их всех в NSDictionary:
- (void)someMethodWithOptions:(NSDictionary *)options;
затем объявляют, что словарь опций может содержать:
- key1, value must be a BlahObject
- key2, value must be a NonBlahObject
можно затем позволить любому из ключей отсутствовать, и даже сам словарь мог быть нолем.
2 ответа
Да, это так. Он расширяет Random , который всегда имел де-факто потокобезопасную реализацию, и, начиная с Java 7, явно гарантирует безопасность потоков.
Если многие потоки используют один SecureRandom , может возникнуть конфликт, снижающий производительность. С другой стороны, инициализация экземпляра SecureRandom может быть относительно медленной. Лучше всего использовать глобальный ГСЧ или создать новый для каждого потока - зависит от вашего приложения. Класс ThreadLocalRandom можно использовать в качестве шаблона для предоставления решения, поддерживающего SecureRandom .
Текущий реализация SecureRandom является потокобезопасной, в частности, синхронизируются два метода изменения nextBytes (bytes []) и setSeed (byte []) .
Насколько я могу судить, все методы мутации в конечном итоге маршрутизируются через эти два метода, и SecureRandom переопределяет несколько методов в Random , чтобы гарантировать, что . Что работает, но может быть нестабильным, если реализация будет изменена в будущем.
Лучшее решение - сначала вручную синхронизировать экземпляр SecureRandom . Это означает, что каждый стек вызовов получит две блокировки для одного и того же объекта, но на современных JVM это обычно очень дешево. То есть явная синхронизация себя не представляет особого вреда. Например:
SecureRandom rnd = ...;
byte[] b = new byte[NRANDOM_BYTES];
synchronized (rnd) {
rnd.nextBytes(b);
}