Czy preferuję ThreadLocalRandom nad ThreadLocal <Random>?

Question

Szukam użyć (zaszczepione) Random obiektów w wielu wątków, a javadocs wskazał mi ThreadLocalRandom, który wygląda świetnie, z wyjątkiem nie mogę ustawić materiału siewnego, więc nie mogę zapewnić spójności między różnymi wątkami lub uruchomień. Czy istnieje jakiś praktyczny powód, aby korzystać ThreadLocalRandom lub byłoby dopuszczalne zrobić coś jak następuje:

// Pass returned ThreadLocal object to all threads which need it 
public static ThreadLocal<Random> threadRandom(final long seed) { 
    return new ThreadLocal<Random>(){ 
     @Override 
     protected Random initialValue() { 
      return new Random(seed); 
     } 
    }; 
} 

Answer 1

Możesz po prostu użyć Random, upewnij się tylko, że każdy obiekt Random jest dostępny tylko w jednym wątku.

Random, będąc klasą starożytną, taką jak Vector, jest niepotrzebnie mocno zsynchronizowany. Prawdopodobnie chcieli pokazać wsparcie dla Javy, ponieważ była to wielka sprawa w tym czasie. Również Java była przeznaczona głównie do komputerów osobistych, które w większości miały jeden procesor, więc synchronizacja nie miała wpływu na skalowanie, tak jak ma to miejsce obecnie w przypadku wieloprocesorowych.

Teraz oczywistą odpowiedzią jest dostarczenie niebezpiecznej dla wątków wersji Random, podobnie jak dostarczenie wątku-unsfae ArrayList jako alternatywy dla Vector. Tak się nie stało, zamiast tego dostaliśmy ThreadLocalRandom. To trochę dziwne, nie jestem pewna, na czym polega motywacja. W java8, ThreadLocalRandom jest dodatkowo zoptymalizowany do działania bezpośrednio na niektórych polach int obiektu Thread.

Answer 2

code for ThreadLocalRandom wydaje się być realizowany jako ThreadLocal mimo to (nie dokładnie jakbyś umieścić go, ale prawdopodobnie blisko dość). Myślę, że to, co masz, będzie dobrze działać.

Answer 3

Po pierwsze, twój kod używa tego samego materiału siewnego dla każdego wątku. To może być problem z bezpieczeństwem. Co więcej, każdy dostęp do członka twojej instancji Random jest zsynchronizowany, więc będzie wolniejszy niż odpowiednie metody ThreadLocalRandom (które nie są zsynchronizowane). Jeśli kompilator może mieć pewność, że instancja Przypadkowa nie ucieknie od bieżącego wątku, może zoptymalizować te "zsynchronizowane". ale Ponieważ możesz przechowywać wspólne odniesienia w ThreadLocal, kompilator nie może tego sprawdzić.