Java并發編程之悲觀鎖和樂觀鎖機制
一、資源和加鎖
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語句中最終釋放鎖,維護相對正常的線程狀態,在獲取鎖的過程中,可以嘗試獲取,或者嘗試獲取鎖一段時間。