摘要：此時(shí)線程和會(huì)再有一個(gè)線程能夠獲取寫鎖，假設(shè)是，如果不采用再次驗(yàn)證的方式，此時(shí)會(huì)再次查詢數(shù)據(jù)庫。而實(shí)際上線程已經(jīng)把緩存的值設(shè)置好了，完全沒有必要再次查詢數(shù)據(jù)庫。
大家知道了Java中使用管程同步原語,理論上可以解決所有的并發(fā)問題。那 Java SDK 并發(fā)包里為什么還有很多其他的工具類呢？原因很簡單：分場景優(yōu)化性能，提升易用性
今天我們就介紹一種非常普遍的并發(fā)場景：讀多寫少場景。實(shí)際工作中，為了優(yōu)化性能，我們經(jīng)常會(huì)使用緩存，例如緩存元數(shù)據(jù)、緩存基礎(chǔ)數(shù)據(jù)等，這就是一種典型的讀多寫少應(yīng)用場景。緩存之所以能提升性能，一個(gè)重要的條件就是緩存的數(shù)據(jù)一定是讀多寫少的.
針對讀多寫少這種并發(fā)場景，Java SDK 并發(fā)包提供了讀寫鎖——ReadWriteLock，非常容易使用，并且性能很好。
什么是讀寫鎖
讀寫鎖，并不是 Java 語言特有的，而是一個(gè)廣為使用的通用技術(shù)，所有的讀寫鎖都遵守以下三條基本原則：
允許多個(gè)線程同時(shí)讀共享變量；
只允許一個(gè)線程寫共享變量；
如果一個(gè)寫線程正在執(zhí)行寫操作，此時(shí)禁止讀線程讀共享變量。
讀寫鎖與互斥鎖的一個(gè)重要區(qū)別就是讀寫鎖允許多個(gè)線程同時(shí)讀共享變量，而互斥鎖是不允許的，這是讀寫鎖在讀多寫少場景下性能優(yōu)于互斥鎖的關(guān)鍵。但讀寫鎖的寫操作是互斥的，當(dāng)一個(gè)線程在寫共享變量的時(shí)候，是不允許其他線程執(zhí)行讀操作和寫操作的。
快速實(shí)現(xiàn)一個(gè)緩存
在下面的代碼中，我們聲明了一個(gè) Cache 類，其中類型參數(shù) K 代表緩存里 key 的類型，V 代表緩存里 value 的類型。緩存的數(shù)據(jù)保存在 Cache 類內(nèi)部的 HashMap 里面，HashMap 不是線程安全的，這里我們使用讀寫鎖 ReadWriteLock 來保證其線程安全。ReadWriteLock 是一個(gè)接口，它的實(shí)現(xiàn)類是 ReentrantReadWriteLock，通過名字你應(yīng)該就能判斷出來，它是支持可重入的。下面我們通過 rwl 創(chuàng)建了一把讀鎖和一把寫鎖。
Cache 這個(gè)工具類，我們提供了兩個(gè)方法，一個(gè)是讀緩存方法 get()，另一個(gè)是寫緩存方法 put()。讀緩存需要用到讀鎖，讀鎖的使用和前面我們介紹的 Lock 的使用是相同的，都是 try{}finally{}這個(gè)編程范式。寫緩存則需要用到寫鎖，寫鎖的使用和讀鎖是類似的。
class Cache {
final Map m =
new HashMap<>();
final ReadWriteLock rwl =
new ReentrantReadWriteLock();
// 讀鎖
final Lock r = rwl.readLock();
// 寫鎖
final Lock w = rwl.writeLock();
// 讀緩存
V get(K key) {
r.lock();
try { return m.get(key); }
finally { r.unlock(); }
}
// 寫緩存
V put(String key, Data v) {
w.lock();
try { return m.put(key, v); }
finally { w.unlock(); }
}
}
實(shí)現(xiàn)緩存的按需加載
設(shè)計(jì)封裝緩存類時(shí)，我們需要在當(dāng)應(yīng)用查詢緩存，并且數(shù)據(jù)不在緩存里的時(shí)候，觸發(fā)加載源頭相關(guān)數(shù)據(jù)進(jìn)緩存的操作，這也是我們需要實(shí)現(xiàn)的最基本的功能。下面看下利用 ReadWriteLock 來實(shí)現(xiàn)緩存的按需加載。
這里我們假設(shè)緩存的源頭是數(shù)據(jù)庫。需要注意的是，如果緩存中沒有緩存目標(biāo)對象，那么就需要從數(shù)據(jù)庫中加載，然后寫入緩存，寫緩存需要用到寫鎖，所以在代碼中的⑤處，我們調(diào)用了w.lock() 來獲取寫鎖。
另外，還需要注意的是，在獲取寫鎖之后，我們并沒有直接去查詢數(shù)據(jù)庫，而是在代碼⑥⑦處，重新驗(yàn)證了一次緩存中是否存在，再次驗(yàn)證如果還是不存在，我們才去查詢數(shù)據(jù)庫并更新本地緩存。為什么我們要再次驗(yàn)證呢？
class Cache {
final Map m =
new HashMap<>();
final ReadWriteLock rwl =
new ReentrantReadWriteLock();
final Lock r = rwl.readLock();
final Lock w = rwl.writeLock();
V get(K key) {
V v = null;
// 讀緩存
r.lock(); ①
try {
v = m.get(key); ②
} finally{
r.unlock(); ③
}
// 緩存中存在，返回
if(v != null) { ④
return v;
}
// 緩存中不存在，查詢數(shù)據(jù)庫
w.lock(); ⑤
try {
// 再次驗(yàn)證
// 其他線程可能已經(jīng)查詢過數(shù)據(jù)庫
v = m.get(key); ⑥
if(v == null){ ⑦
// 查詢數(shù)據(jù)庫
v= 省略代碼無數(shù)
m.put(key, v);
}
} finally{
w.unlock();
}
return v;
}
}
原因是在高并發(fā)的場景下，有可能會(huì)有多線程競爭寫鎖。假設(shè)緩存是空的，沒有緩存任何東西，如果此時(shí)有三個(gè)線程 T1、T2 和 T3 同時(shí)調(diào)用 get() 方法，并且參數(shù) key 也是相同的。那么它們會(huì)同時(shí)執(zhí)行到代碼⑤處，但此時(shí)只有一個(gè)線程能夠獲得寫鎖，假設(shè)是線程 T1，線程 T1 獲取寫鎖之后查詢數(shù)據(jù)庫并更新緩存，最終釋放寫鎖。此時(shí)線程 T2 和 T3 會(huì)再有一個(gè)線程能夠獲取寫鎖，假設(shè)是 T2，如果不采用再次驗(yàn)證的方式，此時(shí) T2 會(huì)再次查詢數(shù)據(jù)庫。T2 釋放寫鎖之后，T3 也會(huì)再次查詢一次數(shù)據(jù)庫。而實(shí)際上線程 T1 已經(jīng)把緩存的值設(shè)置好了，T2、T3 完全沒有必要再次查詢數(shù)據(jù)庫。所以，再次驗(yàn)證的方式，能夠避免高并發(fā)場景下重復(fù)查詢數(shù)據(jù)的問題。
讀寫鎖的升級
上面按需加載的示例代碼中，在①處獲取讀鎖，在③處釋放讀鎖，那是否可以在②處的下面增加驗(yàn)證緩存并更新緩存的邏輯呢？詳細(xì)的代碼如下。
// 讀緩存
r.lock(); ①
try {
v = m.get(key); ②
if (v == null) {
w.lock();
try {
// 再次驗(yàn)證并更新緩存
// 省略詳細(xì)代碼
} finally{
w.unlock();
}
}
} finally{
r.unlock(); ③
}
這樣看上去好像是沒有問題的，先是獲取讀鎖，然后再升級為寫鎖，對此還有個(gè)專業(yè)的名字，叫鎖的升級?？上?ReadWriteLock 并不支持這種升級。在上面的代碼示例中，讀鎖還沒有釋放，此時(shí)獲取寫鎖，會(huì)導(dǎo)致寫鎖永久等待，最終導(dǎo)致相關(guān)線程都被阻塞，永遠(yuǎn)也沒有機(jī)會(huì)被喚醒。
小結(jié)
讀寫鎖類似于 ReentrantLock，也支持公平模式和非公平模式。讀鎖和寫鎖都實(shí)現(xiàn)了 java.util.concurrent.locks.Lock 接口，所以除了支持 lock() 方法外，tryLock()、lockInterruptibly() 等方法也都是支持的。但是有一點(diǎn)需要注意，那就是只有寫鎖支持條件變量，讀鎖是不支持條件變量的，讀鎖調(diào)用 newCondition() 會(huì)拋出 UnsupportedOperationException 異常。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/77659.html
