并發編程中的三個問題
并發這玩意也不知道讓多少新手村的伙伴退游,確實有難度,不過這樣才有意思嘛!
可見性問題
什么是可見性:指一個執行緒對共享變數經行修改,另一個先立即得到修改后的最新值,
但是在并發中一個常見的問題就是無法保證可見性,也就是,假設多個執行緒并發執行,這個時候,如果對于共享變數,第一個執行緒拿到了值,后面的執行緒改變了這個值,前面的執行緒可能依然拿著舊值運算,
舉個例子:一個執行緒獲取boolean型別的標記flag經行while回圈,另一個執行緒改變這個flag變數的值,前一個執行緒并不會停止回圈,
private static boolean flag = true; //共享資料
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
while (flag){
//這里什么都不做,這樣一來,如果是這個執行緒執行就會進入死回圈
}
});
t1.start();
Thread.sleep(1000); //記得要休眠,否則,很多時候都是t2執行,看不出效果
Thread t2 = new Thread(() ->{
flag = false;
System.out.println("執行緒二改變了資料");
});
t2.start();
}
所以并發中如何保證可見性這就是一個問題,
原子性
什么是原子性:在一次或者多次操作中,要么所有的操作都執行并且不會受其他因素干擾而中斷,要么所有操作都不執行,
這么一想會發現和資料庫中的事務的原子性簡直是一模一樣,不久幾個操作要么都執行要么都不執行嗎,
舉個例子:
private static int num = 0;
public static void main(String[] args) throws InterruptedException {
/**
* 這個執行緒就是把這個數加到100
*/
Runnable runnable = () -> {
for (int i = 0; i < 100; i++) {
num++;
}
};
//用一個集合裝載執行緒,方便中斷主執行緒,避免提前結束
ArrayList<Thread> runnables = new ArrayList<>();
for (int i = 0; i < 5; i++) {
Thread thread = new Thread(runnable);
thread.start();
runnables.add(thread);
}
//每個執行緒呼叫join方法都可以用來阻塞主執行緒,
for (Thread thread : runnables) {
thread.join();
}
System.out.println(num); //最后的結果很可能小于500
}
join方法的用法可以參考多執行緒常用API,
這個例子中,num++可不是一步操作,編譯之后看位元組碼檔案(javap -p -v 位元組碼檔案):

其中,對于num++ 而言(num 為靜態變數),實際會產生如下的 JVM 位元組碼指令:
getstatic#12//Fieldnum:I
iconst_1
iadd
putstatic#12//Fieldnum:I
看到了吧,num++并不是一條陳述句,這樣一來,如果是一個執行緒執行,到也沒有什么問題,但是如果多執行緒執行,就可能,造成一個執行緒獲得資料0,然后被中斷,另一個獲得0并加一,然后恢復,結果依然用0去加一,本應該為2的結果最后確定可能出現結果為1,
有序性
有序性應該很好理解,就是代碼按照撰寫的順序執行,但是呢,編譯器可不一定按照你撰寫的代碼進行編譯!因為很多時候編譯器會給你優化代碼,可能就不是按照寫的順序進行編譯,
舉個例子:
private static boolean flag = false; //共享資料
private static int num = 0;
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
if(flag){
num = num + num;
} else {
num = 1;
}
System.out.println(num);
});
t1.start();
Thread t2 = new Thread(() ->{
num = 2;
flag = true;
});
t2.start();
}
正常情況下,不論t1還是t2先執行,結果都不可能為0吧,但是如果編譯后t2這兩句因為誰先執行都不影響自己,所以有可能編譯后執行順序是這樣的:
Thread t2 = new Thread(() ->{
flag = true;
num = 2;
});
也就是編譯器有可能覺得這樣編譯效率更高,但是如果是這樣,就可能出現結果為0!
這也就是并發中的有序性問題!
小結一下
總的來說,在多執行緒的情況下,基本上就是這幾個問題,搞懂這些玩意,自然就可以搞懂并發這個玩意,
Java記憶體模型概述
馮諾依曼結構
在這之前,先看一下計算機的基本記憶體模型(作為一個學計算機的,這個必須知道)
提到這又又又又一次需要提到:馮諾依曼結構,即計算機由五大部分組成:
- 輸入設備(比如我們的鍵盤)
- 輸出設備(顯示幕,聲音)
- 存盤器(記憶體)
- 控制器
- 運算器
后面的控制器和運算器是劃分到CPU中,

