1.可重入鎖
如果鎖具備可重入性，則稱作為可重入鎖。
==========================================
這種情況出現在多任務系統當中，在任務執行期間捕捉到信號並對其進行處理時，進程正在執行的指令序列就被信號處理程序臨時中斷。如果從信號處理程序返回，則繼續執行進程斷點處的正常指令序列，從重新恢復到斷點重新執行的過程中，函數所依賴的環境沒有發生改變，就說這個函數是可重入的，反之就是不可重入的。
眾所周知，在進程中斷期間，系統會保存和恢復進程的上下文，然而恢復的上下文僅限於返回地址，cpu寄存器等之類的少量上下文，而函數內部使用的諸如全局或靜態變量，buffer等並不在保護之列，所以如果這些值在函數被中斷期間發生了改變，那么當函數回到斷點繼續執行時，其結果就不可預料了。打個比方，比如malloc，將如一個進程此時正在執行malloc分配堆空間，此時程序捕捉到信號發生中斷，執行信號處理程序中恰好也有一個malloc，這樣就會對進程的環境造成破壞，因為malloc通常為它所分配的存儲區維護一個鏈接表，插入執行信號處理函數時，進程可能正在對這張表進行操作，而信號處理函數的調用剛好覆蓋了進程的操作，造成錯誤。
滿足下面條件之一的多數是不可重入函數：
(1)使用了靜態數據結構;
(2)調用了malloc或free;
(3)調用了標准I/O函數;標准io庫很多實現都以不可重入的方式使用全局數據結構。
(4)進行了浮點運算.許多的處理器/編譯器中，浮點一般都是不可重入的 (浮點運算大多使用協處理器或者軟件模擬來實現)。
1) 信號處理程序A內外都調用了同一個不可重入函數B；B在執行期間被信號打斷，進入A (A中調用了B),完事之后返回B被中斷點繼續執行，這時B函數的環境可能改變，其結果就不可預料了。
2) 多線程共享進程內部的資源，如果兩個線程A，B調用同一個不可重入函數F，A線程進入F后，線程調度，切換到B，B也執行了F，那么當再次切換到線程A時，其調用F的結果也是不可預料的。
在信號處理程序中即使調用可重入函數也有問題要注意。作為一個通用的規則，當在信號處理程序中調用可重入函數時，應當在其前保存errno，並在其后恢復errno。(因為每個線程只有一個errno變量，信號處理函數可能會修改其值，要了解經常被捕捉到的信號是SIGCHLD，其信號處理程序通常要調用一種wait函數，而各種wait函數都能改變errno。)
可重入函數列表:
_exit（）、 access（）、alarm（）、cfgetispeed（）、cfgetospeed（）、cfsetispeed（）、cfsetospeed （）、chdir（）、chmod（）、chown（）、close（）、creat（）、dup（）、dup2（）、execle（）、 execve（）、fcntl（）、fork（）、fpathconf （）、fstat（）、fsync（）、getegid（）、 geteuid（）、getgid（）、getgroups（）、getpgrp（）、getpid（）、getppid（）、getuid（）、 kill（）、link（）、lseek（）、mkdir（）、mkfifo（）、 open（）、pathconf（）、pause（）、pipe（）、raise（）、read（）、rename（）、rmdir（）、setgid （）、setpgid（）、setsid（）、setuid（）、 sigaction（）、sigaddset（）、sigdelset（）、sigemptyset（）、sigfillset（）、 sigismember（）、signal（）、sigpending（）、sigprocmask（）、sigsuspend（）、sleep（）、 stat（）、sysconf（）、tcdrain（）、tcflow（）、tcflush（）、tcgetattr（）、tcgetpgrp（）、 tcsendbreak（）、tcsetattr（）、tcsetpgrp（）、time（）、times（）、 umask（）、uname（）、unlink（）、utime（）、wait（）、waitpid（）、write（）。
書上關於信號處理程序中調用不可重入函數的例子:
#include <stdlib.h>
#include <stdio.h>
#include <pwd.h>
static void func(int signo)
{
struct passwd *rootptr;
if( ( rootptr = getpwnam( "root" ) ) == NULL )
{
err_sys( "getpwnam error" );
}
signal(SIGALRM,func);
alarm(1);
}
int main(int argc, char** argv)
{
signal(SIGALRM,func);
alarm(1);
for(;;)
{
if( ( ptr = getpwnam("sar") ) == NULL )
{
err_sys( "getpwnam error" );
}
}
return 0;
}
signal了一個SIGALRM,而后設置一個定時器，在for函數運行期間的某個時刻，也許就是在getpwnam函數運行期間，相應信號發生中斷，進入信號處理函數func，在運行func期間又收到alarm發出的信號，getpwnam可能再次中斷，這樣就很容易發生不可預料的問題。
==========================================
像synchronized和ReentrantLock都是可重入鎖，可重入性在我看來實際上表明了鎖的分配機制：
基於線程的分配，而不是基於方法調用的分配。
舉個簡單的例子，當一個線程執行到某個synchronized方法時，比如說method1，而在method1中會調用另外一個synchronized方法method2，
此時線程不必重新去申請鎖，而是可以直接執行方法method2。
class MyClass {
public synchronized void method1() {
method2();
}
public synchronized void method2() {
}
}
上述代碼中的兩個方法method1和method2都用synchronized修飾了，
假如某一時刻，線程A執行到了method1，此時線程A獲取了這個對象的鎖，而由於method2也是synchronized方法，假如synchronized不具備可重入性，此時線程A需要重新申請鎖。
但是這就會造成一個問題，因為線程A已經持有了該對象的鎖，而又在申請獲取該對象的鎖，這樣就會線程A一直等待永遠不會獲取到的鎖。
而由於synchronized和ReentrantLock都具備可重入性，所以不會發生上述現象。《可重入鎖》
2.可中斷鎖
可中斷鎖：顧名思義，就是可以相應中斷的鎖。
在Java中，synchronized就不是可中斷鎖，而Lock是可中斷鎖。
如果某一線程A正在執行鎖中的代碼，另一線程B正在等待獲取該鎖，可能由於等待時間過長，線程B不想等待了，想先處理其他事情，我們可以讓它中斷自己或者在別的線程中中斷它，這種就是可中斷鎖。
在前面演示lockInterruptibly()的用法時已經體現了Lock的可中斷性。
3.公平鎖
公平鎖即盡量以請求鎖的順序來獲取鎖。比如同是有多個線程在等待一個鎖，當這個鎖被釋放時，等待時間最久的線程（最先請求的線程）會獲得該所，這種就是公平鎖。
非公平鎖即無法保證鎖的獲取是按照請求鎖的順序進行的。這樣就可能導致某個或者一些線程永遠獲取不到鎖。
在Java中，synchronized就是非公平鎖，它無法保證等待的線程獲取鎖的順序。
而對於ReentrantLock和ReentrantReadWriteLock，它默認情況下是非公平鎖，但是可以設置為公平鎖。這一點由構造函數可知：
1
2 public ReentrantLock() {
3 sync = new NonfairSync();
4 }
5
6
7 public ReentrantLock(boolean fair) {
8 sync = (fair)? new FairSync() : new NonfairSync();
9 }
在ReentrantLock中定義了2個靜態內部類，一個是NotFairSync，一個是FairSync，分別用來實現非公平鎖和公平鎖。
我們可以在創建ReentrantLock對象時，通過知道布爾參數來決定使用 非公平鎖 還是公平鎖
如果參數為true表示為公平鎖，為fasle為非公平鎖。默認情況下，如果使用無參構造器，則是非公平鎖
另外在ReentrantLock類中定義了很多方法，比如：
isFair() //判斷鎖是否是公平鎖
isLocked() //判斷鎖是否被任何線程獲取了
isHeldByCurrentThread() //判斷鎖是否被當前線程獲取了
hasQueuedThreads() //判斷是否有線程在等待該鎖
在ReentrantReadWriteLock中也有類似的方法，同樣也可以設置為公平鎖和非公平鎖。
不過要記住，ReentrantReadWriteLock並未實現Lock接口，它實現的是ReadWriteLock接口。
4.讀寫鎖
讀寫鎖將對一個資源（比如文件）的訪問分成了2個鎖，一個讀鎖和一個寫鎖。
正因為有了讀寫鎖，才使得多個線程之間的讀操作不會發生沖突。
ReadWriteLock就是讀寫鎖，它是一個接口，ReentrantReadWriteLock實現了這個接口。
可以通過readLock()獲取讀鎖，通過writeLock()獲取寫鎖。
CLH隊列鎖
CLH鎖即Craig, Landin, and Hagersten (CLH) locks，CLH鎖是一個自旋鎖，能確保無飢餓性，提供先來先服務的公平性。
CLH鎖也是一種基於鏈表的可擴展、高性能、公平的自旋鎖，申請線程只在本地變量上自旋，它不斷輪詢前驅的狀態，如果發現前驅釋放了鎖就結束自旋。
Memory Access)非一致存儲訪問，將CPU分為CPU模塊，每個CPU模塊由多個CPU組成，並且具有獨立的本地內存、I/O槽口等，模塊之間可以通過互聯模塊相互訪問，訪問本地內存的速度將遠遠高於訪問遠地內存(系統內其它節點的內存)的速度，這也是非一致存儲訪問NUMA的由來。NUMA優點是可以較好地解決原來SMP系統的擴展問題，缺點是由於訪問遠地內存的延時遠遠超過本地內存，因此當CPU數量增加時，系統性能無法線性增加。
CLH算法實現
locked域為false，此時線程A獲取到了鎖。
public class CLHLock implements Lock { AtomicReference<QNode> tail = new AtomicReference<QNode>(new QNode()); ThreadLocal<QNode> myPred; ThreadLocal<QNode> myNode; public CLHLock() { tail = new AtomicReference<QNode>(new QNode()); myNode = new ThreadLocal<QNode>() { protected QNode initialValue() { return new QNode(); } }; myPred = new ThreadLocal<QNode>() { protected QNode initialValue() { return null; } }; } @Override public void lock() { QNode qnode = myNode.get(); qnode.locked = true; QNode pred = tail.getAndSet(qnode); myPred.set(pred); while (pred.locked) { } } @Override public void unlock() { QNode qnode = myNode.get(); qnode.locked = false; myNode.set(myPred.get()); } }
從代碼中可以看出lock方法中有一個while循環，這 是在等待前趨結點的locked域變為false，這是一個自旋等待的過程。unlock方法很簡單，只需要將自己的locked域設置為false即可。
CLH優缺點
自旋鎖（Spin lock）
自旋鎖是指當一個線程嘗試獲取某個鎖時，如果該鎖已被其他線程占用，就一直循環檢測鎖是否被釋放，而不是進入線程掛起或睡眠狀態。
自旋鎖適用於鎖保護的臨界區很小的情況，臨界區很小的話，鎖占用的時間就很短。
簡單的實現
package com.dxz.sync3; import java.util.concurrent.atomic.AtomicReference; public class SpinLock { private AtomicReference<Thread> owner = new AtomicReference<Thread>(); public void lock() { Thread currentThread = Thread.currentThread(); // 如果鎖未被占用，則設置當前線程為鎖的擁有者 while (owner.compareAndSet(null, currentThread)) { } } public void unlock() { Thread currentThread = Thread.currentThread(); // 只有鎖的擁有者才能釋放鎖 owner.compareAndSet(currentThread, null); } }
SimpleSpinLock里有一個owner屬性持有鎖當前擁有者的線程的引用，如果該引用為null，則表示鎖未被占用，不為null則被占用。
這里用AtomicReference是為了使用它的原子性的compareAndSet方法（CAS操作），解決了多線程並發操作導致數據不一致的問題，確保其他線程可以看到鎖的真實狀態。
缺點
- CAS操作需要硬件的配合；
- 保證各個CPU的緩存（L1、L2、L3、跨CPU Socket、主存）的數據一致性，通訊開銷很大，在多處理器系統上更嚴重；
- 沒法保證公平性，不保證等待進程/線程按照FIFO順序獲得鎖。
Ticket Lock
Ticket Lock 是為了解決上面的公平性問題，類似於現實中銀行櫃台的排隊叫號：鎖擁有一個服務號，表示正在服務的線程，還有一個排隊號；每個線程嘗試獲取鎖之前先拿一個排隊號，然后不斷輪詢鎖的當前服務號是否是自己的排隊號，如果是，則表示自己擁有了鎖，不是則繼續輪詢。
當線程釋放鎖時，將服務號加1，這樣下一個線程看到這個變化，就退出自旋。
簡單的實現
缺點
Ticket Lock 雖然解決了公平性的問題，但是多處理器系統上，每個進程/線程占用的處理器都在讀寫同一個變量serviceNum ，每次讀寫操作都必須在多個處理器緩存之間進行緩存同步，這會導致繁重的系統總線和內存的流量，大大降低系統整體的性能。
下面介紹的CLH鎖和MCS鎖都是為了解決這個問題的。
MCS 來自於其發明人名字的首字母： John Mellor-Crummey和Michael Scott。
CLH的發明人是：Craig，Landin and Hagersten。
CLH鎖
CLH鎖也是一種基於鏈表的可擴展、高性能、公平的自旋鎖，申請線程只在本地變量上自旋，它不斷輪詢前驅的狀態，如果發現前驅釋放了鎖就結束自旋。
package com.dxz.sync3; import java.util.concurrent.atomic.AtomicInteger; public class TicketLock { private AtomicInteger serviceNum = new AtomicInteger(); // 服務號 private AtomicInteger ticketNum = new AtomicInteger(); // 排隊號 public int lock() { // 首先原子性地獲得一個排隊號 int myTicketNum = ticketNum.getAndIncrement(); // 只要當前服務號不是自己的就不斷輪詢 while (serviceNum.get() != myTicketNum) { } return myTicketNum; } public void unlock(int myTicket) { // 只有當前線程擁有者才能釋放鎖 int next = myTicket + 1; serviceNum.compareAndSet(myTicket, next); } }
MCS鎖
MCS Spinlock 是一種基於鏈表的可擴展、高性能、公平的自旋鎖，申請線程只在本地變量上自旋，直接前驅負責通知其結束自旋，從而極大地減少了不必要的處理器緩存同步的次數，降低了總線和內存的開銷。
package com.dxz.sync3; import java.util.concurrent.atomic.AtomicReferenceFieldUpdater; public class MCSLock { public static class MCSNode { MCSNode next; boolean isLocked = true; // 默認是在等待鎖 } volatile MCSNode queue;// 指向最后一個申請鎖的MCSNode private static final AtomicReferenceFieldUpdater<MCSLock, MCSNode> UPDATER = AtomicReferenceFieldUpdater .newUpdater(MCSLock.class, MCSNode.class, "queue"); public void lock(MCSNode currentThreadMcsNode) { MCSNode predecessor = UPDATER.getAndSet(this, currentThreadMcsNode);// step // 1 if (predecessor != null) { predecessor.next = currentThreadMcsNode;// step 2 while (currentThreadMcsNode.isLocked) {// step 3 } } } public void unlock(MCSNode currentThreadMcsNode) { if (UPDATER.get(this) == currentThreadMcsNode) {// 鎖擁有者進行釋放鎖才有意義 if (currentThreadMcsNode.next == null) {// 檢查是否有人排在自己后面 if (UPDATER.compareAndSet(this, currentThreadMcsNode, null)) {// step // 4 // compareAndSet返回true表示確實沒有人排在自己后面 return; } else { // 突然有人排在自己后面了，可能還不知道是誰，下面是等待后續者 // 這里之所以要忙等是因為：step 1執行完后，step 2可能還沒執行完 while (currentThreadMcsNode.next == null) { // step 5 } } } currentThreadMcsNode.next.isLocked = false; currentThreadMcsNode.next = null;// for GC } } }
下圖是CLH鎖和MCS鎖隊列圖示：
差異：
- 從代碼實現來看，CLH比MCS要簡單得多。
- 從自旋的條件來看，CLH是在前驅節點的屬性上自旋，而MCS是在本地屬性變量上自旋
- 從鏈表隊列來看，CLH的隊列是隱式的，CLHNode並不實際持有下一個節點；MCS的隊列是物理存在的。
- CLH鎖釋放時只需要改變自己的屬性，MCS鎖釋放則需要改變后繼節點的屬性。
注意：這里實現的鎖（自旋鎖、排隊自旋鎖、MCS鎖、CLH鎖）都是獨占的，且不能重入的。