點選“終碼一生”，關注，置頂公眾號

每日技術乾貨，第一時間送達！

1、背景

最近在寫一些業務程式碼時遇到一個需要產生隨機數的場景，這時自然想到 jdk 包裡的 Random 類。但出於對效能的極致追求，就考慮使用 ThreadLocalRandom 類進行優化，在檢視 ThreadLocalRandom 實現的過程中，又追了下 Unsafe 有部分程式碼，整個流程下來，學到了不少東西，也通過搜尋和提問解決了很多疑惑，於是總結成本文。

Random 的效能問題

使用 Random 類時，為了避免重複建立的開銷，我們一般將例項化好的 Random 物件設定為我們所使用服務物件的屬性或靜態屬性，這線上程競爭不激烈的情況下沒有問題，但在一個高併發的 web 服務內，使用同一個 Random 物件可能會導致執行緒阻塞。

Random 的隨機原理是對一個”隨機種子”進行固定的算術和位運算，得到隨機結果，再使用這個結果作為下一次隨機的種子。在解決執行緒安全問題時，Random 使用 CAS 更新下一次隨機的種子，可以想到，如果多個執行緒同時使用這個物件，就肯定會有一些執行緒執行 CAS 連續失敗，進而導致執行緒阻塞。

ThreadLocalRandom

jdk 的開發者自然考慮到了這個問題，在 concurrent 包內添加了 ThreadLocalRandom 類，第一次看到這個類名，我以為它是通過 ThreadLocal 實現的，進而想到恐怖的記憶體洩漏問題，但點進原始碼卻沒有 ThreadLocal 的影子，而是存在著大量 Unsafe 相關的程式碼。

另外，關注公號“終碼一生”，回覆關鍵詞“資料”，獲取視訊教程和最新的面試資料！

我們來看一下它的核心程式碼：

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

翻譯成更直觀的 Java 程式碼就像：

Thread t = Thread.currentThread();
longr = UNSAFE.getLong(t, SEED) + GAMMA;
UNSAFE.putLong(t, SEED, r);

看上去非常眼熟，像我們平常往 Map 裡 get/set 一樣，以 Thread.currentThread() 獲取到的當前物件裡 key，以 SEED 隨機種子作為 value。

但是以物件作為 key 是可能會造成記憶體洩漏的啊，由於 Thread 物件可能會大量建立，在回收時不 remove Map 裡的 value 時會導致 Map 越來越大，最後記憶體溢位。

2、Unsafe

功能

不過再仔細看 ThreadLocalRandom 類的核心程式碼，發現並不是簡單的 Map 操作，它的 getLong() 方法需要傳入兩個引數，而 putLong() 方法需要三個引數，檢視原始碼發現它們都是 native 方法，我們看不到具體的實現。兩個方法簽名分別是：

publicnativelonggetLong(Object var1,longvar2);
publicnativevoidputLong(Object var1,longvar2,longvar4);

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

• putLong(object, offset, value) 可以將 object 物件記憶體地址偏移 offset 後的位置後四個位元組設定為 value。

• getLong(object, offset) 會從 object 物件記憶體地址偏移 offset 後的位置讀取四個位元組作為 long 型返回。

不安全性

作為 Unsafe 類內的方法，它也透露著一股 “Unsafe” 的氣息，具體表現就是可以直接操作記憶體，而不做任何安全校驗，如果有問題，則會在執行時丟擲 Fatal Error，導致整個虛擬機器的退出。

在我們的常識裡，get 方法是最容易拋異常的地方，比如空指標、型別轉換等，但 Unsafe.getLong() 方法是個非常安全的方法，它從某個記憶體位置開始讀取四個位元組，而不管這四個位元組是什麼內容，總能成功轉成 long 型，至於這個 long 型結果是不是跟業務匹配就是另一回事了。而 set 方法也是比較安全的，它把某個記憶體位置之後的四個位元組覆蓋成一個 long 型的值，也幾乎不會出錯。

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

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

publicstaticvoidmain(String[] args) throws NoSuchFieldException, IllegalAccessException{
// Unsafe 設定了構造方法私有，getUnsafe 獲取例項方法包私有，在包外只能通過反射獲取
Field field = Unsafe.class.getDeclaredField("theUnsafe");
field.setAccessible(true);
Unsafeunsafe= (Unsafe) field.get(null);

// Test 類是一個隨手寫的測試類，只有一個 String 型別的測試類
Test test =newTest();
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 就是很安全的。

3、疑問

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

使用場景

首先就是 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。

4、小結

在寫程式碼時還是要多注意檢視依賴庫的具體實現，不然可能踩到意想不到的坑，而且多看看並沒有壞處，仔細研究一下還能學到更多。

PS：防止找不到本篇文章，可以收藏點贊，方便翻閱查詢哦