從線程間通信看到的關於基本類型封包的問題

本文描述了在某種特殊場景下JDK編譯器對Java的基本類型的封包操作。

其原理非常簡單，但是現象卻非常非常的迷惑人。可以讓我們從另外一個角度看待JDK對基本類型的封包。

本文代碼的原意是想找到一種當未來超時後，可以盡量快的終止掉還在運行的未來（事實上，未來超時後（在主線程拋出超時異常後），未來的線程並不會停止，直到它運行結束，自然消亡。）

先上代碼：

主函數：

再看TestThread類：

最後是輔助豆

猜猜列印的結果是啥？

注意紅色和藍色部分。

變數ISC1的值：假

變數ISC1通過的ThreadLocal的獲取的值：假

變數ISC2的值：假

變數ISC2通過的ThreadLocal的獲取的值：假

變數ISC3的值：thread.InteruptTest.RichBoolean@5740bb

變數ISC3通過的ThreadLocal的獲取的值：thread.InteruptTest.RichBoolean@5740bb

1

變數ISC1的值：假

變數ISC1通過ThreadLocal的獲取的值：假

變數ISC2的值：假

變數ISC2通過ThreadLocal的獲取的值：假

變數ISC3的值：thread .InteruptTest.RichBoolean @ 5740bb

變數ISC3通過ThreadLocal的獲取的值：thread.InteruptTest.RichBoolean@5740bb

2

變數ISC1的值：假

變數ISC1通過ThreadLocal的獲取的值：假

變數ISC2的值：假

變數ISC2通過ThreadLocal的獲取的值：假

變數ISC3的值：thread.InteruptTest.RichBoolean@5740bb

變數ISC3通過ThreadLocal的獲取的值：thread.InteruptTest.RichBoolean@5740bb

3

變數ISC1的值：假

變數ISC1通過ThreadLocal的獲取的值：假

變數ISC2的值：假

變數ISC2通過的ThreadLocal的獲取的值：假

變數ISC3 值：thread.InteruptTest.RichBoolean@5740bb

變數ISC3通過ThreadLocal的獲取值：thread.InteruptTest.RichBoolean@5740bb

4

變數ISC1的值：假

變數ISC1通過ThreadLocal的獲取的值：假

變數ISC2的值：假

變數ISC2通過ThreadLocal的獲取值：假

超時拉

變數ISC3的值：thread.InteruptTest.RichBoolean@5740bb

變數ISC3通過ThreadLocal中獲取的值：thread.InteruptTest.RichBoolean@5740bb

5

變數ISC1的值：真正的

變數ISC1通過ThreadLocal中獲取的值：假

變數ISC2的值：真正的

變數ISC2通過ThreadLocal中獲取的值：假

變數ISC3的值：thread.InteruptTest.RichBoolean@5740bb

變數ISC3通過ThreadLocal中獲取的值：thread.InteruptTest.RichBoolean @ 5740bb

6

變數ISC1的值：真正的

變數isC1通過ThreadLocal獲取的值：false

變數isC2的值：true

變數isC2通過ThreadLocal獲取的值：false

變數isC3的值：thread.InteruptTest.RichBoolean@5740bb

變數isC3通過ThreadLocal獲取的值：thread.InteruptTest.RichBoolean@574 0bb

想想為什麼ISC1，ISC2中，未來自身的變數變為了真實而他們對應的ThreadLocal中的中的值卻還是假???????

難道是線程之間不能使用這種方式訪問同一個變數？

那為什麼ISC3又是和我們想想的一樣的？

其實仔細推導後發現原理非常簡單

看看 DivideFuture.class

內層的紅色框中說明，我們取消時是將ISC2的變數重新賦值了，也就是說ISC2指向了一個新的對象而thISC2裡面還是老的值，所以他們列印出來的結果不同。

同理，ISC1 =真正的這句話因為jdk的封包操作的原因類似ISC2也是重新新增了一個對象，ISC1指向了新對象，而thISC1中還是老對象。現象雖小，追逐根源的過程，才是我們成長的來源。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！