跳到主要內容

Java併發編程(05):悲觀鎖和樂觀鎖機制

本文源碼:GitHub·點這裏 || GitEE·點這裏


一、資源和加鎖


1、場景描述


多線程併發訪問同一個資源問題,假如線程A獲取變量之後修改變量值,線程C在此時也獲取變量值並且修改,兩個線程同時併發處理一個變量,就會導致併發問題。



這種并行處理數據庫的情況在實際的業務開發中很常見,兩個線程先後修改數據庫的值,導致數據有問題,該問題復現的概率不大,處理的時候需要對整個模塊體系有概念,才能容易定位問題。


2、演示案例


public class LockThread01 {
public static void main(String[] args) {
CountAdd countAdd = new CountAdd() ;
AddThread01 addThread01 = new AddThread01(countAdd) ;
addThread01.start();
AddThread02 varThread02 = new AddThread02(countAdd) ;
varThread02.start();
}
}
class AddThread01 extends Thread {
private CountAdd countAdd ;
public AddThread01 (CountAdd countAdd){
this.countAdd = countAdd ;
}
@Override
public void run() {
countAdd.countAdd(30);
}
}
class AddThread02 extends Thread {
private CountAdd countAdd ;
public AddThread02 (CountAdd countAdd){
this.countAdd = countAdd ;
}
@Override
public void run() {
countAdd.countAdd(10);
}
}
class CountAdd {
private Integer count = 0 ;
public void countAdd (Integer num){
try {
if (num == 30){
count = count + 50 ;
Thread.sleep(3000);
} else {
count = count + num ;
}
System.out.println("num="+num+";count="+count);
} catch (Exception e){
e.printStackTrace();
}
}
}

這裏案例演示多線程併發修改count值,導致和預期不一致的結果,這是多線程併發下最常見的問題,尤其是在併發更新數據時。


出現併發的情況時,就需要通過一定的方式或策略來控制在併發情況下數據讀寫的準確性,這被稱為併發控制,實現併發控制手段也很多,最常見的方式是資源加鎖,還有一種簡單的實現策略:修改數據前讀取數據,修改的時候加入限制條件,保證修改的內容在此期間沒有被修改。


二、鎖的概念簡介


1、鎖機制簡介


併發編程中一個最關鍵的問題,多線程併發處理同一個資源,防止資源使用的衝突一個關鍵解決方法,就是在資源上加鎖:多線程序列化訪問。鎖是用來控制多個線程訪問共享資源的方式,鎖機制能夠讓共享資源在任意給定時刻只有一個線程任務訪問,實現線程任務的同步互斥,這是最理想但性能最差的方式,共享讀鎖的機制允許多任務併發訪問資源。


2、悲觀鎖


悲觀鎖,總是假設每次每次被讀取的數據會被修改,所以要給讀取的數據加鎖,具有強烈的資源獨佔和排他特性,在整個數據處理過程中,將數據處於鎖定狀態,例如synchronized關鍵字的實現就是悲觀機制。



悲觀鎖的實現,往往依靠數據庫提供的鎖機制,只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性,否則,即使在本系統中實現了加鎖機制,也無法保證外部系統不會修改數據,悲觀鎖主要分為共享讀鎖和排他寫鎖。


排他鎖基本機制:又稱寫鎖,允許獲取排他鎖的事務更新數據,阻止其他事務取得相同的資源的共享讀鎖和排他鎖。若事務T對數據對象A加上寫鎖,事務T可以讀A也可以修改A,其他事務不能再對A加任何鎖,直到T釋放A上的寫鎖。


3、樂觀鎖


樂觀鎖相對悲觀鎖而言,採用更加寬鬆的加鎖機制。悲觀鎖大多數情況下依靠數據庫的鎖機制實現,以保證操作最大程度的獨佔性。但隨之而來的就是數據庫性能的大量開銷,特別是對長事務的開銷非常的占資源,樂觀鎖機制在一定程度上解決了這個問題。



