這些線程安全的坑，你在工作中踩了么？
點擊關(guān)注公眾號，Java干貨及時送達(dá)
我們知道多線程能并發(fā)的處理多個任務(wù)，有效地提高復(fù)雜應(yīng)用程序的性能，在實際開發(fā)中扮演著十分重要的角色
但是使用多線程也帶來了很多風(fēng)險，并且由線程引起的問題往往在測試中難以發(fā)現(xiàn)，到了線上就會造成重大的故障和損失
下面我會結(jié)合幾個實際案例，幫助大家在工作做規(guī)避這些問題
多線程問題
首先介紹下使用的多線程會有哪些問題
使用多線程的問題很大程度上源于多個線程對同一變量的操作權(quán)，以及不同線程之間執(zhí)行順序的不確定性
《Java并發(fā)編程實戰(zhàn)》這本書中提到了三種多線程的問題：安全性問題、活躍性問題和性能問題
安全性問題
例如有一段很簡單的扣庫存功能操作，如下：
public int decrement(){
return --count;//count初始庫存為10
}
在單線程環(huán)境下，這個方法能正確工作，但在多線程環(huán)境下，就會導(dǎo)致錯誤的結(jié)果
--count看上去是一個操作，但實際上它包含三步（讀取-修改-寫入）：
讀取count的值 將值減一 最后把計算結(jié)果賦值給count
如下圖展示了一種錯誤的執(zhí)行過程，當(dāng)有兩個線程1、2同時執(zhí)行該方法時，它們讀取到count的值都是10，最后返回結(jié)果都是9；意味著可能有兩個人購買了商品，但庫存卻只減了1，這對于真實的生產(chǎn)環(huán)境是不可接受的
像上面例子這樣由于不恰當(dāng)?shù)膱?zhí)行時序?qū)е虏徽_結(jié)果的情況，是一種很常見的并發(fā)安全問題，被稱為競態(tài)條件
decrement()方法這個導(dǎo)致發(fā)生競態(tài)條件的代碼區(qū)被稱為臨界區(qū)
避免這種問題，需要保證讀取-修改-寫入這樣復(fù)合操作的原子性
在Java中，有很多方式可以實現(xiàn)，比如使用synchronize內(nèi)置鎖或ReentrantLock顯式鎖的加鎖機制、使用線程安全的原子類、以及采用CAS的方式等
活躍性問題
活躍性問題指的是，某個操作因為阻塞或循環(huán)，無法繼續(xù)執(zhí)行下去
最典型的有三種，分別為死鎖、活鎖和饑餓
死鎖
最常見的活躍性問題是死鎖
死鎖是指多個線程之間相互等待獲取對方的鎖，又不會釋放自己占有的鎖，而導(dǎo)致阻塞使得這些線程無法運行下去就是死鎖，它往往是不正確的使用加鎖機制以及線程間執(zhí)行順序的不可預(yù)料性引起的
如何預(yù)防死鎖
1.盡量保證加鎖順序是一樣的
例如有A,B,C三把鎖。
Thread 1的加鎖順序為A、B、C這樣的。
Thread 2的加鎖順序為A、C，這樣就不會死鎖。
如果Thread2的加鎖順序為B、A或者C、A這樣順序就不一致了，就會出現(xiàn)死鎖問題。
2.盡量用超時放棄機制
Lock接口提供了tryLock(long time, TimeUnit unit)方法，該方法可以按照固定時長等待鎖，因此線程可以在獲取鎖超時以后，主動釋放之前已經(jīng)獲得的所有的鎖?？梢员苊馑梨i問題
活鎖
活鎖與死鎖非常相似，也是程序一直等不到結(jié)果，但對比于死鎖，活鎖是活的，什么意思呢？因為正在運行的線程并沒有阻塞，它始終在運行中，卻一直得不到結(jié)果
饑餓
饑餓是指線程需要某些資源時始終得不到，尤其是CPU 資源，就會導(dǎo)致線程一直不能運行而產(chǎn)生的問題。
在 Java 中有線程優(yōu)先級的概念，Java 中優(yōu)先級分為 1 到 10，1 最低，10 最高。
如果我們把某個線程的優(yōu)先級設(shè)置為 1，這是最低的優(yōu)先級，在這種情況下，這個線程就有可能始終分配不到 CPU 資源，而導(dǎo)致長時間無法運行。
性能問題
線程本身的創(chuàng)建、以及線程之間的切換都要消耗資源，如果頻繁的創(chuàng)建線程或者CPU在線程調(diào)度花費的時間遠(yuǎn)大于線程運行的時間，使用線程反而得不償失，甚至造成CPU負(fù)載過高或者OOM的后果
舉例說明
線程不安全類
案例1
使用線程不安全集合（ArrayList、HashMap等）要進行同步，最好使用線程安全的并發(fā)集合
在多線程環(huán)境下，對線程不安全的集合遍歷進行操作時，可能會拋出ConcurrentModificationException的異常，也就是常說的fail-fast機制
下面例子模擬了多個線程同時對ArrayList操作，線程t1遍歷list并打印，線程t2向list添加元素
List<Integer> list = new ArrayList<>();
list.add(0);
list.add(1);
list.add(2); //list: [0,1,2]
System.out.println(list);
//線程t1遍歷打印list
Thread t1 = new Thread(() -> {
for(int i : list){
System.out.println(i);
}
});
//線程t2向list添加元素
Thread t2 = new Thread(() -> {
for(int i = 3; i < 6; i++){
list.add(i);
}
});
t1.start();
t2.start();
進到拋異常的ArrayList源碼中，可以看到遍歷ArrayList是通過內(nèi)部實現(xiàn)的迭代器完成的
調(diào)用迭代器的next()方法獲取下一個元素時，會先通過checkForComodification()方法檢查modCount和expectedModCount是否相等，若不相等則拋出ConcurrentModificationException
modCount是ArrayList的屬性，表示集合結(jié)構(gòu)被修改的次數(shù)（列表長度發(fā)生變化的次數(shù)），每次調(diào)用add或remove等方法都會使modCount加1
expectedModCount是迭代器的屬性，在迭代器實例創(chuàng)建時被賦與和遍歷前modCount相等的值（expectedModCount=modCount）
所以當(dāng)有其他線程添加或刪除集合元素時，modCount會增加，然后集合遍歷時expectedModCount不等于modCount，就會拋出異常
使用加鎖機制操作線程不安全的集合類
List<Integer> list = new ArrayList<>();
list.add(0);
list.add(1);
list.add(2);
System.out.println(list);
//線程t1遍歷打印list
Thread t1 = new Thread(() -> {
synchronized (list){ //使用synchronized關(guān)鍵字
for(int i : list){
System.out.println(i);
}
}
});
//線程t2向list添加元素
Thread t2 = new Thread(() -> {
synchronized (list){
for(int i = 3; i < 6; i++){
list.add(i);
System.out.println(list);
}
}
});
t1.start();
t2.start();
如上面代碼，用synchronized關(guān)鍵字鎖住對list的操作，就不會拋出異常。不過用synchronized相當(dāng)于把鎖住的代碼塊串行化，性能上是不占優(yōu)勢的
推薦使用線程安全的并發(fā)工具類
JDK1.5加入了很多線程安全的工具類供使用，如CopyOnWriteArrayList、ConcurrentHashMap等并發(fā)容器
日常開發(fā)中推薦使用這些工具類來實現(xiàn)多線程編程
案例2
不要將SimpleDateFormat作為全局變量使用
SimpleDateFormat實際上是一個線程不安全的類，其根本原因是SimpleDateFormat的內(nèi)部實現(xiàn)對一些共享變量的操作沒有進行同步
public static final SimpleDateFormat SDF_FORMAT = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
public static void main(String[] args) {
//兩個線程同時調(diào)用SimpleDateFormat.parse方法
Thread t1 = new Thread(() -> {
try {
Date date1 = SDF_FORMAT.parse("2019-12-09 17:04:32");
} catch (ParseException e) {
e.printStackTrace();
}
});
Thread t2 = new Thread(() -> {
try {
Date date2 = SDF_FORMAT.parse("2019-12-09 17:43:32");
} catch (ParseException e) {
e.printStackTrace();
}
});
t1.start();
t2.start();
}
建議將SimpleDateFormat作為局部變量使用，或者配合ThreadLocal使用
最簡單的做法是將SimpleDateFormat作為局部變量使用即可
但如果是在for循環(huán)中使用，會創(chuàng)建很多實例，可以優(yōu)化下配合ThreadLocal使用
//初始化
public static final ThreadLocal<SimpleDateFormat> SDF_FORMAT = new ThreadLocal<SimpleDateFormat>(){
@Override
protected SimpleDateFormat initialValue() {
return new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
}
};
//調(diào)用
Date date = SDF_FORMAT.get().parse(wedDate);
推薦使用Java8的LocalDateTime和DateTimeFormatter
LocalDateTime和DateTimeFormatter是Java 8引入的新特性，它們不僅是線程安全的，而且使用更方便
推薦在實際開發(fā)中用LocalDateTime和DateTimeFormatter替代Calendar和SimpleDateFormat
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");
LocalDateTime time = LocalDateTime.now();
System.out.println(formatter.format(time));
鎖的正確釋放
假設(shè)有這樣一段偽代碼：
Lock lock = new ReentrantLock();
...
try{
lock.tryLock(timeout, TimeUnit.MILLISECONDS)
//業(yè)務(wù)邏輯
}
catch (Exception e){
//錯誤日志
//拋出異?；蛑苯臃祷?/span>
}
finally {
//業(yè)務(wù)邏輯
lock.unlock();
}
...
這段代碼中在finally代碼塊釋放鎖之前，執(zhí)行了一段業(yè)務(wù)邏輯
假如不巧這段邏輯中依賴服務(wù)不可用導(dǎo)致占用鎖的線程不能成功釋放鎖，會造成其他線程因無法獲取鎖而阻塞，最終線程池被打滿的問題
所以在釋放鎖之前；finally子句中應(yīng)該只有對當(dāng)前線程占有的資源(如鎖、IO流等)進行釋放的一些處理
還有就是獲取鎖時設(shè)置合理的超時時間
為了避免線程因獲取不到鎖而一直阻塞，可以設(shè)置一個超時時間，當(dāng)獲取鎖超時后，線程可以拋出異常或返回一個錯誤的狀態(tài)碼。其中超時時間的設(shè)置也要合理，不應(yīng)過長，并且應(yīng)該大于鎖住的業(yè)務(wù)邏輯的執(zhí)行時間。
正確使用線程池
案例1
不要將線程池作為局部變量使用
public void request(List<Id> ids) {
for (int i = 0; i < ids.size(); i++) {
ExecutorService threadPool = Executors.newSingleThreadExecutor();
}
}
在for循環(huán)中創(chuàng)建線程池，那么每次執(zhí)行該方法時，入?yún)⒌膌ist長度有多大就會創(chuàng)建多少個線程池，并且方法執(zhí)行完后也沒有及時調(diào)用shutdown()方法將線程池銷毀
這樣的話，隨著不斷有請求進來，線程池占用的內(nèi)存會越來越多，就會導(dǎo)致頻繁fullGC甚至OOM。每次方法調(diào)用都創(chuàng)建線程池是很不合理的，因為這和自己頻繁創(chuàng)建、銷毀線程沒有區(qū)別，不僅沒有利用線程池的優(yōu)勢，反而還會耗費線程池所需的更多資源
所以盡量將線程池作為全局變量使用
案例2
謹(jǐn)慎使用默認(rèn)的線程池靜態(tài)方法
Executors.newFixedThreadPool(int); //創(chuàng)建固定容量大小的線程池
Executors.newSingleThreadExecutor(); //創(chuàng)建容量為1的線程池
Executors.newCachedThreadPool(); //創(chuàng)建一個線程池，線程池容量大小為Integer.MAX_VALUE
上述三個默認(rèn)線程池的風(fēng)險點：
newFixedThreadPool創(chuàng)建的線程池corePoolSize和maximumPoolSize值是相等的，使用的阻塞隊列是LinkedBlockingQueue。
newSingleThreadExecutor將corePoolSize和maximumPoolSize都設(shè)置為1，也使用的LinkedBlockingQueue
LinkedBlockingQueue默認(rèn)容量為Integer.MAX_VALUE=2147483647，對于真正的機器來說，可以被認(rèn)為是無界隊列
newFixedThreadPool和newSingleThreadExecutor在運行的線程數(shù)超過corePoolSize時，后來的請求會都被放到阻塞隊列中等待，因為阻塞隊列設(shè)置的過大，后來請求不能快速失敗而長時間阻塞，就可能造成請求端的線程池被打滿，拖垮整個服務(wù)。
newCachedThreadPool將corePoolSize設(shè)置為0，將maximumPoolSize設(shè)置為Integer.MAX_VALUE，阻塞隊列使用的SynchronousQueue，SynchronousQueue不會保存等待執(zhí)行的任務(wù)
所以newCachedThreadPool是來了任務(wù)就創(chuàng)建線程運行，而maximumPoolSize相當(dāng)于無限的設(shè)置，使得創(chuàng)建的線程數(shù)可能會將機器內(nèi)存占滿。
所以需要根據(jù)自身業(yè)務(wù)和硬件配置創(chuàng)建自定義線程池
線程數(shù)建議
線程池corePoolSize數(shù)量設(shè)置建議：
1.CPU密集型應(yīng)用
CPU密集的意思是任務(wù)需要進行大量復(fù)雜的運算，幾乎沒有阻塞，需要CPU長時間高速運行。
一般公式：corePoolSize=CPU核數(shù)+1個線程。JVM可運行的CPU核數(shù)可以通過Runtime.getRuntime().availableProcessors()查看。
2.IO密集型應(yīng)用
IO密集型任務(wù)會涉及到很多的磁盤讀寫或網(wǎng)絡(luò)傳輸，線程花費更多的時間在IO阻塞上，而不是CPU運算。一般的業(yè)務(wù)應(yīng)用都屬于IO密集型。
參考公式：最佳線程數(shù)=CPU數(shù)/(1-阻塞系數(shù)); 阻塞系數(shù)=線程等待時間/(線程等待時間+CPU處理時間) 。
IO密集型任務(wù)的CPU處理時間往往遠(yuǎn)小于線程等待時間，所以阻塞系數(shù)一般認(rèn)為在0.8-0.9之間，以4核單槽CPU為例，corePoolSize可設(shè)置為 4/(1-0.9)=40。當(dāng)然具體的設(shè)置還是要根據(jù)機器實際運行中的各項指標(biāo)而定
參考書籍：Java并發(fā)編程實戰(zhàn)
關(guān)注Java技術(shù)?？锤喔韶?/strong>
