ThreadLocalRandom 安全嗎？

前言

最近在寫一些業務代碼時遇到一個須要產生隨機數的場景，這時天然想到 jdk 包裏的 Random 類。但出於對性能的極致追求，就考慮使用 ThreadLocalRandom 類進行優化，在查看 ThreadLocalRandom 實現的過程當中，又追了下 Unsafe 有部分代碼，整個流程下來，學到了很多東西，也經過搜索和提問解決了不少疑惑，因而總結成本文。java

Random 的性能問題

使用 Random 類時，爲了不重複建立的開銷，咱們通常將實例化好的 Random 對象設置爲咱們所使用服務對象的屬性或靜態屬性，這在線程競爭不激烈的狀況下沒有問題，但在一個高併發的 web 服務內，使用同一個 Random 對象可能會致使線程阻塞。web

Random 的隨機原理是對一個」隨機種子」進行固定的算術和位運算，獲得隨機結果，再使用這個結果做爲下一次隨機的種子。在解決線程安全問題時，Random 使用 CAS 更新下一次隨機的種子，能夠想到，若是多個線程同時使用這個對象，就確定會有一些線程執行 CAS 連續失敗，進而致使線程阻塞。數組

ThreadLocalRandom

jdk 的開發者天然考慮到了這個問題，在 concurrent 包內添加了 ThreadLocalRandom 類，第一次看到這個類名，我覺得它是經過 ThreadLocal 實現的，進而想到恐怖的內存泄漏問題，但點進源碼卻沒有 ThreadLocal 的影子，而是存在着大量 Unsafe 相關的代碼。安全

咱們來看一下它的核心代碼：併發

UNSAFE.putLong(t = Thread.currentThread(), SEED, r = UNSAFE.getLong(t, SEED) + GAMMA);
複製代碼

翻譯成更直觀的 Java 代碼就像：dom

Thread t = Thread.currentThread();
long r = UNSAFE.getLong(t, SEED) + GAMMA;
UNSAFE.putLong(t, SEED, r);
複製代碼

看上去很是眼熟，像咱們日常往 Map 裏 get/set 同樣，以 Thread.currentThread() 獲取到的當前對象裏 key，以 SEED 隨機種子做爲 value。高併發

可是以對象做爲 key 是可能會形成內存泄漏的啊，因爲 Thread 對象可能會大量建立，在回收時不 remove Map 裏的 value 時會致使 Map 愈來愈大，最後內存溢出。工具

Unsafe

功能

不過再仔細看 ThreadLocalRandom 類的核心代碼，發現並非簡單的 Map 操做，它的 getLong() 方法須要傳入兩個參數，而 putLong() 方法須要三個參數，查看源碼發現它們都是 native 方法，咱們看不到具體的實現。兩個方法簽名分別是：佈局

public native long getLong(Object var1, long var2);
public native void putLong(Object var1, long var2, long var4);
複製代碼

雖然看不到具體實現，但咱們能夠查獲得它們的功能，下面是兩個方法的功能介紹：性能

putLong(object, offset, value) 能夠將 object 對象內存地址偏移 offset 後的位置後四個字節設置爲 value。
getLong(object, offset) 會從 object 對象內存地址偏移 offset 後的位置讀取四個字節做爲 long 型返回。

不安全性

做爲 Unsafe 類內的方法，它也透露着一股「Unsafe」的氣息，具體表現就是能夠直接操做內存，而不作任何安全校驗，若是有問題，則會在運行時拋出 Fatal Error，致使整個虛擬機的退出。

在咱們的常識裏，get 方法是最容易拋異常的地方，好比空指針、類型轉換等，但 Unsafe.getLong() 方法是個很是安全的方法，它從某個內存位置開始讀取四個字節，而無論這四個字節是什麼內容，總能成功轉成 long 型，至於這個 long 型結果是否是跟業務匹配就是另外一回事了。而 set 方法也是比較安全的，它把某個內存位置以後的四個字節覆蓋成一個 long 型的值，也幾乎不會出錯。

那麼這兩個方法」不安全」在哪呢？

它們的不安全並非在這兩個方法執行期間報錯，而是未經保護地改變內存，會引發別的方法在使用這一段內存時報錯。

public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException {
        // Unsafe 設置了構造方法私有，getUnsafe 獲取實例方法包私有，在包外只能經過反射獲取
        Field field = Unsafe.class.getDeclaredField("theUnsafe"); 
        field.setAccessible(true);
        Unsafe unsafe = (Unsafe) field.get(null);
        // Test 類是一個隨手寫的測試類，只有一個 String 類型的測試類
        Test test = new Test();
        test.ttt = "12345";
        unsafe.putLong(test, 12L, 2333L);
        System.out.println(test.value);
    }
