關於Java線程的5個使用技巧

蘿蔔白菜各有所愛。像我就喜歡Java。學無止境,這也是我喜歡它的一個原因。日常工作中你所用到的工具,通常都有些你從來沒有了解過的東西,比方說某個方法或者是一些有趣的用法。比如說線程。沒錯,就是線程。或者確切說是Thread這個類。當我們在構建高可擴展性系統的時候,通常會面臨各種各樣的併發編程的問題,不過我們現在所要講的可能會略有不同。

關於Java線程的5個使用技巧
Java線程的5個使用技巧

從本文中你將會看到線程提供的一些不太常用的方法及技術。不管你是初學者還是高級用戶或者是Java專家,希望都能看一下哪些是你已經知道的,而哪些是剛瞭解的。

  初學者 1、線程名

程序中的每個線程都有一個名字,創建線程的時候會給它分配一個簡單的Java字符串來作爲線程名。默認的名字是”Thread-0″, “Thread-1″, “Thread-2″等等。現在有趣的事情來了——Thread提供了兩種方式來設置線程名:

線程構造函數,下面是最簡單的一個實現:

class SuchThread extends Thread {

Public void run() {

tln ("Hi Mom! " + getName());

}

}

SuchThread wow = new SuchThread("much-name");

線程名setter方法:

ame(“Just another thread name”);

沒錯,線程名是可變的。因此我們可以在運行時修改它的名字,而不用在初始化的時候就指定好。name字段其實就是一個簡單的字符串對象。也就是說它能達到231-1個字符那麼長(_VALUE)。這足夠用了。注意這個名字並不是一個唯一性的標識,因此不同的線程也可以擁有同樣的線程名。還有一點就是,不要把null用作線程名,否則會拋出異常(當然了,”null”還是可以的)。

使用線程名來調試問題

既然可以設置線程名,那麼如果遵循一定的命名規則的話,出了問題的時候排查起來就能更容易一些。“Thread-6″這樣的名字看起來就太沒心沒肺了,肯定有比它更好的名字。在處理用戶請求的時候,可以將事務ID追加到線程名後面,這樣能顯著減少你排查問題的時間。

“pool-1-thread-1″ #17 prio=5 os_prio=31 tid=0x00007f9d620c9800

nid=0x6d03 in () [0x000000013ebcc000]

“pool-1-thread-1″,這也太嚴肅了吧。我們來看下這是什麼情況,給它起一個好點的名字:

entThread()ame(Context + TID + Params + current Time, ...);

現在我們再來運行下jstack,情況便豁然開朗了:

”Queue Processing Thread, MessageID: AB5CAD, type:

AnalyzeGraph, queue: ACTIVE_PROD, Transaction_ID: 5678956,

Start Time: 30/12/2014 17:37″ #17 prio=5 os_prio=31 tid=0x00007f9d620c9800

nid=0x6d03 in () [0x000000013ebcc000]

如果我們能知道線程在做什麼,這樣當它出問題的時候,至少可以拿到事務ID來開始排查。你可以回溯這個問題,復現它,然後定位問題並搞定它。。

  2、線程優先級

線程還有一個有意思的屬性就是它的優先級。線程的優先級介於1 (MINPRIORITY)到10 (MAXPRIORITY)之間,主線程默認是5(NORM_PRIORITY)。每個新線程都默認繼承父線程的優先級,因此如果你沒有設置過的話,所有線程的優先級都是5。這個是通常被忽視的屬性,我們可以通過getPriority()與setPriority()方法來獲取及修改它的值。線程的構造函數裏是沒有這個功能的。

什麼地方會用到優先級?

當然並不是所有的線程都是平等的,有的線程需要立即引起CPU的重視,而有些線程則只是後臺任務而已。優先級就是用來把這些告訴給操作系統的線程調度器的。在Takipi中,這是我們開發的一錯誤跟蹤及排查的工具,負責處理用戶異常的線程的優先級是MAX_PRIORITY,而那些只是在上報新的部署情況的線程,它們的優先級就要低一些。你可能會覺得優先級高的線程從JVM的線程調度器那得到的時間會多一些。但其實並都是這樣的。

在操作系統層面,每一個新線程都會對應一個本地線程,你所設置的Java線程的優先級會被轉化成本地線程的優先級,這個在各個平臺上是不一樣的。在Linux上,你可以打開“-XX:+UseThreadPriorities”選項來啓用這項功能。正如前面所說的,線程優先級只是你所提供的'一個建議。和Linux本地的優先級相比,Java線程的優先級並不能覆蓋全所有的級別(Linux共有1到99個優先級,線程的優先級在是-20到20之間)。最大的好處就是你所設定的優先級能在每個線程獲得的CPU時間上有所體現,不過完全依賴於線程優先級的做法是不推薦的。

  進階篇 3.線程本地存儲

這個和前面提到的兩個略有不同。ThreadLocal是在Thread類之外實現的一個功能(adLocal),但它會爲每個線程分別存儲一份唯一的數據。正如它的名字所說的,它爲線程提供了本地存儲,也就是說你所創建出來變量對每個線程實例來說都是唯一的。和線程名,線程優先級類似,你可以自定義出一些屬性,就好像它們是存儲在Thread線程內部一樣,是不是覺得酷?不過先別高興得太早了,有幾句醜話得先說在前頭。

