[concurrency-interest] ThreadLocalRandom

Jeremy Manson jeremy.manson at gmail.com
Tue Jan 13 01:26:00 EST 2009

This seems a little weirdly backwards to me (although I'm sure you had
a good reason to do it this way).  Given that (I assume) you can't
change the class hierarchy to add a superclass for Random, why didn't
you extract the actual random number generation logic into a delegate
class and have both Random and ThreadLocalRandom point to that class?


On Mon, Jan 12, 2009 at 9:31 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> As probably the final refactoring pass on Java7 versions of ForkJoin etc
> the thread-local random generator was pulled out into a stand-alone class.
> Class ThreadLocalRandom is useful in most situations where people use
> java.util.Random across multiple threads. It is a subclass of Random,
> but has no constructor -- instead a static "current()" method to
> get the one for the current thread. It also doesn't let you change
> the seed. (So people who need thread-local generators with explicit
> seed control can't use it.)
> The main reason for using it is performance, including performance
> testing. Using a contended shared Random will often be 10X slower,
> and mask the performance differences you are actually looking for.
> (Some SPEC benchmarks have had this problem.)
> See:
> http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166ydocs/jsr166y/ThreadLocalRandom.html
> Comments welcome.
> Also, as we move closer to jdk7 (openjdk) integration,
> anyone wanting to help with code or documentation reviews
> ot testing might want to take a look. See links from
> http://gee.cs.oswego.edu/dl/concurrency-interest/index.html
> -Doug
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list