java.util.Random和concurrent.ThreadLocalRandom使用對比
java.util.Random和concurrent.ThreadLocalRandom對比
最近工作中遇到了一個需求
需要以一定的概率過濾掉一部分的流量,想想只能用Random了,因為是在多線程環(huán)境下,我還特意確認了下Random在多線程是否能正常運行,Random的實現(xiàn)也比較簡單,初始化的時候用當前的事件來初始化一個隨機數(shù)種子,然后每次取值的時候用這個種子與有些MagicNumber運算,并更新種子。
最核心的就是這個next的函數(shù),不管你是調(diào)用了nextDouble還是nextInt還是nextBoolean,Random底層都是調(diào)這個next(int bits)。
protected int next(int bits) {
long oldseed, nextseed;
AtomicLong seed = this.seed;
do {
oldseed = seed.get();
nextseed = (oldseed * multiplier + addend) & mask;
} while (!seed.compareAndSet(oldseed, nextseed));
return (int)(nextseed >>> (48 - bits));
}為了保證多線程下每次生成隨機數(shù)都是用的不同
next()得保證seed的更新是原子操作,所以用了AtomicLong的compareAndSet(),該方法底層調(diào)用了sum.misc.Unsafe的compareAndSwapLong(),也就是大家常聽到的CAS, 這是一個native方法,它能保證原子更新一個數(shù)?! ?/p>
既然Random滿足我的需求,又能在多線程下正常運行,所以我直接用了random,后來在codeReview中,同事提出用concurrent.ThreadLocalRandom來替代Random。
我腦子里立馬冒出一個問題,既然random是線程安全的,為什么concurrent包里還要實現(xiàn)一個random。
在oracle的jdk文檔里發(fā)現(xiàn)這樣一句話:
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 (for example, each a ForkJoinTask) use random numbers in parallel in thread pools.
大意就是用ThreadLocalRandom更適合用在多線程下,能大幅減少多線程并行下的性能開銷和資源爭搶?! ?/p>
既然文檔里說的牛,到底能有多少的性能提升?
我做了一個簡單的測試。
測試環(huán)境:
24核 CPU, jdk8,每個隨機生成100000個double數(shù),分別測試不同線程數(shù)下rando和ThreadLocalRandom的運行時間,數(shù)據(jù)如下:

ThreadNum,Random,ThreadLocalRandom
50,1192,575
100,4031,162
150,6068,223
200,8093,287
250,10049,248
300,12346,200
350,14429,212
400,16491,62
450,18475,96
500,11311,97
550,12421,90
600,13577,102
650,14718,111
700,15896,127
750,17101,129
800,17907,203
850,19261,226
900,21576,151
950,22206,147
1000,23418,174
ThreadLocalRandom雖然也有波動,但基本上是平的,而random隨著線程數(shù)的增加一直在增加,在1000個線程時兩者居然有百倍的性能差距。
不過這里有個讓人百思不得其解的現(xiàn)象,為什么random的耗時在500個線程的時候又掉下來,測試多次都是這個情況,可見并不是偶發(fā)現(xiàn)象。
我也在本人的筆記本上測了下,我筆記本雙核i7,ThreadLocalRandom和Random性能差距最高也有100倍,我發(fā)現(xiàn)我筆記本比公司服務(wù)器跑的快(數(shù)據(jù)如下)。。。。
我也在一臺1核的阿里云ECS上測試了,按道理1核心的技術(shù)上,即便是多線程起始也是串行執(zhí)行的,但ThreadLocalRandom和Random在1000個線程的情況下也有6倍的性能差距。

