跳到主要內容

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)：悲觀鎖和樂觀鎖機制

留言

張貼留言

這個網誌中的熱門文章

架構設計 | 異步處理流程，多種實現模式詳解

本文源碼：GitHub·點這裏 || GitEE·點這裏 一、異步處理 1、異步概念 異步處理不用阻塞當前線程來等待處理完成，而是允許後續操作，直至其它線程將處理完成，並回調通知此線程。 必須強調一個基礎邏輯，異步是一種設計理念，異步操作不等於多線程，MQ中間件，或者消息廣播，這些是可以實現異步處理的方式。 同步處理和異步處理相對，需要實時處理並響應，一旦超過時間會結束會話，在該過程中調用方一直在等待響應方處理完成並返回。同步類似電話溝通，需要實時對話，異步則類似短信交流，發送消息之後無需保持等待狀態。 2、異步處理優點 雖然異步處理不能實時響應，但是處理複雜業務場景，多數情況都會使用異步處理。 異步可以解耦業務間的流程關聯，降低耦合度； 降低接口響應時間，例如用戶註冊，異步生成相關信息表； 異步可以提高系統性能，提升吞吐量； 流量削峰即把請求先承接下來，然後在異步處理； 異步用在不同服務間，可以隔離服務，避免雪崩； 異步處理的實現方式有很多種，常見多線程，消息中間件，發布訂閱的廣播模式，其根據邏輯在於先把請求承接下來，放入容器中，在從容器中把請求取出，統一調度處理。 注意 ：一定要監控任務是否產生積壓過度情況，任務如果積壓到雪崩之勢的地步，你會感覺每一片雪花都想勇闖天涯。 3、異步處理模式 異步流程處理的實現有好多方式，但是實際開發中常用的就那麼幾種，例如： 基於接口異步響應，常用在第三方對接流程； 基於消息生產和消費模式，解耦複雜流程； 基於發布和訂閱的廣播模式，常見系統通知 異步適用的業務場景，對數據強一致性的要求不高，異步處理的數據更多時候追求的是最終一致性。 二、接口響應異步 1、流程描述 基於接口異步響應的方式，有一個本地業務服務，第三方接口服務，流程如下： 本地服務發起請求，調用第三方服務接口； 請求包含業務參數，和成功或失敗的回調地址； 第三方服務實時響應流水號，作為該調用的標識； 之後第三方服務處理請求，得到最終處理結果； 如果處理成功，回調本地服務的成功通知接口； 如果處理失敗，回調本地服務的失敗通知接口； 整個流程基於部分異步和部分實時的模式，完整處理； 注意 ：如...
張貼留言
閱讀完整內容

.NET Core前後端分離快速開發框架(Core.3.0+AntdVue)

.NET Core前後端分離快速開發框架(Core.3.0+AntdVue) 目錄 引言 時間真快，轉眼今年又要過去了。回想今年，依次開源發布了 Colder.Fx.Net.AdminLTE(254Star) 、 Colder.Fx.Core.AdminLTE(335Star) 、 DotNettySocket(82Star) 、 IdHelper(47Star) ，這些框架及組件都是本着以實際出發，實事求是的態度，力求提高開發效率（我自己都是第一個使用者），目前來看反響不錯。但是隨着前端和後端技術的不斷變革，尤其是前端，目前大環境已經是前後端完全分離為主的開發模式，在這樣的大環境和必然趨勢之下，傳統的MVC就顯得有些落伍了。在這樣的背景下，一款前後端分離的.NET開發框架就顯得尤為必要，由此便定了框架的升級目標： 前後端分離 。 首先後端技術的選擇，從目前的數據來看，.NET Core的發展遠遠快於.NET Framework，最簡單的分析就是Colder.Fx.Core.AdminLTE發布比Colder.Fx.Net.AdminLTE晚，但是星星卻後來居上而且比前者多30%，並且這個差距在不斷擴大，由點及面的分析可以看出我們廣大.NET開發人員學習的熱情和积極向上的態度，並不是某些人所認為的那麼不堪（ 走自己的路，讓別人說去吧 ）。大環境上微軟积極擁抱開源，大力發展.NET Core， 可以說前途一片光明。因此後端決定採用 .NET Core3.0 ，不再浪費精力去支持.NET Framework。 然後是前端技術選擇，首選是三大js框架選擇，也是從實際出發，Vue相對其它而言更加容易上手，並且功能也毫不遜色，深得各種大小公司喜歡，如果偏要說缺點的話，那就是對TS支持不行，但是即將發布Vue3.0肯定會改變這一缺陷。選擇了Vue之後，然後就是UI框架的選擇了，這裏的選擇更多了，我選擇了Ant Design Vue，理由便是簡潔方便，十分符合我的設計理念。 技術選型完畢之後便...
張貼留言
閱讀完整內容

台北市住宅、社區建創儲能設備 最高可獲600萬元補助

為了推廣分散式發電，台北市環保局預計補助1億元供住宅社區設置創能、儲能設備，計有3種方案可供選擇。環保局說明，每案補助額度不超過建制總經費49％，社區每案最高可獲200萬至600萬元補助，住宅每案補助上限100萬元，5月1日起開放申請。 環保局說明，台北市溫室氣體排放量7成以上來自住商部門，其中以使用電力造成間接溫室氣體排放為大宗，台北市平均年用電量約159.86億度，1度電約等同排放0.5公斤二氧化碳，若想達成2050年淨零排放目標，僅靠節能減碳無法達成，必須發展綠色創能、儲能，並且參考歐洲、日本的做法，採分散式發電方式，推廣到社區、住家、商辦，達到供電自給自足目標。 因此，環保局推出「台北市住宅社區創能儲能及節能補助計畫」，補助對象為台北市轄內房屋所有權人及社區管理委員會，補助方案共計3種，每一申請人或每一場址僅能獲1次補助，每案補助額度不超過建置總經費49％為限，5月1日到7月31日開放申請，但補助經費用完即停止申請。 環保局說明，方案A補助對象以社區為主，公共區域申請創能儲能及節能項目，每案補助上限新台幣600萬元；方案B分為住宅或社區公共區域申請創能搭配儲能項目（創能或儲能方案不得單獨申請），社區每案補助上限新台幣400萬元，住宅每案補助上限100萬元。方案C補助對象也是社區，公共區域申請節能項目，每案補助上限新台幣200萬元。 網頁設計 最專業,超強功能平台可客製,窩窩以「數位行銷」「品牌經營」「網站與應用程式」「印刷品設計」等四大主軸，為每一位客戶客製建立行銷脈絡及洞燭市場先機,請問 台中電動車 哪裡在賣比較便宜可以到台中景泰電動車門市去看看總店：臺中市潭子區潭秀里雅潭路一段102-1號。 電動車補助 推薦評價好的 iphone維修 中心擁有專業的維修技術團隊，同時聘請資深iphone手機維修專家，現場說明手機問題，快速修理，沒修好不收錢住家的頂樓裝 太陽光電 聽說可發揮隔熱功效一線推薦東陽能源擁有核心技術、產品研發、系統規劃設置、專業團隊的太陽能發電廠商。 網頁設計 一頭霧水該從何著手呢? 回頭車 貨運收費標準宇安交通關係企業，自成立迄今，即秉持著「以誠待人」、「以實處事」的企業信念 台中搬家公司 教你幾個打包小技巧,輕鬆整理裝箱!還在煩惱搬家費用要多少哪？台中大展搬家線上試算搬家費用，從此不再擔心「物品怎麼計費」、「多...
張貼留言
閱讀完整內容