這是一篇關(guān)于java鎖的總結(jié)的開(kāi)端，后續(xù)會(huì)單獨(dú)對(duì)部分鎖的原理進(jìn)行展開(kāi)。內(nèi)容大多來(lái)自《深入理解Java虛擬機(jī)》、《Java并發(fā)編程實(shí)戰(zhàn)》和網(wǎng)絡(luò)上城须。

公平鎖和非公平鎖

顧名思義，一個(gè)是不可搶占嚴(yán)格按照先到先得的鎖米苹，一個(gè)是可搶占的不公平的鎖糕伐。
公平鎖是指多個(gè)線程在等待同一個(gè)鎖時(shí)，必須按照申請(qǐng)鎖的先后順序來(lái)一次獲得鎖蘸嘶。公平鎖的好處是等待鎖的線程不會(huì)餓死良瞧，但是整體效率相對(duì)低一些；
非公平鎖的好處是整體效率相對(duì)高一些训唱，但是有些線程可能會(huì)餓死或者要等很久才會(huì)獲得鎖褥蚯。如果在某個(gè)時(shí)刻有線程需要獲取鎖，而這個(gè)時(shí)候剛好鎖可用况增，那么這個(gè)線程會(huì)直接搶占赞庶，而這時(shí)阻塞在等待隊(duì)列的線程則不會(huì)被喚醒。
公平鎖可以使用new ReentrantLock(true)實(shí)現(xiàn)澳骤。

可重入鎖

可重入鎖歧强，也叫做遞歸鎖，指的是同一線程外層函數(shù)獲得鎖之后 宴凉，內(nèi)層遞歸函數(shù)仍然有獲取該鎖的代碼誊锭，但不受影響。
在JAVA環(huán)境下 ReentrantLock 和synchronized 都是可重入鎖弥锄。可重入鎖最大的作用是避免死鎖。

重入的一種實(shí)現(xiàn)方法是：為每個(gè)鎖關(guān)聯(lián)一個(gè)獲取計(jì)數(shù)器和一個(gè)所有者線程籽暇。當(dāng)計(jì)數(shù)器值為0時(shí)温治，這個(gè)鎖就被認(rèn)為是沒(méi)有被任何線程持有。當(dāng)線程請(qǐng)求一個(gè)未被持有的鎖時(shí)戒悠，JVM記下鎖的持有者熬荆，并將計(jì)數(shù)器置1，如果同一個(gè)線程再次獲取到鎖绸狐，計(jì)數(shù)器遞增卤恳，當(dāng)線程退出同步代碼塊時(shí)，計(jì)數(shù)器會(huì)相應(yīng)地遞減寒矿。當(dāng)計(jì)數(shù)器值為0時(shí)突琳，這個(gè)鎖將被釋放。
不然當(dāng)子類改寫(xiě)了父類的synchronized方法符相，然后調(diào)用父類中的方法拆融，此時(shí)如果沒(méi)有可重入鎖，那么這段代碼將會(huì)產(chǎn)生死鎖啊终，如：

public class Widget {
    public synchronized void doSomething() {
    ...
    }
}

public class LoggingWidget extends Widget {
    public synchronized void doSomething() {
    super.doSomething();
    }
}

鎖消除

鎖消除是虛擬機(jī)在運(yùn)行時(shí)镜豹，對(duì)一些代碼上要求同步，但是被檢測(cè)到不可能存在共享數(shù)據(jù)競(jìng)爭(zhēng)的鎖進(jìn)行消除蓝牲。鎖消除的主要判斷依據(jù)是來(lái)源于逃逸分析的數(shù)據(jù)支持趟脂，如果判斷在一段代碼中，堆上的所有數(shù)據(jù)都不會(huì)逃逸出去從而能被其他線程訪問(wèn)到例衍，那就可以把他們當(dāng)做棧上數(shù)據(jù)對(duì)待散怖，認(rèn)為他們是線程私有的缔莲，同步加鎖自然就無(wú)需進(jìn)行佑附。看例子：