既然ThreadLocalRandom在多線程下表現(xiàn)這么牛,它究竟是如何做到的?
我們來看下源碼,它的核心代碼是這個:
final long nextSeed() {
Thread t; long r; // read and update per-thread seed
UNSAFE.putLong(t = Thread.currentThread(), SEED,
r = UNSAFE.getLong(t, SEED) + GAMMA);
return r;
}起始ThreadLocalRandom是對每個線程都設(shè)置了單獨的隨機數(shù)種子,這樣就不會發(fā)生多線程同時更新一個數(shù)時產(chǎn)生的資源爭搶了,用空間換時間?! ?/p>
附上Random和ThreadLocalRandom的性能測試代碼
import java.util.Random;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.ThreadLocalRandom;
import java.util.concurrent.TimeUnit;
public class RandomTest {
private static Random random = new Random();
private static final int N = 100000;
// Random from java.util.concurrent.
private static class TLRandom implements Runnable {
@Override
public void run() {
double x = 0;
for (int i = 0; i < N; i++) {
x += ThreadLocalRandom.current().nextDouble();
}
}
}
// Random from java.util
private static class URandom implements Runnable {
@Override
public void run() {
double x = 0;
for (int i = 0; i < N; i++) {
x += random.nextDouble();
}
}
}
public static void main(String[] args) {
System.out.println("threadNum,Random,ThreadLocalRandom");
for (int threadNum = 50; threadNum <= 2000; threadNum += 50) {
ExecutorService poolR = Executors.newFixedThreadPool(threadNum);
long RStartTime = System.currentTimeMillis();
for (int i = 0; i < threadNum; i++) {
poolR.execute(new URandom());
}
try {
poolR.shutdown();
poolR.awaitTermination(100, TimeUnit.SECONDS);
} catch (InterruptedException e) {
e.printStackTrace();
}
String str = "" + threadNum +"," + (System.currentTimeMillis() - RStartTime)+",";
ExecutorService poolTLR = Executors.newFixedThreadPool(threadNum);
long TLRStartTime = System.currentTimeMillis();
for (int i = 0; i < threadNum; i++) {
poolTLR.execute(new TLRandom());
}
try {
poolTLR.shutdown();
poolTLR.awaitTermination(100, TimeUnit.SECONDS);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(str + (System.currentTimeMillis() - TLRStartTime));
}
}
}
總結(jié)
以上為個人經(jīng)驗,希望能給大家一個參考,也希望大家多多支持腳本之家。
相關(guān)文章
利用反射獲取Java類中的靜態(tài)變量名及變量值的簡單實例
下面小編就為大家?guī)硪黄梅瓷浍@取Java類中的靜態(tài)變量名及變量值的簡單實例。小編覺得挺不錯的,現(xiàn)在就分享給大家,也給大家做個參考。一起跟隨小編過來看看吧2016-12-12
解決IDEA下載依賴包源碼報錯Sources not found for:org.spri
IDEA查看源碼時如遇無法下載源代碼報錯,可通過Maven命令或配置IDEA自動下載源碼來解決,保證依賴包能自動獲取源碼,提升開發(fā)體驗2025-10-10
SpringBoot啟動時自動執(zhí)行指定方法的幾種實現(xiàn)方式
在Spring Boot應(yīng)用程序中,要實現(xiàn)在應(yīng)用啟動時自動執(zhí)行某些代碼,本文主要介紹了SpringBoot啟動時自動執(zhí)行指定方法的幾種方式,文中有相關(guān)的代碼示例供大家參考,需要的朋友可以參考下2024-03-03
java使用BeanUtils.copyProperties踩坑經(jīng)歷
最近在做個項目,踩了個坑特此記錄一下,本文主要介紹了使用BeanUtils.copyProperties踩坑經(jīng)歷,需要的朋友們下面隨著小編來一起學習學習吧2021-05-05
SpringMVC JSON數(shù)據(jù)交互及RESTful支持實現(xiàn)方法
這篇文章主要介紹了SpringMVC JSON數(shù)據(jù)交互及RESTful支持實現(xiàn)方法,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下2020-06-06
Java JVM原理與調(diào)優(yōu)_動力節(jié)點Java學院整理
JVM是Java Virtual Machine(Java虛擬機)的縮寫,JVM是一種用于計算設(shè)備的規(guī)范,它是一個虛構(gòu)出來的計算機,是通過在實際的計算機上仿真模擬各種計算機功能來實現(xiàn)的。下面通過本文給大家介紹jvm原理與調(diào)優(yōu)相關(guān)知識,感興趣的朋友一起學習吧2017-04-04
springboot中使用過濾器,jsoup過濾XSS腳本詳解
這篇文章主要介紹了springboot中使用過濾器,jsoup過濾XSS腳本詳解,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2021-12-12