樂觀鎖大多是基於數據版本記錄機制實現,為數據增加一個版本標識,在基於數據庫表的版本解決方案中,一般是通過為數據庫表增加一個version字段來實現。讀取出數據時,將此版本號一同讀出,之後更新時,對此版本號加一。此時,將提交數據的版本數據與數據庫表對應記錄的當前版本信息進行比對,如果提交的數據版本號等於數據庫表當前版本號,則予以更新,否則認為是過期數據。樂觀鎖機制在高併發場景下,可能會導致大量更新失敗的操作。


樂觀鎖的實現是策略層面的實現:CAS(Compare-And-Swap)。當多個線程嘗試使用CAS同時更新同一個變量時,只有其中一個線程能成功更新變量的值,而其它線程都失敗,失敗的線程並不會被掛起,而是被告知這次競爭中失敗,並可以再次嘗試。


4、機制對比


悲觀鎖本身的實現機制就以損失性能為代價,多線程爭搶,加鎖、釋放鎖會導致比較多的上下文切換和調度延時,加鎖的機制會產生額外的開銷,還有增加產生死鎖的概率,引發性能問題。


樂觀鎖雖然會基於對比檢測的手段判斷更新的數據是否有變化,但是不確定數據是否變化完成,例如線程1讀取的數據是A1,但是線程2操作A1的值變化為A2,然後再次變化為A1,這樣線程1的任務是沒有感知的。


悲觀鎖每一次數據修改都要上鎖,效率低,寫數據失敗的概率比較低,比較適合用在寫多讀少場景。


樂觀鎖並未真正加鎖,效率高,寫數據失敗的概率比較高,容易發生業務形異常,比較適合用在讀多寫少場景。


是選擇犧牲性能,還是追求效率,要根據業務場景判斷,這種選擇需要依賴經驗判斷,不過隨着技術迭代,數據庫的效率提升,集群模式的出現,性能和效率還是可以兩全的。


三、Lock基礎案例


1、Lock方法說明


lock:執行一次獲取鎖,獲取后立即返回;


lockInterruptibly:在獲取鎖的過程中可以中斷;


tryLock:嘗試非阻塞獲取鎖,可以設置超時時間,如果獲取成功返回true,有利於線程的狀態監控;


unlock:釋放鎖,清理線程狀態;


newCondition:獲取等待通知組件,和當前鎖綁定;


2、應用案例


import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
public class LockThread02 {
public static void main(String[] args) {
LockNum lockNum = new LockNum() ;
LockThread lockThread1 = new LockThread(lockNum,"TH1");
LockThread lockThread2 = new LockThread(lockNum,"TH2");
LockThread lockThread3 = new LockThread(lockNum,"TH3");
lockThread1.start();
lockThread2.start();
lockThread3.start();
}
}
class LockNum {
private Lock lock = new ReentrantLock() ;
public void getNum (){
lock.lock();
try {
for (int i = 0 ; i < 3 ; i++){
System.out.println("ThreadName:"+Thread.currentThread().getName()+";i="+i);
}
} finally {
lock.unlock();
}
}
}
class LockThread extends Thread {
private LockNum lockNum ;
public LockThread (LockNum lockNum,String name){
this.lockNum = lockNum ;
super.setName(name);
}
@Override
public void run() {
lockNum.getNum();
}
}

這裏多線程基於Lock鎖機制,分別依次執行任務,這是Lock的基礎用法,各種API的詳解,下次再說。


3、與synchronized對比


基於synchronized實現的鎖機制,安全性很高,但是一旦線程失敗,直接拋出異常,沒有清理線程狀態的機會。顯式的使用Lock語法,可以在finally語句中最終釋放鎖,維護相對正常的線程狀態,在獲取鎖的過程中,可以嘗試獲取,或者嘗試獲取鎖一段時間。


四、源代碼地址


GitHub·地址
https://github.com/cicadasmile/java-base-parent
GitEE·地址
https://gitee.com/cicadasmile/java-base-parent