public String concatString(String s1, String s2, String s3) { 
    StringBuffer sb StringBuffer(); 
    sb.append(s1); 
    sb.append(s2); 
    sb.append(s3); 
    return sb.toString(); 
}

StringBuffer append方法的內(nèi)部加了同步關(guān)鍵字：

public synchronized StringBuffer append(Object obj) {
    toStringCache = null;
    super.append(String.valueOf(obj));
    return this;
}

也就是說(shuō)在concatString()方法中涉及了同步操作吠各。但是虛擬機(jī)觀察sb變量的的作用域被限制在方法的內(nèi)部翎嫡，也就是sb的所有引用不會(huì)“逃逸”到concatString之外欠动，其他線程無(wú)法訪問(wèn)到它。因此惑申，雖然這里有鎖具伍，但是可以被安全的消除，在即時(shí)編譯之后圈驼，這段代碼就會(huì)忽略掉所有的同步而直接執(zhí)行了人芽。

鎖粗化

原則上，我們?cè)诰帉?xiě)代碼的時(shí)候绩脆，總是推薦將同步塊的作用范圍限制的盡量小——只在共享數(shù)據(jù)的實(shí)際作用域中才進(jìn)行同步萤厅，這樣是為了使得需要同步的操作數(shù)量盡可能變小橄抹，如果存在鎖競(jìng)爭(zhēng)，那等待的線程也能盡快拿到鎖惕味。大部分情況下楼誓，這些都是正確的。但是名挥，如果一些列的聯(lián)系操作都是同一個(gè)對(duì)象反復(fù)加上和解鎖疟羹，甚至加鎖操作是出現(xiàn)在循環(huán)體中的，那么即使沒(méi)有線程競(jìng)爭(zhēng)禀倔，頻繁地進(jìn)行互斥同步操作也導(dǎo)致不必要的性能損耗榄融。
舉個(gè)案例，類似鎖消除的concatString()方法救湖。如果StringBuffer sb = new StringBuffer();定義在方法體之外愧杯，那么就會(huì)有線程競(jìng)爭(zhēng)，但是每個(gè)append()操作都對(duì)同一個(gè)對(duì)象反復(fù)加鎖解鎖捎谨，那么虛擬機(jī)探測(cè)到有這樣的情況的話民效，會(huì)把加鎖同步的范圍擴(kuò)展到整個(gè)操作序列的外部，即擴(kuò)展到第一個(gè)append()操作之前和最后一個(gè)append()操作之后涛救，這樣的一個(gè)鎖范圍擴(kuò)展的操作就稱之為鎖粗化畏邢。

類鎖和對(duì)象鎖

類鎖：在方法上加上static synchronized的鎖，或者synchronized(xxx.class)的鎖检吆，鎖的范圍是整個(gè)類class舒萎。如下代碼中的m1和m2：

對(duì)象鎖:鎖對(duì)象是當(dāng)前類對(duì)象或者自定義鎖對(duì)象，參考m3,m4,m5蹭沛。

public class LockClass { 
    public Object lock = Object(); 
    //類鎖
    public static synchronized m1(){}  
    public m2(){ synchronized(LockClass.class){}} 
    //對(duì)象鎖
    public synchronized m3(){}
    public m4() { synchronized(){} } 
    public m5() { synchronized(object1){} } 
}

自旋鎖

Java的線程是映射到操作系統(tǒng)的原生線程之上的臂寝，如果要阻塞或喚醒一個(gè)線程，都需要操作系統(tǒng)來(lái)幫忙完成摊灭，這就需要從用戶態(tài)轉(zhuǎn)換到核心態(tài)中咆贬，因此狀態(tài)裝換需要耗費(fèi)很多的處理器時(shí)間，對(duì)于代碼簡(jiǎn)單的同步塊（如被synchronized修飾的getter()和setter()方法）帚呼，狀態(tài)轉(zhuǎn)換消耗的時(shí)間有可能比用戶代碼執(zhí)行的時(shí)間還要長(zhǎng)掏缎。

