Ⅰ 自旋鎖和互斥鎖的區別 java中lock Syntronized區別
自旋鎖(Spin lock)
自旋鎖與互斥鎖有點類似，只是自旋鎖不會引起調用者睡眠，如果自旋鎖已經被別的執行單元保持，調用者就一直循環在那裡看是
否該自旋鎖的保持者已經釋放了鎖，"自旋"一詞就是因此而得名。其作用是為了解決某項資源的互斥使用。因為自旋鎖不會引起調用者睡眠，所以自旋鎖的效率遠
高於互斥鎖。雖然它的效率比互斥鎖高，但是它也有些不足之處：
1、自旋鎖一直佔用CPU，他在未獲得鎖的情況下，一直運行－－自旋，所以佔用著CPU，如果不能在很短的時 間內獲得鎖，這無疑會使CPU效率降低。
2、在用自旋鎖時有可能造成死鎖，當遞歸調用時有可能造成死鎖，調用有些其他函數也可能造成死鎖，如 _to_user()、_from_user()、kmalloc()等。
因此我們要慎重使用自旋鎖，自旋鎖只有在內核可搶占式或SMP的情況下才真正需要，在單CPU且不可搶占式的內核下，自旋鎖的操作為空操作。自旋鎖適用於鎖使用者保持鎖時間比較短的情況下。
兩種鎖的加鎖原理
互斥鎖：線程會從sleep（加鎖）——>running（解鎖），過程中有上下文的切換，cpu的搶占，信號的發送等開銷。
自旋鎖：線程一直是running(加鎖——>解鎖)，死循環檢測鎖的標志位，機制不復雜。
互斥鎖屬於sleep-waiting類型的鎖。例如在一個雙核的機器上有兩個線程(線程A和線程B)，它們分別運行在Core0和
Core1上。假設線程A想要通過pthread_mutex_lock操作去得到一個臨界區的鎖，而此時這個鎖正被線程B所持有，那麼線程A就會被阻塞
(blocking)，Core0 會在此時進行上下文切換(Context
Switch)將線程A置於等待隊列中，此時Core0就可以運行其他的任務(例如另一個線程C)而不必進行忙等待。而自旋鎖則不然，它屬於busy-waiting類型的鎖，如果線程A是使用pthread_spin_lock操作去請求鎖，那麼線程A就會一直在
Core0上進行忙等待並不停的進行鎖請求，直到得到這個鎖為止。
兩種鎖的區別
互斥鎖的起始原始開銷要高於自旋鎖，但是基本是一勞永逸，臨界區持鎖時間的大小並不會對互斥鎖的開銷造成影響，而自旋鎖是死循環檢測，加鎖全程消耗cpu，起始開銷雖然低於互斥鎖，但是隨著持鎖時間，加鎖的開銷是線性增長。
兩種鎖的應用
互斥鎖用於臨界區持鎖時間比較長的操作，比如下面這些情況都可以考慮
1 臨界區有IO操作
2 臨界區代碼復雜或者循環量大
3 臨界區競爭非常激烈
4 單核處理器
至於自旋鎖就主要用在臨界區持鎖時間非常短且CPU資源不緊張的情況下，自旋鎖一般用於多核的伺服器。
lock與Syntronized的區別
轉自自：
java並發之Lock與synchronized的區別
1）Lock是一個介面，而synchronized是Java中的關鍵字，synchronized是內置的語言實現；
2）synchronized在發生異常時，會自動釋放線程佔有的鎖，因此不會導致死鎖現象發生；而Lock在發生異常時，如果沒有主動通過unLock()去釋放鎖，則很可能造成死鎖現象，因此使用Lock時需要在finally塊中釋放鎖；
3）Lock可以讓等待鎖的線程響應中斷，而synchronized卻不行，使用synchronized時，等待的線程會一直等待下去，不能夠響應中斷；
4）通過Lock可以知道有沒有成功獲取鎖，而synchronized卻無法辦到。
5）Lock可以提高多個線程進行讀操作的效率。
在性能上來說，如果競爭資源不激烈，兩者的性能是差不多的，而當競爭資源非常激烈時（即有大量線程同時競爭），此時Lock的性能要遠遠優於synchronized。所以說，在具體使用時要根據適當情況選擇。
兩者在鎖的相關概念上區別：
1.可重入鎖
如果鎖具備可重入性，則稱作為可重入鎖。像synchronized和ReentrantLock都是可重入鎖，可重入性在我看來實際上表明了鎖的分配機制：基於線程的分配，而不是基於方法調用的分配。舉個簡單的例子，當一個線程執行到某個synchronized方法時，比如說method1，而在method1中會調用另外一個synchronized方法method2，此時線程不必重新去申請鎖，而是可以直接執行方法method2。
看下面這段代碼就明白了：
1
2
3
4
5
6
7
8
9
class MyClass
{
public synchronized void method1()
{
method2();
}
public synchronized void method2()
{
}
}
上述代碼中的兩個方法method1和method2都用synchronized修飾了，假如某一時刻，線程A執行到了method1，此時線程A獲取了這個對象的鎖，而由於method2也是synchronized方法，假如synchronized不具備可重入性，此時線程A需要重新申請鎖。但是這就會造成一個問題，因為線程A已經持有了該對象的鎖，而又在申請獲取該對象的鎖，這樣就會線程A一直等待永遠不會獲取到的鎖。
而由於synchronized和Lock都具備可重入性，所以不會發生上述現象。
2.可中斷鎖
可中斷鎖：顧名思義，就是可以相應中斷的鎖。
在Java中，synchronized就不是可中斷鎖，而Lock是可中斷鎖。
如果某一線程A正在執行鎖中的代碼，另一線程B正在等待獲取該鎖，可能由於等待時間過長，線程B不想等待了，想先處理其他事情，我們可以讓它中斷自己或者在別的線程中中斷它，這種就是可中斷鎖。
在前面演示lockInterruptibly()的用法時已經體現了Lock的可中斷性。
3.公平鎖
公平鎖即盡量以請求鎖的順序來獲取鎖。比如同是有多個線程在等待一個鎖，當這個鎖被釋放時，等待時間最久的線程（最先請求的線程）會獲得該所，這種就是公平鎖。
非公平鎖即無法保證鎖的獲取是按照請求鎖的順序進行的。這樣就可能導致某個或者一些線程永遠獲取不到鎖。
在Java中，synchronized就是非公平鎖，它無法保證等待的線程獲取鎖的順序。
而對於ReentrantLock和ReentrantReadWriteLock，它默認情況下是非公平鎖，但是可以設置為公平鎖。
看一下這2個類的源代碼就清楚了：
在ReentrantLock中定義了2個靜態內部類，一個是NotFairSync，一個是FairSync，分別用來實現非公平鎖和公平鎖。
我們可以在創建ReentrantLock對象時，通過以下方式來設置鎖的公平性：
1
ReentrantLock
lock = new ReentrantLock(true);
如果參數為true表示為公平鎖，為fasle為非公平鎖。默認情況下，如果使用無參構造器，則是非公平鎖。
另外在ReentrantLock類中定義了很多方法，比如：
isFair() //判斷鎖是否是公平鎖
isLocked() //判斷鎖是否被任何線程獲取了
isHeldByCurrentThread() //判斷鎖是否被當前線程獲取了
hasQueuedThreads() //判斷是否有線程在等待該鎖
在ReentrantReadWriteLock中也有類似的方法，同樣也可以設置為公平鎖和非公平鎖。不過要記住，ReentrantReadWriteLock並未實現Lock介面，它實現的是ReadWriteLock介面。
4.讀寫鎖
讀寫鎖將對一個資源（比如文件）的訪問分成了2個鎖，一個讀鎖和一個寫鎖。
正因為有了讀寫鎖，才使得多個線程之間的讀操作不會發生沖突。
ReadWriteLock就是讀寫鎖，它是一個介面，ReentrantReadWriteLock實現了這個介面。
可以通過readLock()獲取讀鎖，通過writeLock()獲取寫鎖。
性能比較
在JDK1.5中，synchronized是性能低效的。因為這是一個重量級操作，它對性能最大的影響是阻塞的是實現，掛起線程和恢復線程的操作都需要轉入內核態中完成，這些操作給系統的並發性帶來了很大的壓力。相比之下使用Java提供的Lock對象，性能更高一些。Brian
Goetz對這兩種鎖在JDK1.5、單核處理器及雙Xeon處理器環境下做了一組吞吐量對比的實驗，發現多線程環境下，synchronized的吞吐量下降的非常嚴重，而ReentrankLock則能基本保持在同一個比較穩定的水平上。但與其說ReetrantLock性能好，倒不如說synchronized還有非常大的優化餘地，於是到了JDK1.6，發生了變化，對synchronize加入了很多優化措施，有自適應自旋，鎖消除，鎖粗化，輕量級鎖，偏向鎖等等。導致在JDK1.6上synchronize的性能並不比Lock差。官方也表示，他們也更支持synchronize，在未來的版本中還有優化餘地，所以還是提倡在synchronized能實現需求的情況下，優先考慮使用synchronized來進行同步。
Ⅱ 線程同步互斥鎖和讀寫鎖的區別和各自適用場景
讀寫鎖特點：
1）多個讀者可以同時進行讀
2）寫者必須互斥（只允許一個寫者寫，也不能讀者寫者同時進行）
3）寫者優先於讀者（一旦有寫者，則後續讀者必須等待，喚醒時優先考慮寫者）
互斥鎖特點：
一次只能一個線程擁有互斥鎖，其他線程只有等待
自旋鎖：
一次只能有一個進程進入臨界區，讀寫鎖是自旋鎖的一個特例。
應用場景：
以隊列操作為例：
線程A對隊列負責將數據寫入隊列。須採取「互斥鎖」或「讀寫鎖的寫鎖」
線程B隊列負責從隊列讀出數據。須採取「互斥鎖」或「讀寫鎖的寫鎖」，讀隊列操作，不可採取「讀寫鎖的讀鎖」，因為從隊列讀出數據時，需要更改隊列本身的下標索引，如果多個線程同時操作該隊列的話，就會導致隊列下標索引混亂。
Ⅲ POS線程同步互斥鎖和讀寫鎖的區別和各自適用場景
線程同步的方式包括：互斥鎖、讀寫鎖、條件變數、信號量和令牌。
以Java語言為例：
用synchronized關鍵字修飾同步方法。
同步有幾種實現方法分別是synchronized,wait與notify
wait():使一個線程處於等待狀態，並且釋放所持有的對象的lock。
sleep():使一個正在運行的線程處於睡眠狀態，是一個靜態方法，調用此方法要捕捉InterruptedException異常。
notify():喚醒一個處於等待狀態的線程，注意的是在調用此方法的時候，並不能確切的喚醒某一個等待狀態的線程，而是由JVM確定喚醒哪個線程，而且不是按優先順序。
Allnotity():喚醒所有處入等待狀態的線程，注意並不是給所有喚醒線程一個對象的鎖，而是讓它們競爭。
同步是多線程中的重要概念。同步的使用可以保證在多線程運行的環境中，程序不會產生設計之外的錯誤結果。同步的實現方式有兩種，同步方法和同步塊，這兩種方式都要用到synchronized關鍵字。
給一個方法增加synchronized修飾符之後就可以使它成為同步方法，這個方法可以是靜態方法和非靜態方法，但是不能是抽象類的抽象方法，也不能是介面中的介面方法。下面代碼是一個同步方法的示例：
public synchronized void aMethod() {
// do something
}
public static synchronized void anotherMethod() {
// do something
}
線程在執行同步方法時是具有排它性的。當任意一個線程進入到一個對象的任意一個同步方法時，這個對象的所有同步方法都被鎖定了，在此期間，其他任何線程都不能訪問這個對象的任意一個同步方法，直到這個線程執行完它所調用的同步方法並從中退出，從而導致它釋放了該對象的同步鎖之後。在一個對象被某個線程鎖定之後，其他線程是可以訪問這個對象的所有非同步方法的。
同步塊是通過鎖定一個指定的對象，來對同步塊中包含的代碼進行同步；而同步方法是對這個方法塊里的代碼進行同步，而這種情況下鎖定的對象就是同步方法所屬的主體對象自身。如果這個方法是靜態同步方法呢？那麼線程鎖定的就不是這個類的對象了，也不是這個類自身，而是這個類對應的java.lang.Class類型的對象。同步方法和同步塊之間的相互制約只限於同一個對象之間，所以靜態同步方法只受它所屬類的其它靜態同步方法的制約，而跟這個類的實例（對象）沒有關系。
Ⅳ java 鎖有幾種
樂觀鎖/悲觀鎖
樂觀鎖與悲觀鎖不是指具體的什麼類型的鎖，而是指看待並發同步的角度。
悲觀鎖認為對於同一個數據的並發操作，一定是會發生修改的，哪怕沒有修改，也會認為修改。因此對於同一個數據的並發操作，悲觀鎖採取加鎖的形式。悲觀的認為，不加鎖的並發操作一定會出問題。
樂觀鎖則認為對於同一個數據的並發操作，是不會發生修改的。在更新數據的時候，會採用嘗試更新，不斷重新的方式更新數據。樂觀的認為，不加鎖的並發操作是沒有事情的。
從上面的描述我們可以看出，悲觀鎖適合寫操作非常多的場景，樂觀鎖適合讀操作非常多的場景，不加鎖會帶來大量的性能提升。
公平鎖/非公平鎖
公平鎖是指多個線程按照申請鎖的順序來獲取鎖。
非公平鎖是指多個線程獲取鎖的順序並不是按照申請鎖的順序，有可能後申請的線程比先申請的線程優先獲取鎖。
優點：在於吞吐量比公平鎖大。
缺點：可能會造成優先順序反轉或者某些線程飢餓現象(一直拿不到鎖)。
對於Java ReentrantLock而言，通過構造函數指定該鎖是否是公平鎖，默認是非公平鎖。
對於Synchronized而言，也是一種非公平鎖。由於其並不像ReentrantLock是通過AQS的來實現線程調度，所以並沒有任何辦法使其變成公平鎖。
可重入鎖
可重入鎖的概念是自己可以再次獲取自己的內部鎖。
舉個例子，比如一條線程獲得了某個對象的鎖，此時這個對象鎖還沒有釋放，當其再次想要獲取這個對象的鎖的時候還是可以獲取的（如果不可重入的鎖的話，此刻會造成死鎖）。說的更高深一點可重入鎖是一種遞歸無阻塞的同步機制。
對於Java ReentrantLock而言, 他的名字就可以看出是一個可重入鎖，其名字是Re entrant Lock重新進入鎖。
對於Synchronized而言,也是一個可重入鎖。可重入鎖的一個好處是可一定程度避免死鎖。
獨享鎖/共享鎖
獨享鎖是指該鎖一次只能被一個線程所持有。
共享鎖是指該鎖可被多個線程所持有。
對於Java ReentrantLock（互斥鎖）而言，其是獨享鎖。
但是對於Lock的另一個實現類ReadWriteLock（讀寫鎖），其讀鎖是共享鎖，其寫鎖是獨享鎖。讀鎖的共享鎖可保證並發讀是非常高效的，讀寫，寫讀 ，寫寫的過程是互斥的。
對於Synchronized而言，當然是獨享鎖。
分段鎖
分段鎖其實是一種鎖的設計，並不是具體的一種鎖。對於ConcurrentHashMap而言，其並發的實現就是通過分段鎖的形式來實現高效的並發操作。
我們以ConcurrentHashMap來說一下分段鎖的含義以及設計思想，ConcurrentHashMap中的分段鎖稱為Segment，它即類似於HashMap（JDK7與JDK8中HashMap的實現）的結構，即內部擁有一個Entry數組，數組中的每個元素又是一個鏈表；同時又是一個ReentrantLock（Segment繼承了ReentrantLock)。
當需要put元素的時候，並不是對整個hashmap進行加鎖，而是先通過hashcode來知道他要放在那一個分段中，然後對這個分段進行加鎖，所以當多線程put的時候，只要不是放在一個分段中，就實現了真正的並行的插入。
但是，在統計size的時候，可就是獲取hashmap全局信息的時候，就需要獲取所有的分段鎖才能統計。
分段鎖的設計目的是細化鎖的粒度，當操作不需要更新整個數組的時候，就僅僅針對數組中的一項進行加鎖操作。
互斥鎖：
無法獲取瑣時，進線程立刻放棄剩餘的時間片並進入阻塞（或者說掛起）狀態，同時保存寄存器和程序計數器的內容（保存現場，上下文切換的前半部分），當可以獲取鎖時，進線程激活，等待被調度進CPU並恢復現場（上下文切換下半部分）
上下文切換會帶來數十微秒的開銷，不要在性能敏感的地方用互斥鎖
讀寫鎖：
1）多個讀者可以同時進行讀
2）寫者必須互斥（只允許一個寫者寫，也不能讀者寫者同時進行）
3）寫者優先於讀者（一旦有寫者，則後續讀者必須等待，喚醒時優先考慮寫者）
自旋鎖：
自旋鎖是指嘗試獲取鎖的線程不會立即阻塞，而是採用循環的方式去嘗試獲取鎖，這樣的好處是減少線程上下文切換的消耗，缺點是循環會消耗CPU。
Ⅳ java中讀鎖的作用,為什麼要用讀鎖
讀寫鎖：ReentrantReadWriteLock
如果有很多線程從一個數據結構中讀取數據，而很少的線程修改數據，那麼就用讀寫鎖。
分別得到讀鎖和寫鎖：
ReentrantReadWriteLock rrwl=new ReentrantReadWriteLock();
ReadLock readL = rrwl.readLock();
WriteLock writeL = rrwl.writeLock();
讀鎖與讀鎖不互斥，讀鎖與寫鎖互斥，寫鎖與寫鎖互斥。
用於優化性能，提高讀寫速度。
Ⅵ Java鎖有哪些種類，以及區別
一、公平鎖/非公平鎖
公平鎖是指多個線程按照申請鎖的順序來獲取鎖。
非公平鎖是指多個線程獲取鎖的順序並不是按照申請鎖的順序，有可能後申請的線程比先申請的線程優先獲取鎖。有可能，會造成優先順序反轉或者飢餓現象。
對於Java ReentrantLock而言，通過構造函數指定該鎖是否是公平鎖，默認是非公平鎖。非公平鎖的優點在於吞吐量比公平鎖大。
對於Synchronized而言，也是一種非公平鎖。由於其並不像ReentrantLock是通過AQS的來實現線程調度，所以並沒有任何辦法使其變成公平鎖。
二、可重入鎖
可重入鎖又名遞歸鎖，是指在同一個線程在外層方法獲取鎖的時候，在進入內層方法會自動獲取鎖。說的有點抽象，下面會有一個代碼的示例。
對於Java ReentrantLock而言, 他的名字就可以看出是一個可重入鎖，其名字是Re entrant Lock重新進入鎖。
對於Synchronized而言,也是一個可重入鎖。可重入鎖的一個好處是可一定程度避免死鎖。
synchronized void setA() throws Exception{
Thread.sleep(1000);
setB();
}
synchronized void setB() throws Exception{
Thread.sleep(1000);
}
上面的代碼就是一個可重入鎖的一個特點，如果不是可重入鎖的話，setB可能不會被當前線程執行，可能造成死鎖。
三、獨享鎖/共享鎖
獨享鎖是指該鎖一次只能被一個線程所持有。
共享鎖是指該鎖可被多個線程所持有。
對於Java
ReentrantLock而言，其是獨享鎖。但是對於Lock的另一個實現類ReadWriteLock，其讀鎖是共享鎖，其寫鎖是獨享鎖。
讀鎖的共享鎖可保證並發讀是非常高效的，讀寫，寫讀 ，寫寫的過程是互斥的。
獨享鎖與共享鎖也是通過AQS來實現的，通過實現不同的方法，來實現獨享或者共享。
對於Synchronized而言，當然是獨享鎖。
四、互斥鎖/讀寫鎖
上面講的獨享鎖/共享鎖就是一種廣義的說法，互斥鎖/讀寫鎖就是具體的實現。
互斥鎖在Java中的具體實現就是ReentrantLock
讀寫鎖在Java中的具體實現就是ReadWriteLock
五、樂觀鎖/悲觀鎖
樂觀鎖與悲觀鎖不是指具體的什麼類型的鎖，而是指看待並發同步的角度。
悲觀鎖認為對於同一個數據的並發操作，一定是會發生修改的，哪怕沒有修改，也會認為修改。因此對於同一個數據的並發操作，悲觀鎖採取加鎖的形式。悲觀的認為，不加鎖的並發操作一定會出問題。
樂觀鎖則認為對於同一個數據的並發操作，是不會發生修改的。在更新數據的時候，會採用嘗試更新，不斷重新的方式更新數據。樂觀的認為，不加鎖的並發操作是沒有事情的。
從上面的描述我們可以看出，悲觀鎖適合寫操作非常多的場景，樂觀鎖適合讀操作非常多的場景，不加鎖會帶來大量的性能提升。
悲觀鎖在Java中的使用，就是利用各種鎖。
樂觀鎖在Java中的使用，是無鎖編程，常常採用的是CAS演算法，典型的例子就是原子類，通過CAS自旋實現原子操作的更新。
六、分段鎖
分段鎖其實是一種鎖的設計，並不是具體的一種鎖，對於ConcurrentHashMap而言，其並發的實現就是通過分段鎖的形式來實現高效的並發操作。
我們以ConcurrentHashMap來說一下分段鎖的含義以及設計思想，ConcurrentHashMap中的分段鎖稱為Segment，它即類似於HashMap(JDK7與JDK8中HashMap的實現)的結構，即內部擁有一個Entry數組，數組中的每個元素又是一個鏈表;同時又是一個ReentrantLock(Segment繼承了ReentrantLock)。
當需要put元素的時候，並不是對整個hashmap進行加鎖，而是先通過hashcode來知道他要放在那一個分段中，然後對這個分段進行加鎖，所以當多線程put的時候，只要不是放在一個分段中，就實現了真正的並行的插入。
但是，在統計size的時候，可就是獲取hashmap全局信息的時候，就需要獲取所有的分段鎖才能統計。
分段鎖的設計目的是細化鎖的粒度，當操作不需要更新整個數組的時候，就僅僅針對數組中的一項進行加鎖操作。
七、偏向鎖/輕量級鎖/重量級鎖
這三種鎖是指鎖的狀態，並且是針對Synchronized。在Java
5通過引入鎖升級的機制來實現高效Synchronized。這三種鎖的狀態是通過對象監視器在對象頭中的欄位來表明的。
偏向鎖是指一段同步代碼一直被一個線程所訪問，那麼該線程會自動獲取鎖。降低獲取鎖的代價。
輕量級鎖是指當鎖是偏向鎖的時候，被另一個線程所訪問，偏向鎖就會升級為輕量級鎖，其他線程會通過自旋的形式嘗試獲取鎖，不會阻塞，提高性能。
重量級鎖是指當鎖為輕量級鎖的時候，另一個線程雖然是自旋，但自旋不會一直持續下去，當自旋一定次數的時候，還沒有獲取到鎖，就會進入阻塞，該鎖膨脹為重量級鎖。重量級鎖會讓其他申請的線程進入阻塞，性能降低。
八、自旋鎖
在Java中，自旋鎖是指嘗試獲取鎖的線程不會立即阻塞，而是採用循環的方式去嘗試獲取鎖，這樣的好處是減少線程上下文切換的消耗，缺點是循環會消耗CPU。
典型的自旋鎖實現的例子，可以參考自旋鎖的實現
Ⅶ 在java中有哪些鎖
給你整理了Java中的一些鎖：
公平鎖/非公平鎖
可重入鎖
獨享鎖/共享鎖
互斥鎖/讀寫鎖
樂觀鎖/悲觀鎖
分段鎖
偏向鎖/輕量級鎖/重量級鎖
自旋鎖
上面是很多鎖的名詞，這些分類並不是全是指鎖的狀態，有的指鎖的特性，有的指鎖的設計
Ⅷ java 哪個鎖是非重入的
讀寫鎖 ReadWriteLock讀寫鎖維護了一對相關的鎖，一個用於只讀操作，一個用於寫入操作。只要沒有writer，讀取鎖可以由多個reader線程同時保持。寫入鎖是獨占的。
互斥鎖一次只允許一個線程訪問共享數據，哪怕進行的是只讀操作；讀寫鎖允許對共享數據進行更高級別的並發訪問：對於寫操作，一次只有一個線程（write線程）可以修改共享數據，對於讀操作，允許任意數量的線程同時進行讀取。
與互斥鎖相比，使用讀寫鎖能否提升性能則取決於讀寫操作期間讀取數據相對於修改數據的頻率，以及數據的爭用——即在同一時間試圖對該數據執行讀取或寫入操作的線程數。
讀寫鎖適用於讀多寫少的情況。
可重入讀寫鎖 ReentrantReadWriteLock
屬性ReentrantReadWriteLock 也是基於 AbstractQueuedSynchronizer 實現的，它具有下面這些屬性（來自Java doc文檔）：
* 獲取順序：此類不會將讀取者優先或寫入者優先強加給鎖訪問的排序。
* 非公平模式（默認）：連續競爭的非公平鎖可能無限期地推遲一個或多個reader或writer線程，但吞吐量通常要高於公平鎖。
* 公平模式：線程利用一個近似到達順序的策略來爭奪進入。當釋放當前保持的鎖時，可以為等待時間最長的單個writer線程分配寫入鎖，如果有一組等待時間大於所有正在等待的writer線程的reader，將為該組分配讀者鎖。
* 試圖獲得公平寫入鎖的非重入的線程將會阻塞，除非讀取鎖和寫入鎖都自由（這意味著沒有等待線程）。
* 重入：此鎖允許reader和writer按照 ReentrantLock 的樣式重新獲取讀取鎖或寫入鎖。在寫入線程保持的所有寫入鎖都已經釋放後，才允許重入reader使用讀取鎖。
writer可以獲取讀取鎖，但reader不能獲取寫入鎖。
* 鎖降級：重入還允許從寫入鎖降級為讀取鎖，實現方式是：先獲取寫入鎖，然後獲取讀取鎖，最後釋放寫入鎖。但是，從讀取鎖升級到寫入鎖是不可能的。
* 鎖獲取的中斷：讀取鎖和寫入鎖都支持鎖獲取期間的中斷。
* Condition 支持：寫入鎖提供了一個 Condition 實現，對於寫入鎖來說，該實現的行為與 ReentrantLock.newCondition() 提供的Condition 實現對 ReentrantLock 所做的行為相同。當然，此 Condition 只能用於寫入鎖。
讀取鎖不支持 Condition，readLock().newCondition() 會拋出 UnsupportedOperationException。
* 監測：此類支持一些確定是讀取鎖還是寫入鎖的方法。這些方法設計用於監視系統狀態，而不是同步控制。
實現AQS 回顧在之前的文章已經提到，AQS以單個 int 類型的原子變數來表示其狀態，定義了4個抽象方法（ tryAcquire(int)、tryRelease(int)、tryAcquireShared(int)、tryReleaseShared(int)，前兩個方法用於獨占/排他模式，後兩個用於共享模式 ）留給子類實現，用於自定義同步器的行為以實現特定的功能。
對於 ReentrantLock，它是可重入的獨占鎖，內部的 Sync 類實現了 tryAcquire(int)、tryRelease(int) 方法，並用狀態的值來表示重入次數，加鎖或重入鎖時狀態加 1，釋放鎖時狀態減 1，狀態值等於 0 表示鎖空閑。
對於 CountDownLatch，它是一個關卡，在條件滿足前阻塞所有等待線程，條件滿足後允許所有線程通過。內部類 Sync 把狀態初始化為大於 0 的某個值，當狀態大於 0 時所有wait線程阻塞，每調用一次 countDown 方法就把狀態值減 1，減為 0 時允許所有線程通過。利用了AQS的共享模式。
現在，要用AQS來實現 ReentrantReadWriteLock。
一點思考問題
* AQS只有一個狀態，那麼如何表示 多個讀鎖 與 單個寫鎖 呢？
* ReentrantLock 里，狀態值表示重入計數，現在如何在AQS里表示每個讀鎖、寫鎖的重入次數呢？
* 如何實現讀鎖、寫鎖的公平性呢？
Ⅸ 什麼是讀寫鎖能不能用java語言寫一個讀寫鎖的例子
讀寫鎖實際上分為兩種情形。讀鎖和寫鎖。多個線程准備進入臨界區時，加讀鎖不會阻塞，此時線程都能夠進入臨界區。當有線程在進入臨界區時加了寫鎖，那麼此時寫鎖會與讀鎖互斥，如果有讀鎖存在，則加寫鎖線程阻塞。如果沒有讀鎖存在，線程加寫鎖完成，並進入臨界區。 讀寫鎖可以應付多讀少寫的場景，對於多讀少寫的場景，如果使用排他鎖，顯然所有讀都不能並發完成，效率極低。而使用讀寫鎖，所有寫之間是不互斥的。