推薦閱讀:Java基礎系列



































序號 文章標題
A01 Java基礎:基本數據類型,核心點整理
A02 Java基礎:特殊的String類,和相關擴展API
B01 Java併發:線程的創建方式,狀態周期管理
B02 Java併發:線程核心機制,基礎概念擴展
B03 Java併發:多線程併發訪問,同步控制
B04 Java併發:線程間通信,等待/通知機制
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】



※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能



※台北網頁設計公司這麼多該如何選擇?



※智慧手機時代的來臨,RWD網頁設計為架站首選



※評比南投搬家公司費用收費行情懶人包大公開



※回頭車貨運收費標準



Orignal From: Java併發編程(05):悲觀鎖和樂觀鎖機制

留言

這個網誌中的熱門文章

TOYOTA將與FirstElement合作建立加氣站

據AUTONET報導,TOYOTA將與能源公司FirstElement攜手合作加氫站網絡的架設,預計2015-2016年能夠建成20多處的加氣站,並能在2024年實現擴建至100座的計畫。 TOYOTA於2013年底東京車展發表準量產版的FCV Concept,此後又藉由年初的2014 CES消費電子展預告2015年將率先投入北美市場販售,因此對於加氫站等後勤網絡的建設排上日程。 其實在過去的20年來,TOYOTA就已持續針對氫燃料電池進行研發,自2002年以來便投入一系列的測試車輛於北美進行實測,隨著技術的突破,使得氫燃料電池技術成本大幅下修,終於達到原廠量產的預期。 儘管FCV(氫燃料電池車)最終量產版本的相關數據原廠尚未公開,但參考FCV Concept所呈現的數據就相當令人滿意。 動力來源為分別藏在車身底下的氫燃料儲存槽及電池,具備等同於136hp馬力的100kW輸出功率,需花費10秒才能完成100km/h的加速衝刺,滿電的情況下續航力約可達到482km,而且僅需3-5分鐘的時間便能將儲存槽加滿,省去了傳統電池充電耗時的問題。 重點是氫燃料電池是以氫或含氫物質結合氧所形成的一種燃料電池,在化學反應之後僅會產生電流及水且完全沒有污染。 動力來源為分別藏在車身底下的氫燃料儲存槽及電池(圖片來源:AUTONET) 本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理 【其他文章推薦】 ※ 新北清潔 公司,居家、辦公、裝潢細清專業服務 ※別再煩惱 如何寫文案 ,掌握八大原則! ※ 網頁設計 一頭霧水該從何著手呢? 台北網頁設計 公司幫您輕鬆架站! ※超省錢 租車 方案 ※教你寫出一流的 銷售文案 ? Orignal From: TOYOTA將與FirstElement合作建立加氣站

有了四步解題法模板,再也不害怕動態規劃!(看不懂算我輸)