在許多應(yīng)用上，共享數(shù)據(jù)的鎖定狀態(tài)只會(huì)持續(xù)很短的一段時(shí)間煤杀，為了這段時(shí)間取掛起和恢復(fù)現(xiàn)場(chǎng)并不值得眷蜈。
如果物理機(jī)器有一個(gè)以上的處理器，能讓兩個(gè)或以上的線程同時(shí)并行執(zhí)行沈自，我們就可以讓后面請(qǐng)求鎖的那個(gè)線程“稍等一下“酌儒，但不放棄處理器的執(zhí)行時(shí)間，看看持有鎖的線程是否很快就會(huì)釋放鎖枯途。為了讓線程等待忌怎，我們只需讓線程執(zhí)行一個(gè)忙循環(huán)（自旋）籍滴，這項(xiàng)技術(shù)就是所謂的自旋鎖。

自旋等待不能代替阻塞呆躲。自旋等待本身雖然避免了線程切換的開(kāi)銷异逐，但它是要占用處理器時(shí)間的捶索，因此插掂，如果鎖被占用的時(shí)間很短，自旋當(dāng)代的效果就會(huì)非常好腥例，反之辅甥，如果鎖被占用的時(shí)間很長(zhǎng)，那么自旋的線程只會(huì)白白浪費(fèi)處理器資源燎竖。因此璃弄，自旋等待的時(shí)間必須要有一定的限度，如果自旋超過(guò)了限定次數(shù)（默認(rèn)是10次构回，可以使用-XX:PreBlockSpin來(lái)更改）沒(méi)有成功獲得鎖夏块，就應(yīng)當(dāng)使用傳統(tǒng)的方式去掛起線程了。

自旋鎖在JDK1.4.2中引入纤掸，使用-XX:+UseSpinning來(lái)開(kāi)啟脐供。JDK6中已經(jīng)變?yōu)槟J(rèn)開(kāi)啟，并且引入了自適應(yīng)的自旋鎖借跪。自適應(yīng)意味著自旋的時(shí)間不在固定了政己，而是由前一次在同一個(gè)鎖上的自旋時(shí)間及鎖的擁有者的狀態(tài)來(lái)決定。

自旋是在輕量級(jí)鎖中使用的掏愁，在重量級(jí)鎖中歇由，線程不使用自旋。

如果在同一個(gè)鎖對(duì)象上果港，自旋等待剛剛成功獲得過(guò)鎖沦泌，并且持有鎖的線程正在運(yùn)行中，那么虛擬機(jī)就會(huì)認(rèn)為這次自旋也是很有可能再次成功辛掠，進(jìn)而它將允許自旋等待持續(xù)相對(duì)更長(zhǎng)的時(shí)間谢谦，比如100次循環(huán)。另外公浪，如果對(duì)于某個(gè)鎖他宛，自旋很少成功獲得過(guò)，那在以后要獲取這個(gè)鎖時(shí)將可能省略掉自旋過(guò)程欠气，以避免浪費(fèi)處理器資源厅各。

偏向鎖、輕量級(jí)鎖和重量級(jí)鎖

偏向鎖是JDK6中引入的一項(xiàng)鎖優(yōu)化预柒，它的目的是消除數(shù)據(jù)在無(wú)競(jìng)爭(zhēng)情況下的同步原語(yǔ)队塘，進(jìn)一步提高程序的運(yùn)行性能袁梗。
大多數(shù)情況下，鎖不僅不存在多線程競(jìng)爭(zhēng)憔古，而且總是由同一線程多次獲得遮怜，為了讓線程獲得鎖的代價(jià)更低而引入了偏向鎖。
偏向鎖會(huì)偏向于第一個(gè)獲得它的線程鸿市，如果在接下來(lái)的執(zhí)行過(guò)程中锯梁，該鎖沒(méi)有被其他的線程獲取，則持有偏向鎖的線程將永遠(yuǎn)不需要同步焰情。

