由于功能改造需要做灰度上线，通过使用权重来控制让一部分流量走原来的逻辑，一部分流量走改造后的逻辑，基于权重的方案需要根据生成的随机数来看落到哪个区间（类似dubbo的基于权重负载均衡），一般比较常见的就是使用Random生成随机数。作为开发人员，习惯性的会考虑到类的并发安全问题和性能，所以会去先去了解一下类。由于项目使用的是jdk7 翻看java jdk关于Random的文档，发现下面这句话：
Instances of java.util.Random are threadsafe. However, the concurrent use of the same java.util.Random instance across threads may encounter contention and consequent poor performance. Consider instead using ThreadLocalRandom in multithreaded designs.
文档上说Random这个类是线程安全的，但是高并发情况下会引起线程竞争性能不好，推荐使用ThreadLocalRandom。为什么多线程下，Random 的性能不佳？因为，它采用了多个线程共享一个 Random 实例。这样就会导致多个线程争用。
官方推荐ThreadLocalRandom！！ 看来有必要了解一下。
并发安全
虽然文档说了Random是并发安全的，但还是有必要源码确认一下。Random的实现也比较简单，初始化的时候用当前的事件来初始化一个随机数种子，然后每次取值的时候用这个种子与有些MagicNumber运算，并更新种子。最核心的就是这个next的函数，不管你是调用了nextDouble还是nextInt还是nextBoolean，Random底层都是调这个next(int bits)。
为了保证多线程下每次生成随机数都是用的不同，next()得保证seed的更新是原子操作，所以用了AtomicLong的compareAndSet()，该方法底层调用了sum.misc.Unsafe的compareAndSwapLong()，也就是大家常听到的CAS， 这是一个native方法，它能保证原子更新一个数。可以看出多个线程如果CAS设置失败，会不停的在while循环执行。
看下ThreadLocalRandom文档里怎么说的：
When applicable, use of ThreadLocalRandom rather than shared Random objects in concurrent programs will typically encounter much less overhead and contention.
Usages of this class should typically be of the form: ThreadLocalRandom.current().nextX(...) (where X is Int, Long, etc).
大意是并发情况下，使用ThreadLocalRandom能引起更少的线程竞争。也就是性能更好。典型的使用方式是：
ThreadLocalRandom.current().nextX(随机数范围)；
看下源码实现：
current实现
跟进localInit方法
next方法实现
跟进nextSeed
看来是通过为每个线程实例化一个随机数生成器，来减少系统开销和对资源的争用。
性能：
使用 JMH 比较 ThreadLocalRandom 和 Random
Random测试代码，
测试结果
ThreadLocalRandom测试代码
测试结果
通过 JMH 的测试结果中可以看出，使用 Random 生成 1000 个随机值所花费的平均时间是 3653 微秒，但使用 ThreadLocalRandom 只花了 2362 微秒，嗯，差距不是很大，但好歹也是有差距的。
网友评论