基本知識
-
CPU:中央處理器,怎么運算,怎么控制,都是由這玩意搞,我們寫的程式最后也會編程一條一條的指令,然后被CPU去執行,去處理資料,
-
記憶體:我們跑起來的程式總需要有地方可以放吧,不就是放在記憶體中嗎,電腦中的記憶體條,越大不就可以放更多的東西了嗎,這不就是意味著后臺可以開啟的行程就越多嗎,
-
快取:記憶體讀取寫入資料是有一個上限的,但是CPU執行的速度遠比這個快,如果CPU都把一條指令執行完了,記憶體卻還沒有讀取完下一條,這就浪費太多時間,這個時候快取就來了,記憶體是單獨的一的設備,快取相當于在CPU自家開了一個小倉庫,這樣讀取資料不需要每次跑到記憶體那么遠去讀,最靠近CPU的快取稱為L1,然后依次是L2,L3和主記憶體,CPU快取模型如圖下圖所示:

一個處理的程序就是:
CPU先看L1中有沒有資料,有就取出(也就是命中)經行運算,然后把處理的最新結果重繪到主存(也就是記憶體)中,如果沒有命中,會依次到L2,L3,直到記憶體,然后把這個資料放一份到前面的快取中,
Java中的記憶體模型
首先自行區分Java中的記憶體結構和記憶體模型這個概念,Java記憶體模型的英文名稱為Java Memory Model(JMM),其并不想JVM記憶體結構一樣真實存在,而是一個抽象的概念,JMM和執行緒有關,它描述了一組規范或規則,一個執行緒對共享變數的寫入時對另一個執行緒是可見的,Java多執行緒對共享記憶體進行操作的時候,會存在一些如可見性、原子性和順序性的問題,JMM是圍繞著多執行緒通信及相關的一些特性而建立的模型,

這張圖中,就是描述每個執行緒都有自己的作業記憶體,這個部分獨有,互不干擾,但是對于共享的主記憶體就可能出現各種并發問題,
- 主記憶體:所有的執行緒共享,
- 作業記憶體:每個執行緒都有自己的作業記憶體,作業記憶體只存盤該執行緒對主記憶體的副本,執行緒對所有資料進行操作都是在自己的作業記憶體中完成的,
這個玩意就是synchronized和volatile這些東西可以控制并發安全的核心,
了解一下這個作業記憶體到主記憶體這個讀寫程序:

- 一個執行緒操作之前先對該資料加鎖,防止別人亂搞(此時會清空作業記憶體中這個變數的值)
- 然后讀取資料
- 把資料加載到作業記憶體
- 對資料操作
- 操作完了再寫回主記憶體
- 釋放這個鎖(只有同步資料完成才可以釋放)
Synchronized解決并發問題
這個關鍵字可以保證再同一時刻最多只有一個執行緒執行這段代碼,這樣就保證了并發情況下的安全問題,
synchronized(一把鎖){
//需要被保護的代碼
}
保證原子性
還是上面的原子性的例子:
private static int num = 0;
private static Object lock = new Object();
public static void main(String[] args) throws InterruptedException {
/**
* 這個執行緒就是把這個數加到100,注意加鎖了
*/
Runnable runnable = () -> {
for (int i = 0; i < 100; i++) {
synchronized(lock){
num++;
}
}
};
//用一個集合裝載執行緒,方便中斷主執行緒,避免提前結束
ArrayList<Thread> runnables = new ArrayList<>();
for (int i = 0; i < 5; i++) {
Thread thread = new Thread(runnable);
thread.start();
runnables.add(thread);
}
//每個執行緒呼叫join方法都可以用來阻塞主執行緒,
for (Thread thread : runnables) {
thread.join();
}
System.out.println(num); //最后的結果很可能小于500
}
這個時候無論怎么運行,結果都會是500,
進行反編譯看這個結果:(會發現多了monitorenter這個指令)

