java高并發情況下如何高效生成隨機數

今天小編給大家分享一下java高并發情況下如何高效生成隨機數的相關知識點，內容詳細，邏輯清晰，相信大部分人都還太了解這方面的知識，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來了解一下吧。

前言

在代碼中生成隨機數，是一個非常常用的功能，并且JDK已經提供了一個現成的Random類來實現它，并且Random類是線程安全的。

下面是Random.next()生成一個隨機整數的實現：

protected int next(int bits) {
    long oldseed, nextseed;
    AtomicLong seed = this.seed;
    do {
        oldseed = seed.get();
        nextseed = (oldseed * multiplier + addend) & mask;
      //CAS 有競爭是效率低下
    } while (!seed.compareAndSet(oldseed, nextseed));
    return (int)(nextseed >>> (48 - bits));
}

不難看到，上面的方法中使用CAS操作更新seed，在大量線程競爭的場景下，這個CAS操作很可能失敗，失敗了就會重試，而這個重試又會消耗CPU運算，從而使得性能大大下降了。

因此，雖然Random是線程安全的，但是并不是“高并發”的。

為了改進這個問題，增強隨機數生成器在高并發環境中的性能，于是乎，就有了ThreadLocalRandom——一個性能強悍的高并發隨機數生成器。

ThreadLocalRandom繼承自Random，根據里氏代換原則，這說明ThreadLocalRandom提供了和Random相同的隨機數生成功能，只是實現算法略有不同。

在Thread中的變量

為了應對線程競爭，Java中有一個ThreadLocal類，為每一個線程分配了一個獨立的，互不相干的存儲空間。

ThreadLocal的實現依賴于Thread對象中的ThreadLocal.ThreadLocalMap threadLocals成員字段。

與之類似，為了讓隨機數生成器只訪問本地線程數據，從而避免競爭，在Thread中，又增加了3個成員：

/** The current seed for a ThreadLocalRandom */
@sun.misc.Contended("tlr")
long threadLocalRandomSeed;
/** Probe hash value; nonzero if threadLocalRandomSeed initialized */
@sun.misc.Contended("tlr")
int threadLocalRandomProbe;
/** Secondary seed isolated from public ThreadLocalRandom sequence */
@sun.misc.Contended("tlr")
int threadLocalRandomSecondarySeed;

這3個字段作為Thread類的成員，便自然和每一個Thread對象牢牢得捆綁在一起，因此成為了名副其實的ThreadLocal變量，而依賴這幾個變量實現的隨機數生成器，也就成為了ThreadLocalRandom。

消除偽共享

不知道大家有沒有注意到， 在這些變量上面，都帶有一個注解@sun.misc.Contended，這個注解是干什么用的呢？要了解這個，大家得先知道一下并發編程中的一個重要問題——偽共享：

我們知道，CPU是不直接訪問內存的，數據都是從高速緩存中加載到寄存器的，高速緩存又有L1，L2，L3等層級。在這里，我們先簡化這些負責的層級關系，假設只有一級緩存和一個主內存。

CPU讀取和更新緩存的時候，是以行為單位進行的，也叫一個cache line，一行一般64字節，也就是8個long的長度。

因此，問題就來了，一個緩存行可以放多個變量，如果多個線程同時訪問的不同的變量，而這些不同的變量又恰好位于同一個緩存行，那會發生什么呢？

如上圖所示，X,Y為相鄰2個變量，位于同一個緩存行，兩個CPU core1 core2都加載了他們，core1更新X，同時，core2更新Y，由于數據的讀取和更新是以緩存行為單位的，這就意味著當這2件事同時發生時，就產生了競爭，導致core1和core2有可能需要重新刷新自己的數據（緩存行被對方更新了），這就導致系統的性能大大折扣，這就是偽共享問題。

那怎么改進呢？如下圖：

上圖中，我們把X單獨占用一個緩存行，Y單獨占用一個緩存行，這樣各自更新和讀取，都不會有任何影響了。

而上述代碼中的@sun.misc.Contended(“tlr”)就會在虛擬機層面，幫助我們在變量的前后生成一些padding，使得被標注的變量位于同一個緩存行，不與其它變量沖突。

在Thread對象中，成員變量threadLocalRandomSeed，threadLocalRandomProbe，threadLocalRandomSecondarySeed被標記為同一個組tlr，使得這3個變量放置于一個單獨的緩存行，而不與其它變量發生沖突，從而提高在并發環境中的訪問速度。

反射的高效替代方案

隨機數的產生需要訪問Thread的threadLocalRandomSeed等成員，但是考慮到類的封裝性，這些成員卻是包內可見的。

很不幸，ThreadLocalRandom位于java.util.concurrent包，而Thread則位于java.lang包，因此，ThreadLocalRandom并沒有辦法訪問Thread的threadLocalRandomSeed等變量。

這時，Java老鳥們可能就會跳出來說：這算什么，看我的反射大法，不管啥都能摳出來訪問一下。

說的不錯，反射是一種可以繞過封裝，直接訪問對象內部數據的方法，但是，反射的性能不太好，并不適合作為一個高性能的解決方案。

有沒有什么辦法可以讓ThreadLocalRandom訪問Thread的內部成員，同時又具有遠超于反射的，且無限接近于直接變量訪問的方法呢？答案是肯定的，這就是使用Unsafe類。