創建ThreadLocal有兩種推薦方式:要麼是靜態變量,要麼是單例實例中的屬性,這樣可以是非靜態的。注意,它的作用域是全局的,只不過對訪問它的線程而言好像是本地的而已。在下面這個例子中,ThreadLocal裏面存儲了一個數據結構,這樣我們可以很容易地訪問到它:

public static class CriticalData

{

public int transactionId;

public int username;

}

public static final ThreadLocalglobalData =

new ThreadLocal();

一旦獲取到了ThreadLocal對象,就可以通過 ()和()方法來對它進行操作了。

全局變量?這不是什麼好事

也盡然。ThreadLocal可以用來存儲事務ID。如果代碼中出現未捕獲異常的時候它就相當有用了。最佳實踐是設置一個UncaughtExceptionHandler,這個是Thread類本身就支持的,但是你得自己去實現一下這個接口。一旦執行到了UncaughtExceptionHandler裏,就幾乎沒有任何線索能夠知道到底發生了什麼事情了。這會兒你能獲取到的就只有Thread對象,之前導致異常發生的所有變量都無法再訪問了,因爲那些棧幀都已經被彈出了。一旦到了UncaughtExceptionHandler裏,這個線程就只剩下最後一口氣了,唯一能抓住的最後一根稻草就是ThreadLocal。

我們來試下這麼做:

tln("Transaction ID " + ()sactionId);

我們可以將一些與錯誤相關的有價值的上下文信息給存儲到裏面添。ThreadLocal還有一個更有創意的用法,就是用它來分配一塊特定的內存,這樣工作線程可以把它當作緩存來不停地使用。當然了,這有沒有用得看你在CPU和內存之間是怎麼權衡的了。沒錯,ThreadLocal需要注意的就是會造成內存空間的浪費。只要線程還活着,那麼它就會一直存在,除非你主動釋放否則它是不會被回收的。因此如果使用它的話你最好注意一下,儘量保持簡單。

 4. 用戶線程及守護線程

我們再回到Thread類。程序中的每個線程都會有一個狀態,要麼是用戶狀態,要麼是守護狀態。換句話說,要麼是前臺線程要麼是後臺線程。主線程默認是用戶線程,每個新線程都會從創建它的線程中繼承線程狀態。因此如果你把一個線程設置成守護線程,那麼它所創建的所有線程都會被標記成守護線程。如果程序中的所有線程都是守護線程的話,那麼這個進程便會終止。我們可以通過Boolean aemon(true)和emon()方法來查看及設置線程狀態。

什麼時候會用到守護線程?

如果進程不必等到某個線程結束才能終止,那麼這個線程就可以設置成守護線程。這省掉了正常關閉線程的那些麻煩事,可以立即將線程結束掉。換個角度來說,如果一個正在執行某個操作的線程必須要正確地關閉掉否則就會出現不好的後果的話,那麼這個線程就應該是用戶線程。通常都是些關鍵的事務,比方說,數據庫錄入或者更新,這些操作都是不能中斷的。

  專家級 5. 處理器親和性(Processor Affinity)

這裏要講的會更靠近硬件,也就是說,當軟件遇上了硬件。處理器親和性使得你能夠將線程或者進程綁定到特定的CPU核上。這意味着只要是某個特定的線程,它就肯定只會在某個特定的CPU核上執行。通常來講如何綁定是由操作系統的線程調度器根據它自己的邏輯來決定的,它很可能會將我們前面提到的線程優先級也一併考慮進來。

這麼做的好處在於CPU緩存。如果某個線程只會在某個核上運行,那麼它的數據恰好在緩存裏的概率就大大提高了。如果數據正好就在CPU緩存裏,那麼就沒有必要重新再從內存里加載了。你所節省的這幾毫秒時間就能用在刀刃上,在這段時間裏代碼可以馬上開始執行,也就能更好地利用所分配給它的CPU時間。當然了,操作系統層面可能會存在某種優化,硬件架構當然也是個很重要的因素,但利用了處理器的親和性至少能夠減小線程切換CPU的機率。

由於這裏摻雜着多種因素,處理器親和性到底對吞吐量有多大的影響,最好還是通過測試的方式來進行證明。也許這個方法並不是總能顯著地提升性能,但至少有一個好處就是吞吐量會相對穩定。親和策略可以細化到非常細的粒度上,這取決於你具體想要什麼。高頻交易行業便是這一策略最能大顯身手的場景之一。

處理器親和性的測試

Java對處理器的親和性並沒有原生的支持,當然了,故事也還沒有就此結束。在Linux上,我們可以通過taskset命令來設置進程的親和性。假設我們現在有一個Java進程在運行,而我們希望將它綁定到某個特定的CPU上:

taskset -c 1 “java AboutToBePinned”

如果是一個已經在運行了的進程:

taskset -c 1

要想深入到線程級別還得再加些代碼才行。所幸的是,有一個開源庫能完成這樣的功能:Java-Thread-Affinity。這個庫是由OpenHFT的Peter Lawrey開發的,實現這一功能最簡單直接的方式應該就是使用這個庫了。我們通過一個例子來快速看下如何綁定某個線程,關於該庫的更多細節請參考它在Github上的文檔:

AffinityLock al = ireLock();

這樣就可以了。關於獲取鎖的一些更高級的選項——比如說根據不同的策略來選擇CPU——在Github上都有詳細的說明。