怎么理解這個加鎖程序:就是一個執行緒準備操作num這個變數,就會把這個東西占位獨有,用自己定義的lock變數提示對方已經被我鎖住了(相當于上廁所門把手,你進門會鎖門,從外邊看就變成了紅色,別人就不會NT還去嘗試開這門,而是在外邊等著),
所以再次理解這個原子性,這分明就是好幾條指令,但是這些指令再某個時刻只能被一個人操作!
保證可見性
依然是上面的例子:
private static boolean flag = true; //共享資料
private static Object lock = new Object();
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
while (flag){
synchronized (lock){
//加個鎖,
}
}
});
t1.start();
Thread.sleep(1000); //記得要休眠,否則,很多時候都是t2執行,看不出效果
Thread t2 = new Thread(() ->{
flag = false;
System.out.println("執行緒二改變了資料");
});
t2.start();
}
這個時候無論怎么運行都不會出現執行緒t1一直跑的情況,
那之前沒加鎖為什么會出現這種情況呢?了解完Java記憶體模型應該就明白了,
因為每個執行緒都是都是有自己的作業記憶體,假設執行緒t1先拿到資料flag,他就會復制到自己的作業記憶體,然后就死回圈,因為他沒對資料操作改變,就不會重繪主記憶體,然后t2拿到,改變了,重繪了主記憶體,但是對t1來說,他一直使用的都是之前復制的,
加了這個鎖之后呢,每次回圈我都要加鎖,會對主記憶體操作(參考記憶體模型圖),出了這個同步代碼塊又會釋放鎖,也會對主記憶體操作,然后如果t2改變了,這個時候t1由于死回圈,會不斷的重復這個代碼塊,也就是不斷地去主記憶體重繪,自然能讀取到t2改變的新資料,
保證有序性
上面提到過,編譯器在編譯的時候,不一定所有的代碼都是按照我們寫的方式經行編譯,
但是像這樣的代碼一定會按照我們寫的順序執行:(有資料依賴關系)
//讀后寫,這個例子中,就必須按照這種順序編譯,否則就會結果出錯
int a = 1;
int b = a;
//總之如果一些代碼沒有依賴關系,就有可能發生重排序,例如:
int a = 1;
int b = 2;
int c = a + b;
//這個也可能發生重排序,但是最多只能是a b互換,c必須是最后
int b = 2;
int a = 1;
int c = a + b;
然后使用synchronized是如何保證的呢:
private static boolean flag = false; //共享資料
private static int num = 0;
private static Object o = new Object();
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
synchronized(o){
if(flag){
num = num + num;
} else {
num = 1;
}
}
System.out.println(num);
});
t1.start();
Thread t2 = new Thread(() ->{
synchronized(o){
num = 2;
flag = true;
}
});
t2.start();
}
這樣一來,其實t2中的這兩句依然有可能重排序,但是,不論怎么排序,這兩句一定是被執行完了,才能輪到t1,或者說t1執行完了才能輪到t2,不存在,t2執行到重排序后的flag = true,然后t1執行,這樣也就保證了整個程序結果的都是符合預期的!
Synchronized的特性
可重入性
先給出定義:指的是同一執行緒的外層函式獲得鎖之后,內層函式可以直接再次獲得該鎖,
public class ZiJie {
public static void main(String[] args) {
Runnable runnable = () -> {
synchronized (ZiJie.class){
System.out.println("第一層");
synchronized ((ZiJie.class)){
System.out.println("第二層");
}
}
};
new Thread(runnable).start();
new Thread(runnable).start();
}
}
//最后的結果一定是:
第一層
第二層
第一層
第二層
當然也可以這么寫:(更加的符合實際一點)
public class ZiJie {
public static void test(){
synchronized (ZiJie.class){
System.out.println("第二層");
}
}
public static void main(String[] args) {
Runnable runnable = () -> {
synchronized (ZiJie.class){
System.out.println("第一層");
test();
}
};
new Thread(runnable).start();
new Thread(runnable).start();
}
}
這個是什么意思,好比你手里拿著一個本子,你第一次進入synchronized,拿到這個鎖,你就記錄這把鎖數量為1,此時別人肯定拿不到,然后你再進一個,發現又是這把鎖,然后就把這個鎖數量變為2,這個時候即使你退出第一層synchronized,別人依然進不來,因為,你表示你還有一層沒有出去,(也就是你本子上必須寫了這個數量為0的時候,別人才可以使用)
總結:synchronized的鎖物件中有一個計數器(recursions變數)會記錄執行緒獲得幾次鎖.
可重入帶來的好處:
-
避免死鎖
避免死鎖的原因: 如果
synchronized不具備可重入性,當一個執行緒想去訪問另一個方法時,它自身已經持有一把鎖,而且還沒有釋放鎖,又想獲取另一個方法的鎖,于是造成了永遠等待的僵局,就會造成死鎖,有了可重入性后,自己持有一把鎖,并且可以直接進入到內層函式中,就避免了死鎖,注意這是針對同一把鎖,
-
更好的封裝代碼
編程人員不需要手動加鎖和解鎖,統一由JVM管理,提高了可利用性,
Synchronized可重入性的作用范圍是整個獲得鎖的執行緒,執行緒內部的所有被呼叫的方法都共享該鎖,
不可中斷性
一旦這個鎖被別人獲得了,如果我還想獲得,我只能選擇等待或者阻塞,直到別的執行緒釋放這個鎖,如果別人永遠不釋放鎖,那么我只能永遠等下去
相比之下,Lock類,可以擁有中斷的能力,第一點,如果我覺的我等的時間太長了,有權中斷現在已經獲取到鎖的執行緒的執行,第二點,如果我覺的我等待的時間太長了不想等了,也可以退出
synchronized 的不可中斷演示:
public static void main(String[] args) throws InterruptedException {
Runnable runnable = () -> {
synchronized (ZiJie.class){
System.out.println(Thread.currentThread().getName()+"第一層");
while (true){
}
}
};
Thread t1 = new Thread(runnable,"執行緒1");
Thread t2 = new Thread(runnable,"執行緒2");
t2.start();
t1.start();
Thread.sleep(200);
//下面這兩種一個處于RUNABLE,另一個處于BLOCKED
System.out.println(t1.getState());
System.out.println(t2.getState());
}
查看原始碼如下:
public enum State {
/**
* Thread state for a thread which has not yet started.
*/
NEW,
/**
* Thread state for a runnable thread. A thread in the runnable
* state is executing in the Java virtual machine but it may
* be waiting for other resources from the operating system
* such as processor.
*/
RUNNABLE,
/**
* Thread state for a thread blocked waiting for a monitor lock.
* A thread in the blocked state is waiting for a monitor lock
* to enter a synchronized block/method or
* reenter a synchronized block/method after calling
* {@link Object#wait() Object.wait}.
*/
BLOCKED,
/**
* Thread state for a waiting thread.
* A thread is in the waiting state due to calling one of the
* following methods:
* <ul>
* <li>{@link Object#wait() Object.wait} with no timeout</li>
* <li>{@link #join() Thread.join} with no timeout</li>
* <li>{@link LockSupport#park() LockSupport.park}</li>
* </ul>
*
* <p>A thread in the waiting state is waiting for another thread to
* perform a particular action.
*
* For example, a thread that has called <tt>Object.wait()</tt>
* on an object is waiting for another thread to call
* <tt>Object.notify()</tt> or <tt>Object.notifyAll()</tt> on
* that object. A thread that has called <tt>Thread.join()</tt>
* is waiting for a specified thread to terminate.
*/
WAITING,
/**
* Thread state for a waiting thread with a specified waiting time.
* A thread is in the timed waiting state due to calling one of
* the following methods with a specified positive waiting time:
* <ul>
* <li>{@link #sleep Thread.sleep}</li>
* <li>{@link Object#wait(long) Object.wait} with timeout</li>
* <li>{@link #join(long) Thread.join} with timeout</li>
* <li>{@link LockSupport#parkNanos LockSupport.parkNanos}</li>
* <li>{@link LockSupport#parkUntil LockSupport.parkUntil}</li>
* </ul>
*/
TIMED_WAITING,
/**
* Thread state for a terminated thread.
* The thread has completed execution.
*/
TERMINATED;
}
發現BLOCKED表示處于阻塞狀態,
Lock鎖演示
Lock是有兩中的,一個是普通的lock方法,同synchronized一樣是不可中斷的,然后就是另一個tryLock,可中斷鎖,
public static void main(String[] args) throws InterruptedException {
ReentrantLock lock = new ReentrantLock();
boolean flag = true;
Runnable runnable = () -> {
lock.lock();
System.out.println(Thread.currentThread().getName()+"執行中");
while (flag){
}
lock.unlock();
};
Thread t1 = new Thread(runnable,"執行緒1");
Thread t2 = new Thread(runnable,"執行緒2");
t2.start();
Thread.sleep(200);
t1.start();
t1.interrupt();
Thread.sleep(200);
//一個處于WAITING,另一個RUNABLE
System.out.println(t1.getState());
System.out.println(t2.getState());
}
如果使用tryLock(可中斷),成功拿到回傳true,這樣即使別的執行緒沒拿到鎖,就會進入else分支!
public static void main(String[] args) throws InterruptedException {
ReentrantLock lock = new ReentrantLock();
boolean flag = true;
Runnable runnable = () -> {
boolean b = lock.tryLock();
if(b){
System.out.println(Thread.currentThread().getName()+"執行中");
while (flag){
}
lock.unlock();
}else{
System.out.println("反正沒拿到,干點別的事");
}
};
Thread t1 = new Thread(runnable,"執行緒1");
Thread t2 = new Thread(runnable,"執行緒2");
t2.start();
Thread.sleep(200);
t1.start();
Thread.sleep(200);
System.out.println(t1.getState()); //TERMINATED
System.out.println(t2.getState()); //RUNNABLE
}
Synchronized原理
使用Javap反匯編