當(dāng)鎖對(duì)象第一次被線程獲取的時(shí)候陌凳，線程使用CAS操作把這個(gè)鎖的線程ID記錄再對(duì)象Mark Word之中，同時(shí)置偏向標(biāo)志位1内舟。以后該線程在進(jìn)入和退出同步塊時(shí)不需要進(jìn)行CAS操作來(lái)加鎖和解鎖合敦，只需要簡(jiǎn)單地測(cè)試一下對(duì)象頭的Mark Word里是否存儲(chǔ)著指向當(dāng)前線程的偏向鎖。如果測(cè)試成功验游，表示線程已經(jīng)獲得了鎖充岛。

如果線程使用CAS操作時(shí)失敗則表示該鎖對(duì)象上存在競(jìng)爭(zhēng)并且這個(gè)時(shí)候另外一個(gè)線程獲得偏向鎖的所有權(quán)。當(dāng)?shù)竭_(dá)全局安全點(diǎn)時(shí)獲得偏向鎖的線程被掛起耕蝉，膨脹為輕量級(jí)鎖崔梗，同時(shí)被撤銷偏向鎖的線程繼續(xù)往下執(zhí)行同步代碼。
當(dāng)有另外一個(gè)線程去嘗試獲取這個(gè)鎖時(shí)赔硫，偏向模式就宣告結(jié)束炒俱。

線程在執(zhí)行同步塊之前，JVM會(huì)先在當(dāng)前線程的棧幀中創(chuàng)建用于存儲(chǔ)鎖記錄(Lock Record)的空間爪膊，并將對(duì)象頭中的Mard Word復(fù)制到鎖記錄中权悟，官方稱為Displaced Mark Word。然后線程嘗試使用CAS將對(duì)象頭中的Mark Word替換為指向鎖記錄的指針推盛。如果成功峦阁，當(dāng)前線程獲得鎖，如果失敗耘成，表示其他線程競(jìng)爭(zhēng)鎖榔昔，當(dāng)前線程便嘗試使用自旋來(lái)獲取鎖。如果自旋失敗則鎖會(huì)膨脹成重量級(jí)鎖瘪菌。如果自旋成功則依然處于輕量級(jí)鎖的狀態(tài)撒会。

輕量級(jí)鎖提升程序同步性能的依據(jù)是：對(duì)于絕大部分的鎖，在整個(gè)同步周期內(nèi)都是不存在競(jìng)爭(zhēng)的（區(qū)別于偏向鎖）师妙。這是一個(gè)經(jīng)驗(yàn)數(shù)據(jù)诵肛。如果沒(méi)有競(jìng)爭(zhēng)，輕量級(jí)鎖使用CAS操作避免了使用互斥量的開(kāi)銷默穴，但如果存在鎖競(jìng)爭(zhēng)怔檩，除了互斥量的開(kāi)銷外褪秀，還額外發(fā)生了CAS操作，因此在有競(jìng)爭(zhēng)的情況下薛训，輕量級(jí)鎖比傳統(tǒng)的重量級(jí)鎖更慢媒吗。

整個(gè)synchronized鎖流程如下：
1. 檢測(cè)Mark Word里面是不是當(dāng)前線程的ID，如果是乙埃，表示當(dāng)前線程處于偏向鎖
2. 如果不是闸英，則使用CAS將當(dāng)前線程的ID替換Mard Word，如果成功則表示當(dāng)前線程獲得偏向鎖膊爪，置偏向標(biāo)志位1
3. 如果失敗自阱，則說(shuō)明發(fā)生競(jìng)爭(zhēng)嚎莉，撤銷偏向鎖米酬，進(jìn)而升級(jí)為輕量級(jí)鎖。
4. 當(dāng)前線程使用CAS將對(duì)象頭的Mark Word替換為鎖記錄指針趋箩，如果成功赃额，當(dāng)前線程獲得鎖
5. 如果失敗，表示其他線程競(jìng)爭(zhēng)鎖叫确，當(dāng)前線程便嘗試使用自旋來(lái)獲取鎖跳芳。
6. 如果自旋成功則依然處于輕量級(jí)狀態(tài)。
7. 如果自旋失敗竹勉，則升級(jí)為重量級(jí)鎖飞盆。

