synchronized,ReentrantLock,Atomic 使用場景描述
在實際開發過程中如果服務量，請求頻繁，就會經常碰見并發，這時候不做處理就會出現很多非法數據。這時候就需要解決線程安全的問題，這時候就可以使用java當中的鎖機制。常用有java關鍵synchronized、可重入鎖ReentrantLock，還有并發包下的Atomic 或者Concurrent的安全類型。
synchronized使用場景：
在資源競爭不是很激烈的情況下，偶爾出現并發，需要同步的情形下，synchronized是很合適的。原因在于，編譯程序通常會盡可能的進行優化synchronized，另外可讀性非常好，不管用沒用過5.0多線程包的程序員都能理解。可以多對方法進行加鎖（同步方法），也可以對對象進行加鎖（同步代碼快）。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
/** * synchronized用id */private static volatile Long syncId=0L;/** * synchronized方式獲取id 同步方法 * @return */public static synchronized Long getSyncId1(){ syncId++; return syncId;}/** * synchronized方式獲取id 同步代碼塊 * @return */public static Long getSyncId2(){ synchronized (syncId){ syncId++; return syncId; }} |
代碼可讀性強，畢竟是java的關鍵字，執行優先級高。synchronized關鍵字一放，就解決線程安全的問題。
但是還有一個問題，當前資源競爭激烈時，對于部分線程遲遲獲取不到鎖，這時候會出現一個鎖升級的過程，且鎖升級的過程是不可逆的。當從輕量級鎖到偏向鎖，再到一個重量級鎖。性能會大大的降低。
在資源競爭激烈可以使用其他方式來加鎖。
ReentrantLock使用場景:
ReentrantLock提供了多樣化的同步，比如有時間限制的同步，可以被Interrupt的同步（synchronized的同步是不能Interrupt的）等。在資源競爭不激烈的情形下，性能稍微比synchronized差點點。但是當同步非常激烈的時候，synchronized的性能一下子能下降好幾十倍。而ReentrantLock還能保證正常的性能。
且這個鎖可以定義成公平鎖還可以定義成非公平鎖。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
/** * ReentrantLock用id */private static volatile Long lockId=0L;/** * ReentrantLock公平鎖 */private static final ReentrantLock reentrantLock = new ReentrantLock(true);/** * ReentrantLock方式獲取id * @return */public static Long getLockId(){ reentrantLock.lock(); try { lockId++; return lockId; }catch (Exception e){ e.printStackTrace(); return getLockId(); }finally { reentrantLock.unlock(); }} |
我這里以公平鎖作為演示對象。ReentrantLock還可以查看鎖的狀態, 鎖是否被鎖上了.
可以查看當前有多少線程再等待鎖。但是因為ReentrantLock是悲觀鎖，加鎖時會對資源進行加鎖，當讀取頻繁時性能會不如CAS的樂觀鎖。所以讀取頻繁使用樂觀鎖，寫入頻繁使用悲觀鎖。
Atomic或者Concurrent使用場景:
和上面的類似，不激烈情況下，性能比synchronized略遜，而激烈的時候，也能維持常態。激烈的時候，Atomic的性能會優于ReentrantLock一倍左右。但是其有一個缺點，就是只能同步一個值，一段代碼中只能出現一個Atomic的變量，多于一個同步無效。因為他不能在多個Atomic之間同步。
|
1
2
3
4
5
6
7
8
9
10
11
12
|
/** * Atomic用id */private static volatile AtomicLong atomicId=new AtomicLong(0L);/** * Atomic方式獲取id * @return */public static Long getAtomicId(){ return atomicId.addAndGet(1);} |
對于其他類型的比如和Map和Set可以使用用并發包下的ConcurrentHashMap和ConcurrentHashSet等線程安全的數據類型。
|
1
2
3
4
5
6
7
8
9
10
11
12
|
/** * 線程安全的hashMap */private static ConcurrentHashMap<String,String> hashMap = new ConcurrentHashMap<>();public static void put(String key,String value){ hashMap.put(key,value);}public static String get(String key{ return hashMap.get(key);} |
ConcurrentHashMap內部的實現是CAS的樂觀鎖，當鎖無法取得會開始自旋，直到下一次取得鎖。
到此這篇關于Java線程安全解決方案(synchronized,ReentrantLock,Atomic)的文章就介紹到這了,更多相關Java線程安全內容請搜索服務器之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持服務器之家！
原文鏈接：https://blog.csdn.net/qq_42271561/article/details/108809073