複製代碼

運行上面的代碼會獲得一個 fatal error，報錯信息爲「A fatal error has been detected by the Java Runtime Environment: … Process finished with exit code 134 (interrupted by signal 6: SIGABRT)」。

能夠從報錯信息中看到虛擬機由於這個 fatal error abort 退出了，緣由也很簡單，我使用 unsafe 將 Test 類 value 屬性的位置設置成了 long 型值 2333，而當我使用 value 屬性時，虛擬機會將這一塊內存解析爲 String 對象，原 String 對象對象頭的結構被打亂了，解析對象失敗拋出了錯誤，更嚴重的問題是報錯信息中沒有類名行號等信息，在複雜項目中排查這種問題真如同大海撈針。

不過 Unsafe 的其餘方法可不必定像這一對方法同樣，使用他們時可能須要注意另外的安全問題，以後有遇到再說。

ThreadLocalRandom 的實現

那麼 ThreadLocalRandom 是否是安全的呢，再回過頭來看一下它的實現。

ThreadLocalRandom 的實現須要 Thread 對象的配合，在 Thread 對象內存在着一個屬性 threadLocalRandomSeed，它保存着這個線程專屬的隨機種子，而這個屬性在 Thread 對象的 offset，是在 ThreadLocalRandom 類加載時就肯定了的，具體方法是 SEED = UNSAFE.objectFieldOffset(Thread.class.getDeclaredField("threadLocalRandomSeed"));

咱們知道一個對象所佔用的內存大小在類被加載後就肯定了的，因此使用 Unsafe.objectFieldOffset(class, fieldName) 能夠獲取到某個屬性在類中偏移量，而在找對了偏移量，又能肯定數據類型時，使用 ThreadLocalRandom 就是很安全的。

疑問

在查找這些問題的過程當中，我也產生了兩個疑問點。

使用場景

首先就是 ThreadLocalRandom 爲何非要使用 Unsafe 來修改 Thread 對象內的隨機種子呢，在 Thread 對象內添加 get/set 方法不是更方便嗎？

stackOverFlow 上有人跟我一樣的疑問，why is threadlocalrandom implemented so bizarrely，被採納的答案裏解釋說，對 jdk 開發者來講 Unsafe 和 get/set 方法都像普通的工具，具體使用哪個並無一個準則。這個答案並無說服我，因而我另開了一個問題，裏面的一個評論我比較認同，大意是 ThreadLocalRandom 和 Thread 不在同一個包下，若是添加 get/set 方法的話，get/set 方法必須設置爲 public，這就有違了類的封閉性原則。

內存佈局

另外一個疑問是我看到 Unsafe.objectFieldOffset 能夠獲取到屬性在對象內存的偏移量後，本身在 IDEA 裏使用 main 方法試了上文中提到的 Test 類，發現 Test 類的惟一一個屬性 value 相對對象內存的偏移量是 12，因而比較疑惑這 12 個字節的組成。

咱們知道，Java 對象的對象頭是放在 Java 對象的內存起始處的，而一個對象的 MarkWord 在對象頭的起始處，在 32 位系統中，它佔用 4 個字節，而在 64 位系統中它佔用 8 個字節，我使用的是 64 位系統，這毫無疑問會佔用 8 個字節的偏移量。

緊跟 MarkWord 的應該是 Test 類的類指針和數組對象的長度，數組長度是 4 字節，但 Test 類並不是數組，也沒有其餘屬性，數據長度能夠排除，但在 64 位系統下指針也應該是 8 字節的啊，爲何只佔用了 4 個字節呢？

惟一的可能性是虛擬機啓用了指針壓縮，指針壓縮只能在 64 位系統內啓用，啓用後指針類型只須要佔用 4 個字節，但我並無顯示指定過使用指針壓縮。查了一下，原來在 1.8 之後指針壓縮是默認開啓的，在啓用時使用 -XX:-UseCompressedOops 參數後，value 的偏移量變成了 16。

小結

在寫代碼時仍是要多注意查看依賴庫的具體實現，否則可能踩到意想不到的坑，並且多看看並無壞處，仔細研究一下還能學到更多。

看完三件事❤️

若是你以爲這篇內容對你還蠻有幫助，我想邀請你幫我三個小忙：

點贊，轉發，有大家的『點贊和評論』，纔是我創造的動力。
關注公衆號『 java爛豬皮 』，不按期分享原創知識。
同時能夠期待後續文章ing🚀

本文轉自：枕邊書的博客，做者：枕邊書