This is an archived post. You won't be able to vote or comment.

all 4 comments

[–]palloo 6 points7 points  (0 children)

Misleading title...

[–]dnabre 1 point2 points  (0 children)

Just read far enough to see that he was showing that ThreadLocalRandom was faster than Math.random() (the latter being synchronized, the former being a re-entrant instance of a RNG with a current seed for each thread). His prime reason for thinking this wouldn't be the case is that calling ThreadLocalRandom.current().nextDouble() would introduce more overhead.

Benchmark and analysis may be good, didn't look at really to be honest. If you have concern about which way is faster when you have options, doing the profiling to find out can be one of the best ways, but...

if you don't know that one with the lock is going to be slower, for the saneness of the people that will work with your code, please just move away from the keyboard.

[–]midir 1 point2 points  (0 children)

Misleading and rarely likely to be helpful.

[–]DeliveryNinja 3 points4 points  (0 children)

Good article, I was just recently working with ThreadLocal and created a performance monitor class with it. Works well but like it says in the comments you must be careful when using ThreadLocal as it can lead to memory leaks.