ThreadLocalRandom.nextGaussian() uses locking Random.nextGaussian() implementation
James Yuzawa
jtyuzawa at gmail.com
Tue Nov 18 17:44:40 UTC 2025
Hello,
I have noticed in Java 25 (and earlier versions) that calling ThreadLocalRandom.current().nextGaussian() uses the Random.nextGaussian() implementation, which is synchronized. Under heavy load in a multithreaded environment, I was detecting lock contention.
Here is a very simple reproducer:
ThreadLocalRandom r = ThreadLocalRandom.current();
// step into this call using a debugger
r.nextGaussian();
It dispatches to the synchronized Random implementation, since ThreadLocalRandom extends Random, thus the default implementation (not synchronizing) on RandomGenerator is not used.
Sketch:
public interface RandomGenerator {
default double nextGaussian() {
// remove TAOCP comment since it is out of date
return RandomSupport.computeNextGaussian(this);
}
}
public class Random implements RandomGenerator {
@Override
public synchronized double nextGaussian() {
// synchronized version ...
}
}
public class ThreadLocalRandom extends Random {
// ADD THIS
@Override
public double nextGaussian() {
return RandomSupport.computeNextGaussian(this);
}
}
A comment on ThreadLocalRandom introduced in JDK-8248862 states "This implementation of ThreadLocalRandom overrides the definition of the nextGaussian() method in the class Random, and instead uses the ziggurat-based algorithm that is the default for the RandomGenerator interface.” However, there is none such override happening. It appears that prior to JDK-8248862 and a0ec2cb289463969509fe508836e3faf789f46d8 the nextGaussian implementation was non-locking since it used proper ThreadLocals.
I have a patch which remedies this by using the same implementation as RandomGenerator. I am willing to submit https://github.com/openjdk/jdk/compare/master...yuzawa-san:jdk:refs/heads/thread-local-random-nextGaussian Per the contribution instructions, I have signed the OCA in prior work on project Panama, but am looking for community input, sponsorship, and help creating an issue if this is something we wish to pursue.
Thank you,
James Yuzawa
More information about the core-libs-dev
mailing list