快捷導(dǎo)航

java.util.Random和concurrent.ThreadLocalRandom使用對比

更新時(shí)間：2024年07月04日 10:33:14 作者：xindoo

這篇文章主要介紹了java.util.Random和concurrent.ThreadLocalRandom使用對比,具有很好的參考價(jià)值,希望對大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教

java.util.Random和concurrent.ThreadLocalRandom對比

最近工作中遇到了一個(gè)需求

需要以一定的概率過濾掉一部分的流量，想想只能用Random了，因?yàn)槭窃诙嗑€程環(huán)境下，我還特意確認(rèn)了下Random在多線程是否能正常運(yùn)行，Random的實(shí)現(xiàn)也比較簡單，初始化的時(shí)候用當(dāng)前的事件來初始化一個(gè)隨機(jī)數(shù)種子，然后每次取值的時(shí)候用這個(gè)種子與有些MagicNumber運(yùn)算，并更新種子。

最核心的就是這個(gè)next的函數(shù)，不管你是調(diào)用了nextDouble還是nextInt還是nextBoolean，Random底層都是調(diào)這個(gè)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));
    }

為了保證多線程下每次生成隨機(jī)數(shù)都是用的不同

next()得保證seed的更新是原子操作，所以用了AtomicLong的compareAndSet()，該方法底層調(diào)用了sum.misc.Unsafe的compareAndSwapLong()，也就是大家常聽到的CAS，這是一個(gè)native方法，它能保證原子更新一個(gè)數(shù)?！　?/p>

既然Random滿足我的需求，又能在多線程下正常運(yùn)行，所以我直接用了random，后來在codeReview中，同事提出用concurrent.ThreadLocalRandom來替代Random。

我腦子里立馬冒出一個(gè)問題，既然random是線程安全的，為什么concurrent包里還要實(shí)現(xiàn)一個(gè)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>

既然文檔里說的牛，到底能有多少的性能提升？

我做了一個(gè)簡單的測試。

測試環(huán)境：

24核 CPU， jdk8，每個(gè)隨機(jī)生成100000個(gè)double數(shù)，分別測試不同線程數(shù)下rando和ThreadLocalRandom的運(yùn)行時(shí)間，數(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個(gè)線程時(shí)兩者居然有百倍的性能差距。

不過這里有個(gè)讓人百思不得其解的現(xiàn)象，為什么random的耗時(shí)在500個(gè)線程的時(shí)候又掉下來，測試多次都是這個(gè)情況，可見并不是偶發(fā)現(xiàn)象。

我也在本人的筆記本上測了下，我筆記本雙核i7，ThreadLocalRandom和Random性能差距最高也有100倍，我發(fā)現(xiàn)我筆記本比公司服務(wù)器跑的快（數(shù)據(jù)如下）。。。。

我也在一臺1核的阿里云ECS上測試了，按道理1核心的技術(shù)上，即便是多線程起始也是串行執(zhí)行的，但ThreadLocalRandom和Random在1000個(gè)線程的情況下也有6倍的性能差距。

　　這里寫圖片描述

既然ThreadLocalRandom在多線程下表現(xiàn)這么牛，它究竟是如何做到的？

我們來看下源碼，它的核心代碼是這個(gè)：

    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是對每個(gè)線程都設(shè)置了單獨(dú)的隨機(jī)數(shù)種子，這樣就不會發(fā)生多線程同時(shí)更新一個(gè)數(shù)時(shí)產(chǎn)生的資源爭搶了，用空間換時(shí)間?！　?/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));
        }
    }
}