導言 動態規劃問題一直是算法面試當中的重點和難點,並且動態規劃這種通過空間換取時間的算法思想在實際的工作中也會被頻繁用到,這篇文章的目的主要是解釋清楚 什麼是動態規劃 ,還有就是面對一道動態規劃問題,一般的 思考步驟 以及其中的注意事項等等,最後通過幾道題目將理論和實踐結合。 什麼是動態規劃 如果你還沒有聽說過動態規劃,或者僅僅只有耳聞,或許你可以看看 Quora 上面的這個 回答 。 How to explain dynamic 用一句話解釋動態規劃就是 " 記住你之前做過的事 ",如果更準確些,其實是 " 記住你之前得到的答案 "。 我舉個大家工作中經常遇到的例子。 在軟件開發中,大家經常會遇到一些系統配置的問題,配置不對,系統就會報錯,這個時候一般都會去 Google 或者是查閱相關的文檔,花了一定的時間將配置修改好。 過了一段時間,去到另一個系統,遇到類似的問題,這個時候已經記不清之前修改過的配置文件長什麼樣,這個時候有兩種方案,一種方案還是去 Google 或者查閱文檔,另一種方案是借鑒之前修改過的配置,第一種做法其實是萬金油,因為你遇到的任何問題其實都可以去 Google,去查閱相關文件找答案,但是這會花費一定的時間,相比之下,第二種方案肯定會更加地節約時間,但是這個方案是有條件的,條件如下: 之前的問題和當前的問題有着關聯性,換句話說,之前問題得到的答案可以幫助解決當前問題 需要記錄之前問題的答案 當然在這個例子中,可以看到的是,上面這兩個條件均滿足,大可去到之前配置過的文件中,將配置拷貝過來,然後做些細微的調整即可解決當前問題,節約了大量的時間。 不知道你是否從這些描述中發現,對於一個動態規劃問題,我們只需要從兩個方面考慮,那就是 找出問題之間的聯繫 ,以及 記錄答案 ,這裏的難點其實是找出問題之間的聯繫,記錄答案只是順帶的事情,利用一些簡單的數據結構就可以做到。 概念 上面的解釋如果大家可以理解的話,接    動態規劃 算法是通過拆分問題,定義問題狀態和狀態之間的關係,使得問題能夠以遞推(或者說分治)的方式去解決。它的幾個重要概念如下所述。    階段: 對於一個完整的問題過程,適當的切分為若干個相互聯繫的子問題,每次在求解一個子問題...

數據資產的玄學、顯學

數據就是資產,這個道理在商業領域並不難懂。 比如國外有聚焦金融數據的彭博,國內也有萬德,早期靠着人工錄入、整理數據的方式,聚集了龐大的數據庫,成為投資公司的必備;而聚焦學術文獻等知識數據的知網,不僅舒舒服服賺差價,還能涉嫌壟斷被處罰。 但數據資產這個理念,在全社會得到認可,也非一蹴而就,而是一波一波的普及、深化。 2011年,麥肯錫發布報告,認為"大數據Big Data已成為當今競爭、創新、生產效率提升的關鍵基礎"。一時間,大數據,成為業內熱點。數據,大家都懂;大,有什麼區別? 聚焦大數據的創業公司紛紛成立,時任美國總統的奧巴馬也在2012年3月宣布了"大數據研究與發展先導計劃",雖然投資額僅2億美元,但有評論認為這和上世紀90年代的信息公路計劃相媲美。 而不管大的是什麼,至少一個確定的趨勢是,數據資產,越來越值錢。 這股科技新風也來到中國。本着"懂不懂先不說,有新趨勢就先干"的大A,也漸漸熱鬧起來。比如擁有消費者購買記錄的百貨公司,雖然還處於電商取代線下的衰退趨勢中,但投資者還是興奮地給了"估值重構"的機會,2013年7月份,也曾有過股價快速漲一倍的戰績。 而最"得勢"的當屬銀之傑,公司通過收購億美軟通,為企業向用戶發送短信,每年發送量超過100億條。每一條短信,在投資人眼裡,都是金燦燦的"數據資產"。再疊加科技牛市buff,銀之傑受到投資者的狂熱追捧。從2012年底起,兩年半漲幅近100倍。一個字,絕。兩個字,瘋狂。 2015年4月,我國首家大數據交易所——貴陽大數據交易所成立,對數據資產的探索,又邁出了關鍵一步。成立當天就完成了第一筆數據交易,交易所管理層也雄心勃勃,提出在3~5年內將日交易額推到100億元的規模。 蜂擁而至的故事,結局似乎都差不多。2016年,Gartner在報告中警告:許多公司正打算削減大數據項目投入。 百貨行業沒有避開電商的衝擊,業績也沒有被數據資產改善;而短信等數據,也讓投資人清醒,有的數據是資產,有的只是01代碼,或者只是投資人情緒的載體。而在大數據領域創業的公司,也有一些融了FGH輪之後,不得不賣服務器來改善現金流。而貴陽大數據中心也在2022年8月,才實現了數據交易規模...