我們可以看到,synchronized關鍵字編譯后,會生成兩條指令:monitorenter,monitorexit

monitorenter解釋
官方解釋如下:
每個物件都會與一個monitor相關聯,當某個monitor被擁有之后就會被鎖住,當執行緒執行到monitorenter指令時,就會去嘗試獲得對應的monitor,步驟如下:
- 每個
monitor維護著一個記錄著擁有次數的計數器,未被擁有的monitor的該計數器為0,當一個執行緒獲得monitor(執行monitorenter)后,該計數器自增變為 1 ,- 當同一個執行緒再次獲得該
monitor的時候,計數器再次自增; - 當不同執行緒想要獲得該
monitor的時候,就會被阻塞,
- 當同一個執行緒再次獲得該
- 當同一個執行緒釋放
monitor(執行monitorexit指令)的時候,計數器再自減,當計數器為0的時候,monitor將被釋放,其他執行緒便可以獲得monitor,
總的來說,就是synchronized關鍵字的鎖物件會關聯一個monitor,這個并不是我們創建的,而是由JVM底層創建,這個物件有兩個重要的成員變數:
- owner,表示當前的物件所屬的主人是誰
- resursions,這個執行緒擁有的鎖的次數,如果一個執行緒擁有一個monitor別的執行緒就只能處于等待狀態,
monitorexit解釋
能執行這個指令的執行緒一定是擁有當前monitor的執行緒,這個應該不難理解,必有只有你有這個鎖才可以釋放,
當執行緒執行monitorexit指令時,會去講monitor的計數器減一,如果結果是0,則該執行緒將不再擁有該monitor,其他執行緒就可以獲得該monitor了,
而且,monitorexit插入在方法結束處和例外處,JVM保證每個monitorenter必須有對應的monitorexit,
同步方法
public synchronized static void test(){
System.out.println(Thread.currentThread().getName()+"第二層");
}
對其進行反編譯如下:

我們看到對于同步方法,反編譯后得到ACC_SYNCHRONIZED 標志,
同步方法是隱式的,會隱式的呼叫monitorenter和monitorexit這兩條指令,
小結
通過javap反匯編我們看到synchronized使用編程了monitorentor和monitorexit兩個指令,每個鎖物件都會關聯一個monitor(監視器,它才是真正的鎖物件),它內部有兩個重要的成員變數owner會保存獲得鎖的執行緒,recursions會保存執行緒獲得鎖的次數,當執行到monitorexit時,recursions會-1,當計數器減到0時這個執行緒就會釋放鎖,
monitor監視器鎖
上面中提到,不論怎么使用synchronized,都會涉及到monitor這個物件,
在HotSpot虛擬機原始碼中,monitor這個是由ObjectMonitor這個物件實作(C++寫的)
可以把它理解為一個同步工具,也可以描述為一種同步機制,它通常被描述為一個物件,和萬物皆物件一樣,所有的Java物件是天生的Monitor,每一個Java物件都有成為Monitor的潛質,因為在Java的設計中 ,每一個Java物件自打娘胎里出來就帶了一把看不見的鎖,它叫做內部鎖或者Monitor鎖,Monitor 是執行緒私有的資料結構,每一個執行緒都有一個可用monitor record串列,同時還有一個全域的可用串列,
每一個被鎖住的物件都會和一個monitor關聯(物件頭的MarkWord中的LockWord指向monitor的起始地址),同時monitor中有一個Owner欄位存放擁有該鎖的執行緒的唯一標識,表示該鎖被這個執行緒占用,
Java物件頭
java的物件頭由以下三部分組成:
- Mark Word
- 指向類的指標
- 陣列長度(只有陣列物件才有)
Mark Word記錄了物件和鎖有關的資訊,當這個物件被synchronized關鍵字當成同步鎖時,圍繞這個鎖的一系列操作都和Mark Word有關,總之啊,這個物件頭會記錄一些狀態的設定,

