一、資源和加鎖
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