分段鎖

要降低鎖的競(jìng)爭(zhēng)程度，其中有一種方式是：減少鎖的持有時(shí)間次乓、縮小鎖的范圍吓歇、減少鎖的粒度。
這種技術(shù)可以采用多個(gè)相互獨(dú)立的鎖來(lái)保護(hù)共享資源來(lái)實(shí)現(xiàn)票腰，這就是分段鎖城看。然而這會(huì)提高程序的復(fù)雜度，而且使用的鎖越多杏慰，發(fā)生死鎖的風(fēng)險(xiǎn)也就越高测柠。但是要做全局的統(tǒng)計(jì)功能時(shí)還是需要對(duì)共享資源進(jìn)行全局加鎖。
ConcurrentHashMap中采用了分段鎖缘滥。

悲觀鎖和樂(lè)觀鎖

悲觀鎖：假定會(huì)發(fā)生并發(fā)沖突轰胁，屏蔽一切可能違反數(shù)據(jù)完整性的操作，簡(jiǎn)單地說(shuō)是讀寫(xiě)都加鎖朝扼。
樂(lè)觀鎖：假定不會(huì)發(fā)生并發(fā)沖突赃阀，只在提交操作時(shí)檢測(cè)是否違反數(shù)據(jù)完整性。（寫(xiě)時(shí)加鎖吟税，使用版本號(hào)或者時(shí)間戳來(lái)配合實(shí)現(xiàn)凹耙，如CAS）.

死鎖

死鎖是指兩個(gè)或兩個(gè)以上的進(jìn)程在執(zhí)行過(guò)程中姿现，因爭(zhēng)奪資源而造成的一種互相等待的現(xiàn)象，若無(wú)外力作用肖抱，他們都將無(wú)法推進(jìn)下去备典。這是一個(gè)嚴(yán)重的問(wèn)題，因?yàn)樗梨i會(huì)讓你的程序掛起無(wú)法完成任務(wù)意述，死鎖的發(fā)生必須滿足一下4個(gè)條件：

• 互斥條件：一個(gè)資源每次只能被一個(gè)進(jìn)程使用提佣。
• 請(qǐng)求與保持條件：一個(gè)進(jìn)程因請(qǐng)求資源而阻塞時(shí)，對(duì)已獲得的資源保持不放荤崇。
• 不剝奪條件：進(jìn)程已獲得的資源拌屏，在未使用完之前，不能強(qiáng)行剝奪术荤。
• 循環(huán)等待條件：若干進(jìn)程之間形成一種頭尾相接的循環(huán)等待資源關(guān)系倚喂。

避免死鎖最簡(jiǎn)單的方法就是破壞循環(huán)等待條件。

活鎖

LiveLock是一種形式活躍性問(wèn)題瓣戚，該問(wèn)題盡管不會(huì)阻塞線程端圈，但也不能繼續(xù)執(zhí)行，因?yàn)榫€程將不斷重復(fù)執(zhí)行相同的操作子库，而且總會(huì)失敗舱权。當(dāng)多個(gè)相互協(xié)作的線程都對(duì)彼此進(jìn)行響應(yīng)從而修改各自的狀態(tài)，并使得任何一個(gè)線程都無(wú)法繼續(xù)執(zhí)行時(shí)仑嗅，就發(fā)生了活鎖宴倍。這就像兩個(gè)過(guò)于禮貌的人在半路上面對(duì)面地相遇：他們彼此都給對(duì)方讓路，然而又在另一條路上相遇仓技，就這樣反復(fù)里避讓下去鸵贬，導(dǎo)致誰(shuí)也過(guò)不去。

讀寫(xiě)鎖浑彰、共享鎖和排它鎖恭理、互斥鎖

略。