Synchronized優化
CAS
什么是CAS
CAS的全稱為:Compare And Swap(比較相同再交換),是現在CPU廣泛支持的一種記憶體的共享資料經行操作的一種特殊指令,
CAS可以將比較和交換作為原子操作(這樣就保證了執行緒安全),這個保證由CPU保證,CAS操作依賴三個值:
- 記憶體中的最新值V
- 舊的預估值X
- 要修改的新值B
每次操作會比較X和V,只有相同才會把B保存到記憶體中,
CAS和volatile實作無鎖并發
public class CAS {
public static void main(String[] args) throws InterruptedException {
AtomicInteger atomicInteger = new AtomicInteger();
Runnable runnable = () -> {
for (int i = 0; i < 100; i++) {
atomicInteger.incrementAndGet();
}
};
ArrayList<Thread> list = new ArrayList<>();
for (int i = 0; i < 5; i++) {
Thread thread = new Thread(runnable);
thread.start();
list.add(thread);
}
for (Thread thread : list) {
thread.join();
}
System.out.println(atomicInteger);
}
}
原始碼角度決議
首先我哦們注意到我們使用的不是int,而是AtomicInteger,這是一個原子操作類,原始碼如下:(只看這是使用到的incrementAndGet方法,以及屬性)
public class AtomicInteger extends Number implements java.io.Serializable {
private static final long serialVersionUID = 6214790243416807050L;
// setup to use Unsafe.compareAndSwapInt for updates
private static final Unsafe unsafe = Unsafe.getUnsafe();
private static final long valueOffset;
static {
try {
valueOffset = unsafe.objectFieldOffset
(AtomicInteger.class.getDeclaredField("value"));
} catch (Exception ex) { throw new Error(ex); }
}
//被volatile修飾
private volatile int value;
public AtomicInteger(int initialValue) {
value = initialValue;
}
/**
* Creates a new AtomicInteger with initial value {@code 0}.
*/
public AtomicInteger() {
}
public final int incrementAndGet() {
return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
}
}
[ PS ]:volatile修飾的關鍵字只要對這個值修改就會重繪主記憶體!
我們使用的就是這個默認的構造方法,也就是這個value默認是0,然后在并發中呼叫incrementAndGet方法,這個方法表示自增,然后注意Unsafe這個類:
Unsafe類使Java擁有了像C語言的指標一樣操作記憶體空間的能力,同時也帶來了指標的問題,過度的使用Unsafe類會使得出錯的幾率變大,因此Java官方并不建議使用的,官方檔案也幾乎沒有,這個類你也無法直接呼叫,而只能通過反射獲取,(這個類中的方法幾乎都是呼叫的作業系統的原始碼,不受JVM管理)
然后我們自增的方法呼叫了這個類中的這個getAndAddInt方法:
public final int getAndAddInt(Object var1, long var2, int var4) {
int var5;
do {
//獲取預估值,這個值就是
var5 = this.getIntVolatile(var1, var2);
} while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));
return var5;
}
//而這個比較交換呼叫的就是作業系統的方法
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);
//注意在AtomicInteger這個類中的靜態代碼塊中 valueOffset = unsafe.objectFieldOffset,這個方法同樣是呼叫native方法,獲取記憶體中的value值
public native long objectFieldOffset(Field var1);
然后這個比較交換的程序:(一定要仔細看,否則你可能懵逼了)
假設一個極端情況:(這里使用執行緒A B來表示)
A首先進到var5 = this.getIntVolatile(var1, var2);這句話,你會發現這個也是native方法,而且var2這個值的來源是AtomicInteger中的valueOffset(也就是獲取記憶體中的值):
private static final long valueOffset;
static {
try {
valueOffset = unsafe.objectFieldOffset
(AtomicInteger.class.getDeclaredField("value"));
} catch (Exception ex) { throw new Error(ex); }
}
這個值是一個靜態值,每次呼叫都會觸發這個靜態代碼塊,然后這個方法就是去記憶體中查找value這個值,
至此,A獲取到默認值var5為0,最極端情況,A被中斷,B有執行到A這個地方,也獲取到這個值為0,然后進行compareAndSwapInt方法,var1和var2被本地方法呼叫獲取最新值,然后和var5這個預估值經行比較,B此時發現相同,于是把預估值加上var4(看原始碼,就是unsafe.getAndAddInt(this, valueOffset, 1)傳遞過來的1),然后記憶體的最新值被設定為了1,此時A再進來執行,同樣的取比較記憶體中的最新值和自己的預估值,發現不相等,此時再次進入回圈,再獲取預估值,而這個預估值不就是從記憶體中獲取嗎,就是新設定的值,然后A拿到新的值去比較,相等,再進行加1!
這就是整個CAS演算法的程序,并不難,
樂觀鎖和悲觀鎖
悲觀鎖:總是覺得不夠安全,每次獲取資料怕別人修改,于是每次獲取資料都會對這個資料加鎖,這樣一來,別人來操作這個資料就會進入阻塞,synchronized和ReentrantLock都是一種悲觀鎖,
樂觀鎖:總會覺得沒有問題,自己拿了資料也不上鎖,隨便別人怎么操作,但是自己更新的時候都會判斷一下看別人有沒有改這個資料,改了則重新獲取,CAS這種機制就是一種樂觀鎖,綜合性能不錯,
但是CAS獲取共享變數時,為了保證該變數的可見性,需要使用volatile修飾,結合CAS和volatile可以實作無鎖并發,適用于競爭不激烈、多核 CPU 的場景下:
- 因為沒有使用 synchronized,所以執行緒不會陷入阻塞,這是效率提升的因素之一,
- 如果競爭激烈,可以想到重試(獲取最新值)必然頻繁發生,反而效率會受影響,
鎖升級程序
高效并發是從JDK 5到JDK 6的一個重要改進,HotSpot虛擬機開發團隊在這個版本上花費了大量的精力去實作各種鎖優化技術,包括偏向鎖( Biased Locking )、輕量級鎖( Lightweight Locking )和如適應性自旋(Adaptive Spinning)、鎖消除( Lock Elimination)、鎖粗化( Lock Coarsening )等,這些技術都是為了在執行緒之間更高效地共享資料,以及解決競爭問題,從而提高程式的執行效率,
整個程序:無鎖——>偏向鎖——>輕量級鎖——>自旋鎖——>鎖消除——>鎖粗化——>重量級鎖
偏向鎖
什么是偏向鎖
再大多數情況下,鎖不僅不存在多執行緒競爭,而且同一時間總是由同一個執行緒多次獲得,為了讓執行緒獲得鎖的帶價更低,就引進了偏向鎖,
偏向鎖的意思就是這個鎖會偏向于第一個獲得他的執行緒,會在物件頭存盤鎖偏向的執行緒的id,以后該執行緒進入和退出只需要檢查是否為偏向鎖,鎖標志位以及執行緒id即可,
不過一旦出現多個執行緒競爭時必須撤銷偏向鎖,所以撤銷偏向鎖消耗的性能必須小于之前節省下來的CAS原子操作的性能消耗,不然就得不償失了,
原理
偏向鎖就是指物件頭中的 mark word 存盤了當前執行緒的 ID;
獲取鎖程序
- 檢查
mark word中的執行緒 id 是不是當前執行緒,如果是當前執行緒,進入同步代碼塊;不是就執行步驟 2; - 進行
CAS嘗試將 執行緒 ID 換成自己;如果成功就執行代碼塊,不成功就執行步驟 3; - 當擁有鎖的執行緒到達安全點之后,掛起這個執行緒,進行鎖升級 - 步驟 4;
- 鎖升級,原持有偏向鎖的執行緒,創建鎖記錄,將鎖物件頭拷貝到鎖記錄,喚醒持有鎖的執行緒繼續執行;然后釋放輕量級鎖 - 步驟 5
- 首先對比物件頭中的鎖記錄指標是否指向當前執行緒的鎖記錄;再對比執行緒鎖記錄中的
mark word是否和物件頭的mark word一致;如果一致就釋放鎖,不一致則執行步驟 6 - 執行到這里,表示鎖升級成重量級,釋放鎖,然后喚醒被掛起的執行緒,
好處
偏向鎖是在只有一個執行緒執行同步塊時進一步提高性能,適用于一個執行緒反復獲得同一鎖的情況,偏向鎖可以提高帶有同步但無競爭的程式性能,
它同樣是一個帶有效益權衡性質的優化,也就是說,它并不一定總是對程式運行有利,如果程式中大多數的鎖總是被多個不同的執行緒訪問比如執行緒池,那偏向模式就是多余的,
在JDK5中偏向鎖默認是關閉的,而到了JDK6中偏向鎖已經默認開啟,但在應用程式啟動幾秒鐘之后才激活,可以使用-XX:BiasedLockingStartupDelay=0引數關閉延遲,如果確定應用程式中所有鎖通常情況下處于競爭狀態,可以通過-XX:-UseBiasedLocking=false引數關閉偏向鎖,
輕量級鎖
什么是輕量級鎖
輕量級鎖是JDK 6之中加入的新型鎖機制,它名字中的“輕量級”是相對于使用monitor的傳統鎖而言的,因此傳統的鎖機制就稱為“重量級”鎖,
首先需要強調一點的是,輕量級鎖并不是用來代替重量級鎖的,
引入輕量級鎖的目的:在多執行緒交替執行同步塊的情況下,盡量避免重量級鎖引起的性能消耗,但是如果多個執行緒在同一時刻進入臨界區,會導致輕量級鎖膨脹升級重量級鎖,所以輕量級鎖的出現并非是要替代重量級鎖,
原理
- 當執行緒嘗試獲取鎖時,會在堆疊中創建一個鎖記錄,并把鎖物件的 mark word 拷貝到鎖記錄中;
- 使用 CAS 嘗試將鎖物件的
mark word更新為當前執行緒鎖記錄的指標,如果成功,表示持有鎖,執行同步塊,如果失敗執行步驟 3 - 執行緒就會自旋,重復步驟 2;如果達到一定次數,沒有獲取成功,就執行步驟 4
- 鎖升級,將執行緒鎖物件頭修改指向
monitor的指標,然后繼續執行代碼塊,釋放重量級鎖
小結
在多執行緒交替執行同步塊的情況下,可以避免重量級鎖引起的性能消耗,
自旋鎖
什么是自旋鎖
monitor會阻塞和喚醒執行緒,執行緒的阻塞和喚醒需要CPU從用戶態轉為核心態,頻繁的阻塞和喚醒對CPU來說是一件負擔很重的作業,這些操作給系統的并發性能帶來了很大的壓力,
同時,虛擬機的開發團隊也注意到在許多應用上,共享資料的鎖定狀態只會持續很短的一段時間,為了這段時間阻塞和喚醒執行緒并不值得,如果物理機器有一個以上的處理器,能讓兩個或以上的執行緒同時并行執行,我們就可以讓后面請求鎖的那個執行緒“稍等一下”,但不放棄處理器的執行時間,看看持有鎖的執行緒是否很快就會釋放鎖,為了讓執行緒等待,我們只需讓執行緒執行一個忙回圈(自旋) , 這項技術就是所謂的自旋鎖,
大白話就是,假設有個人上廁所,假設這個人還有10秒出來,而你走過去或者回來需要30秒,這個時候看到有人在廁所,你是等一下還是直接回去,這就是自旋鎖,也就是我設定一個掙扎時間,再這個時間內我就不回去,一直等著,這個時間到了再回去,
自旋等待不能代替阻塞,且先不說對處理器數量的要求,自旋等待本身雖然避免了執行緒切換的開銷,但它是要占用處理器時間的,因此,如果鎖被占用的時間很短,自旋等待的效果就會非常好,反之,如果鎖被占用的時間很長,那么自旋的執行緒只會白白消耗處理器資源,而不會做任何有用的作業,反而會帶來性能上的浪費,
因此,自旋等待的時間必須要有一定的限度,如果自旋超過了限定的次數仍然沒有成功獲得鎖,就應當使用傳統的方式去掛起執行緒了,自旋次數的默認值是10次,用戶可以使用引數-XX : PreBlockSpin更改,
適應性自旋鎖
在JDK 6中引入了自適應的自旋鎖,自適應意味著自旋的時間不再固定了,而是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態來決定,
jvm 會根據上一次自旋的次數動態的調整自旋的次數,如果上一次自旋的次數少,表示執行緒自旋獲取鎖的概率大,jvm 會增加相應的次數,增加獲取鎖的概率,反之亦然;
一張圖總結:

如何優化
減少synchronized的范圍
同步代碼塊中盡量短,減少同步代碼中的執行時間,減少鎖的競爭,
盡量只鎖住可能出現并發問題的地方,
synchronized(Demo.class){
//必要部分
a++;
}
//非必要部分
System.out.print(a);
減少synchronized鎖的粒度
將一個鎖拆分為多個鎖提高并發度,
這一點很重要,因為JDK中改進的地方很多都是這么干的,比如我們知道HashMap本來是執行緒不安全的,但是HashTable是執行緒安全的:(直接鎖住整個方法)
public synchronized V put(K key, V value) {
// Make sure the value is not null
if (value == null) {
throw new NullPointerException();
}
...
}
但是你發現了嗎,所有的put操作,全部上鎖:

后來的JUC(java.util.concurrent)迸發包中改進的ConcurrentHashMap如下:
public V put(K key, V value) {
return putVal(key, value, false); //呼叫下面這個方法
}
/** 這里是重點,順便閱讀一下原始碼 */
final V putVal(K key, V value, boolean onlyIfAbsent) {
if (key == null || value == null) throw new NullPointerException();
int hash = spread(key.hashCode()); //計算hash值
int binCount = 0;
for (Node<K,V>[] tab = table;;) {
Node<K,V> f; int n, i, fh;
if (tab == null || (n = tab.length) == 0)
tab = initTable();
else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {
//當表為空的時候,進行CAS操作,存放這個資料,防止別人并發時候也在這個位置存放資料
if (casTabAt(tab, i, null,
new Node<K,V>(hash, key, value, null))) //下面的官方注釋下都寫著添加的時候表中無資料無鎖,其實就是樂觀鎖
break; // no lock when adding to empty bin
}
else if ((fh = f.hash) == MOVED)
tab = helpTransfer(tab, f);
else {
V oldVal = null;
//然后就是這里,這個f就是每一列的頭!!!,也就是只鎖住了每一列,對其他列不影響
synchronized (f) {
if (tabAt(tab, i) == f) {
......//中間代碼省略
}
}
addCount(1L, binCount);
return null;
}
最后用這張圖來表示:

像這樣的例子還有佇列,普通的佇列都是讀寫使用一把鎖,這樣你在讀的時候我就什么也做不了,但是佇列操作都是一頭一尾,讀寫本就互相獨立:

后的JUC中同樣對這個進行了改進,LinkedBlockingQueue入隊和出隊使用不同的鎖,相對于讀寫只有一個鎖效率要高:

讀取時不加鎖,寫入和洗掉時加鎖:(這也就是讀寫分離)
ConcurrentHashMap,CopyOnWriteArrayList和ConyOnWriteSet
轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/271330.html
標籤:java
