我使出這“三板斧”(分段鎖、雜湊鎖、弱引用鎖)滅霸跑了......
有同學說,學了Java那麼多鎖,還是沒能鎖住滅霸,本文教你“三板斧”,鎖滅霸足矣。
據說,沒幾個人能真正參透這“三板斧”的精髓,你是不是那個有緣人呢?
最近,在工作上碰見了一些高併發的場景需要加鎖來保證業務邏輯的正確性,並且要求加鎖後效能不能受到太大的影響。初步的想法是通過資料的時間戳、id等關鍵字來加鎖,從而保證不同型別資料處理的併發性。而Java自身api提供的鎖粒度太大,很難同時滿足這些需求,於是自己動手寫了幾個簡單的擴充套件。。。
分段鎖
借鑑ConcurrentHashMap的分段思想,先生成一定數量的鎖,具體使用的時候再根據key來返回對應的lock。這是幾個實現裡最簡單,效能最高,也是最終被採用的鎖策略,程式碼如下:
- 分段鎖,系統提供一定數量的原始鎖,根據傳入物件的雜湊值獲取對應的鎖並加鎖
- 注意:要鎖的物件的雜湊值如果發生改變,有可能導致鎖無法成功釋放!!!
public class SegmentLock<T> { private Integer segments = 16;//預設分段數量 private final HashMap<Integer, ReentrantLock> lockMap = new HashMap<>(); public SegmentLock() { init(null, false); } public SegmentLock(Integer counts, boolean fair) { init(counts, fair); } private void init(Integer counts, boolean fair) { if (counts != null) { segments = counts; } for (int i = 0; i < segments; i++) { lockMap.put(i, new ReentrantLock(fair)); } } public void lock(T key) { ReentrantLock lock = lockMap.get((key.hashCode()>>>1) % segments); lock.lock(); } public void unlock(T key) { ReentrantLock lock = lockMap.get((key.hashCode()>>>1) % segments); lock.unlock(); } } 複製程式碼
雜湊鎖
上述分段鎖的基礎上發展起來的第二種鎖策略,目的是實現真正意義上的細粒度鎖。每個雜湊值不同的物件都能獲得自己獨立的鎖。在測試中,在被鎖住的程式碼執行速度飛快的情況下,效率比分段鎖慢 30% 左右。如果有長耗時操作,感覺表現應該會更好。程式碼如下:
public class HashLock<T> { private boolean isFair = false; private final SegmentLock<T> segmentLock = new SegmentLock<>();//分段鎖 private final ConcurrentHashMap<T, LockInfo> lockMap = new ConcurrentHashMap<>(); public HashLock() { } public HashLock(boolean fair) { isFair = fair; } public void lock(T key) { LockInfo lockInfo; segmentLock.lock(key); try { lockInfo = lockMap.get(key); if (lockInfo == null) { lockInfo = new LockInfo(isFair); lockMap.put(key, lockInfo); } else { lockInfo.count.incrementAndGet(); } } finally { segmentLock.unlock(key); } lockInfo.lock.lock(); } public void unlock(T key) { LockInfo lockInfo = lockMap.get(key); if (lockInfo.count.get() == 1) { segmentLock.lock(key); try { if (lockInfo.count.get() == 1) { lockMap.remove(key); } } finally { segmentLock.unlock(key); } } lockInfo.count.decrementAndGet(); lockInfo.unlock(); } private static class LockInfo { public ReentrantLock lock; public AtomicInteger count = new AtomicInteger(1); private LockInfo(boolean fair) { this.lock = new ReentrantLock(fair); } public void lock() { this.lock.lock(); } public void unlock() { this.lock.unlock(); } } } 複製程式碼
弱引用鎖
雜湊鎖因為引入的分段鎖來保證鎖建立和銷燬的同步,總感覺有點瑕疵,所以寫了第三個鎖來尋求更好的效能和更細粒度的鎖。這個鎖的思想是藉助java的弱引用來建立鎖,把鎖的銷燬交給jvm的垃圾回收,來避免額外的消耗。
有點遺憾的是因為使用了ConcurrentHashMap作為鎖的容器,所以沒能真正意義上的擺脫分段鎖。這個鎖的效能比 HashLock 快10% 左右。鎖程式碼:
- 弱引用鎖,為每個獨立的雜湊值提供獨立的鎖功能
public class WeakHashLock<T> {
private ConcurrentHashMap<T, WeakLockRef<T, ReentrantLock>> lockMap = new ConcurrentHashMap<>();
private ReferenceQueue<ReentrantLock> queue = new ReferenceQueue<>();
public ReentrantLock get(T key) {
if (lockMap.size() > 1000) {
clearEmptyRef();
}
WeakReference<ReentrantLock> lockRef = lockMap.get(key);
ReentrantLock lock = (lockRef == null ? null : lockRef.get());
while (lock == null) {
lockMap.putIfAbsent(key, new WeakLockRef<>(new ReentrantLock(), queue, key));
lockRef = lockMap.get(key);
lock = (lockRef == null ? null : lockRef.get());
if (lock != null) {
return lock;
}
clearEmptyRef();
}
return lock;
}
@SuppressWarnings("unchecked")
private void clearEmptyRef() {
Reference<? extends ReentrantLock> ref;
while ((ref = queue.poll()) != null) {
WeakLockRef<T, ? extends ReentrantLock> weakLockRef = (WeakLockRef<T, ? extends ReentrantLock>) ref;
lockMap.remove(weakLockRef.key);
}
}
private static final class WeakLockRef<T, K> extends WeakReference<K> {
final T key;
private WeakLockRef(K referent, ReferenceQueue<? super K> q, T key) {
super(referent, q);
this.key = key;
}
}
}
複製程式碼
後記
最開始想借助 LockSupport 和 AQS 來實現細粒度鎖,寫著寫著發現正在實現的東西和Java 原生的鎖區別不大,於是放棄改為對java自帶鎖的封裝,浪費了不少時間。
實際上在實現了這些細粒度鎖之後,又有了新的想法,比如可以通過分段思想將資料提交給專門的執行緒來處理,可以減少大量執行緒的阻塞時間,留給有緣人去探索。。。
END
如發現文章有錯誤、對內容有疑問,給我留言哦~
彩蛋小福利
部分資料如下:
相關推薦
我使出這“三板斧”(分段鎖、雜湊鎖、弱引用鎖)滅霸跑了......
有同學說,學了Java那麼多鎖,還是沒能鎖住滅霸,本文教你“三板斧”,鎖滅霸足矣。 據說,沒幾個人能真正參透這“三板斧”的精髓,
演算法導論 第十一章:散列表 筆記(直接定址表、散列表、通過連結法解決碰撞、雜湊函式、開放定址法、完全雜湊)
前面討論的各種資料結構中,記錄在各種結構中的相對位置是隨機的,和在記錄的關鍵字之間不存在有確定的關係,因此在查詢記錄是需要進行一系列和關鍵字的比較。而理想的情況是不希望進行任何的比較,一次存取便能得到所查記錄。那就必須在記錄的儲存位置和它的關鍵字之間建立一種確定的關係f,使每個關鍵字和結構中有一
手寫通用型別負載均衡路由引擎(含隨機、輪詢、雜湊等及其帶權形式)
本文記錄了通用型別負載均衡路由引擎(工廠)的實現過程和思路。通過路由引擎獲取指定列舉型別的負載均衡器,降低了程式碼耦合,規範了各個負載均衡器的使用,減少出錯的可能,並簡化了其對應帶權負載均衡的實現(提供預設實現),而無需另外編寫和整合。 文章目錄 一 使用
Android之玩轉MPAndroidChart讓(折線圖、柱形圖、餅狀圖、雜湊圖、雷達圖)優雅的舞動
package com.example.chenyu.mpandroidcharttest; import android.app.Fragment; import android.graphics.Color; import android.os.Bundle; import android.suppor
1002 寫出這個數 (20 分)
讀入一個正整數 n,計算其各位數字之和,用漢語拼音寫出和的每一位數字。 輸入格式: 每個測試輸入包含 1 個測試用例,即給出自然數 n 的值。這裡保證 n 小於 10 100 。 輸出格式: 在一行內輸出 n 的各位數字之和的每一位,拼音數字
PTA:1002 寫出這個數 (java)
package PTA; import java.util.ArrayList; import java.util.HashMap; import java.util.List; import java.util.Scanner; /* 1002 寫出這個數 (20 分) 讀入一個正整數 n,計算
1002 寫出這個數 (20 分)
讀入一個正整數 n,計算其各位數字之和,用漢語拼音寫出和的每一位數字。 輸入格式: 每個測試輸入包含 1 個測試用例,即給出自然數 n 的值。這裡保證 n 小於 10^100。 輸
PAT 1002 寫出這個數 (20 分)
PAT 1002 寫出這個數 (20 分) 讀入一個正整數 n,計算其各位數字之和,用漢語拼音寫出和的每一位數字。 輸入格式: 每個測試輸入包含 1 個測試用例,即給出自然數 n 的值。這裡保證 n 小於 10100。 輸出格式: 在一行內輸出 n 的各位數字
PAT-1002 寫出這個數 (20 分)
1002 寫出這個數 (20 分) 讀入一個正整數 n,計算其各位數字之和,用漢語拼音寫出和的每一位數字。 輸入格式: 每個測試輸入包含 1 個測試用例,即給出自然數 n 的值。這裡保證 n 小於 1
【《致青春》——雲夢澤】記住那些天, 我找出這素水漫出的青蓮; 像是山間的流水溫柔, 輕拍著心湖石岸卻流淌著歡快憂愁; 像是天空的白鳥掠過眼隙, 飛翔著心園幽夢而忘不記你年輕時的嬌羞。
記住那些天, 我找出這素水漫出的青蓮; 像是山間的流水溫柔, 輕拍著心湖石岸卻流淌著歡快憂愁; 像是天空的白鳥掠過眼隙, 飛翔著心園幽夢而忘不記你年輕時的嬌羞。...
(PAT乙級)1002 寫出這個數(C語言實現)
總結:1、關鍵點在於:求出和sum之後怎麼將其輸出成拼音的問題。這裡巧妙地運用了一個函式:sprintf(str,“%d”,num);即 和printf的使用時一樣的,只不過printf是將num輸出到螢幕上,sprintf將num列印
B1002 寫出這個數 (20 分)
讀入一個正整數 n,計算其各位數字之和,用漢語拼音寫出和的每一位數字。 輸入格式: 每個測試輸入包含 1 個測試用例,即給出自然數 n 的值。這裡保證 n 小於 10100。 輸出格式: 在一行內輸出 n&n
PAT乙級1002. 寫出這個數(C語言)
#include <stdio.h> #include <string.h> int main() { char num[101];//輸入的數字 < 10^{100},即數字的位數 < 101
1002 寫出這個數(C語言版 + 註釋 + 字串)
讀入一個正整數 n,計算其各位數字之和,用漢語拼音寫出和的每一位數字。 輸入格式: 每個測試輸入包含 1 個測試用例,即給出自然數 n 的值。這裡保證 n 小於 10100。 輸出格式: 在一行內輸出 n 的各位數字之和的每一位,拼音數字間有 1 空格,但一行中
1002 寫出這個數 (20 分)
else return stack ostream ack ber style ring num #include <iostream> #include <string> #include <stack> using name
為了控制Bean的載入我使出了這些殺手鐗
故事一: 絕代有佳人,幽居在空谷 美女同學小張,在工作中遇到了煩心事。心情那是破涼破涼的,無法言喻。 故事背景是最近由於需求變動,小張在專案中加入了MQ的整合,剛開始還沒什麼問題,後面慢慢問題的顯露出來了。 自己在本地Debug的時候總是能消費到訊息,由於歷史原因,公司的專案只區分了兩套環境,也就是測試和線上
我的時間日期類(自己寫的,以後會一直補充和改變)
package com.xing; import java.text.SimpleDateFormat; import java.util.Date; public class Mydate { private Date date; private Str
Android系統的智能指針(輕量級指針、強指針和弱指針)的實現原理分析【轉】
其中 sin 類的定義 reason ava tab eas file 現在 Android系統的運行時庫層代碼是用C++來編寫的,用C++ 來寫代碼最容易出錯的地方就是指針了,一旦使用不當,輕則造成內存泄漏,重則造成系統崩潰。不過系統為我們提供了智能指針,避免出現上述問題
搜尋:線性搜尋、二分搜尋、雜湊搜尋(雜湊還未完成)
題目: 請編寫一個程式,輸入包含n個整數的數列A以及包含q個不重複整數數列T,請輸出A和T的交集元素的個數 一、線性搜尋 #include "pch.h" #include <stdio.h> int search(int A[], int n, int key) { i
QMap QHash的選擇(QString這種複雜的比較,雜湊演算法比map快很多)
QMap QHash有近乎相同的功能。很多資料裡面介紹過他們之間的區別了。但是都沒有說明在使用中如何選擇他們。 實際上他們除了儲存順序的差別外,只有key操作的區別。 雜湊演算法是將包含較多資訊的“key”轉換成包含資訊較少的“key的key”。通過“key的key”查詢key,在通過key找到value