這里，就簡單介紹一下用的兩個Unsafe的方法：

public native long    getLong(Object o, long offset);
public native void    putLong(Object o, long offset, long x);

其中getLong()方法，會讀取對象o的第offset字節偏移量的一個long型數據；putLong()則會將x寫入對象o的第offset個字節的偏移量中。

這類類似C的操作方法，帶來了極大的性能提升，更重要的是，由于它避開了字段名，直接使用偏移量，就可以輕松繞過成員的可見性限制了。

性能問題解決了，那下一個問題是，我怎么知道threadLocalRandomSeed成員在Thread中的偏移位置呢，這就需要用unsafe的objectFieldOffset()方法了，請看下面的代碼：

上述這段static代碼，在ThreadLocalRandom類初始化的時候，就取得了Thread成員變量threadLocalRandomSeed，threadLocalRandomProbe，threadLocalRandomSecondarySeed在對象偏移中的位置。

因此，只要ThreadLocalRandom需要使用這些變量，都可以通過unsafe的getLong()和putLong()來進行訪問(也可能是getInt()和putInt())。

比如在生成一個隨機數的時候：

protected int next(int bits) {
    return (int)(mix64(nextSeed()) >>> (64 - bits));
}
final long nextSeed() {
    Thread t; long r; // read and update per-thread seed
    //在ThreadLocalRandom中，訪問了Thread的threadLocalRandomSeed變量
    UNSAFE.putLong(t = Thread.currentThread(), SEED,
                   r = UNSAFE.getLong(t, SEED) + GAMMA);
    return r;
}

這種Unsafe的方法掉地能有多快呢，讓我們一起看做個試驗看看：

這里，我們自己寫一個ThreadTest類，使用反射和unsafe兩種方法，來不停讀寫threadLocalRandomSeed成員變量，比較它們的性能差異，代碼如下：

上述代碼中，分別使用反射方式byReflection() 和Unsafe的方式byUnsafe()來讀寫threadLocalRandomSeed變量1億次，得到的測試結果如下：

byUnsafe spend :171ms
byReflection spend :645ms

不難看到，使用Unsafe的方法遠遠優于反射的方法，這也是JDK內部，大量使用Unsafe來替代反射的原因之一。

隨機數種子

我們知道，偽隨機數生成都需要一個種子，threadLocalRandomSeed和threadLocalRandomSecondarySeed就是這里的種子。其中threadLocalRandomSeed是long型的，threadLocalRandomSecondarySeed是int。

threadLocalRandomSeed是使用最廣泛的大量的隨機數其實都是基于threadLocalRandomSeed的。而threadLocalRandomSecondarySeed只是某些特定的JDK內部實現中有使用，使用并不廣泛。

初始種子默認使用的是系統時間：

上述代碼中完成了種子的初始化，并將初始化的種子通過UNSAFE存在SEED的位置（即threadLocalRandomSeed）。

接著就可以使用nextInt()方法獲得隨機整數了：

public int nextInt() {
    return mix32(nextSeed());
}    
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;
}

每一次調用nextInt()都會使用nextSeed()更新threadLocalRandomSeed。由于這是一個線程獨有的變量，因此完全不會有競爭，也不會有CAS的重試，性能也就大大提高了。

探針Probe的作用

除了種子外，還有一個threadLocalRandomProbe探針變量，這個變量是用來做什么的呢？

我們可以把threadLocalRandomProbe 理解為一個針對每個Thread的Hash值（不為0），它可以用來作為一個線程的特征值，基于這個值可以為線程在數組中找到一個特定的位置。

static final int getProbe() {
    return UNSAFE.getInt(Thread.currentThread(), PROBE);
}

來看一個代碼片段：

CounterCell[] as; long b, s;
if ((as = counterCells) != null ||
    !U.compareAndSwapLong(this, BASECOUNT, b = baseCount, s = b + x)) {
    CounterCell a; long v; int m;
    boolean uncontended = true;
    if (as == null || (m = as.length - 1) < 0 ||
        // 使用probe，為每個線程找到一個在數組as中的位置
        // 由于每個線程的probe值不一樣，因此大概率 每個線程對應的數組中的元素也是不一樣的
        // 每個線程對應了不同的元素，就可以沒有沖突的進行完全的并發操作
        // 因此探針probe在這里 就起到了防止沖突的作用
        (a = as[ThreadLocalRandom.getProbe() & m]) == null ||
        !(uncontended =
          U.compareAndSwapLong(a, CELLVALUE, v = a.value, v + x))) {

在具體的實現中，如果上述代碼發生了沖突，那么，還可以使用ThreadLocalRandom.advanceProbe()方法來修改一個線程的探針值，這樣可以進一步避免未來可能得沖突，從而減少競爭，提高并發性能。

static final int advanceProbe(int probe) {
    //根據當前探針值，計算一個更新的探針值
    probe ^= probe << 13;   // xorshift
    probe ^= probe >>> 17;
    probe ^= probe << 5;
    //更新探針值到線程對象中 即修改了threadLocalRandomProbe變量
    UNSAFE.putInt(Thread.currentThread(), PROBE, probe);
    return probe;
}

以上就是“java高并發情況下如何高效生成隨機數”這篇文章的所有內容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，小編每天都會為大家更新不同的知識，如果還想學習更多的知識，請關注億速云行業資訊頻道。