### Details
A little change, replace `Random` with `ThreadLocalRandom` .
Use of ThreadLocalRandom rather than shared Random objects in concurrent
programs will typically encounter much less overhead and contention.
Use of ThreadLocalRandom is particularly appropriate when multiple tasks .
### Benchmark
There are some attentions need to be noticed before benchmark.
1. third-party dependency need use carefully.
2. bugs fix need to trace from upstream repository.
3. performance benchmark
I have compared the three cases : `Random`,`ThreadLocalRandom` from JDK,
`ThreadLocalRandom` from netty.
```
@BenchmarkMode({Mode.AverageTime})
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(iterations = 3, time = 5)
@Measurement(iterations = 3, time = 5)
@Threads(50)
@Fork(1)
@State(Scope.Benchmark)
public class RandomBenchmark {
Random random = new Random();
@Benchmark
public int random() {
return random.nextInt();
}
@Benchmark
public int threadLocalRandom() {
return ThreadLocalRandom.current().nextInt();
}
@Benchmark
public int nettyThreadLocalRandom() {
return io.netty.util.internal.ThreadLocalRandom.current().nextInt();
}
public static void main(String[] args) throws RunnerException {
Options opt = new OptionsBuilder()
.include(RandomBenchmark.class.getSimpleName())
.build();
new Runner(opt).run();
}
}
```
and below is our benchmark result under 50 concurrency
```
Benchmark Mode Cnt Score Error Units
RandomBenchmark.nettyThreadLocalRandom avgt 3 160.321 ± 83.518 ns/op
RandomBenchmark.random avgt 3 3281.972 ± 2093.187 ns/op
RandomBenchmark.threadLocalRandom avgt 3 91.505 ± 39.702 ns/op
```
From the result we can know the truth
> Both the performance (according to above benchmark) and the stability（it is
> from the JDK）
> JDK 's ThreadLocalRandom looks good.
[ Full content available at:
https://github.com/apache/incubator-dubbo/issues/2444 ]
This message was relayed via gitbox.apache.org for [email protected]
