定義:
獨佔鎖是一種悲觀保守的加鎖策略,它避免了讀/讀衝突,若是某個只讀線程獲取鎖,則其餘讀線程都只能等待,這種狀況下就限制了沒必要要的併發性,由於讀操做並不會影響數據的一致性。
共享鎖則是一種樂觀鎖,它放寬了加鎖策略,容許多個執行讀操做的線程同時訪問共享資源。
分類:
獨佔鎖:
ReentrantLock, ReentrantReadWriteLock.WriteLock
共享鎖
:ReentrantReadWriteLock.ReadLock,CyclicBarrier, CountDownLatch和Semaphore都是共享鎖
其餘:
wait(), notify() @hxx,對應Contition的 await 和 signal
前者是object,在代碼中用鎖對象便可調用,後者是一個便可,必須使用ReentrantLock生成
final Lock lock = new ReentrantLock();
final Condition notFull = lock.newCondition();
final Condition notEmpty = lock.newCondition();
Synchronized
ReentrantLock是Synchronized一種更高級的改進
1: 更加面向對象,性能更好
2: 提供了更多機制,好比時間鎖等候,可中斷鎖等候,鎖投票等
3: ReentrantLock提供了可輪詢的鎖請求,提供tryLock()方法;而synchronized則會一直阻塞等待
Lock lock = ...;
if (lock.tryLock()) {
try {
// manipulate protected state
} finally {
lock.unlock();
}
} else {
// 資源正在被別人寫,先作別的事情吧,好比說打印一行日誌
}
注意事項:
除了Synchronized自動走出鎖範圍,其他佔有了鎖,必定要記得釋放鎖,能夠在finally中釋放!!!!
公平參數,默認都是關閉的,因此不要覺得等的時間越長就能更大概率得到鎖!公平和非公平對應着:公平鎖和非公平鎖(Sync類的兩個子類),非公平鎖無視等待隊列,直接上來就是搶!
java實現鎖的底層都是使用Sync類,private final Sync sync;
是繼承了AbstractQueuedSynchronizer的內部抽象類,主要由它負責實現鎖的功能。關於 AbstractQueuedSynchronizer 只要知道它內部存在一個獲取鎖的等待隊列及其互斥鎖狀態下的int狀態位(0當前沒有線程持有該鎖、n存在某線程重入鎖n次)便可,該狀態位也可用於其它諸如共享鎖、信號量等功能。
----------------------------------------
Demo code:
1: CountDownLatch
用於n個線程等待其他M個線程結束, 類位於java.util.concurrent包下
代碼:
CountDownLatch doneSignal = new CountDownLatch(3); // 定義了計數器爲3.表示有3個線程結束便可!
for(int i=0; i<5; i++)
new InnerThread().start(); //
m個線程,InnerThread的run方法末尾中寫了doneSignal .countDown(); 必須手動減
doneSignal.await();
// 阻塞,直到3個線程結束
// await(long timeout, TimeUnit unit) throws InterruptedException { }; 這個就能夠實現超時功能
2: CyclicBarrier
java.util.concurrent包,實現 M 個線程在barrier柵欄處互相等待,能夠重用狀態(因此叫cycli),1的計數器只能減不能從新賦值!
代碼:
CyclicBarrier barrier = new CyclicBarrier(N);//
N個線程互相等
for(int i=0;i<N;i++)
new Writer(barrier).start(); // Writer
的run方法須要M個線程一塊兒完成的點中寫了barrier.await();
3: Semaphore
java.util.concurrent包,用於限制最多M個線程同時併發
代碼:
int N = 8;
//工人數
Semaphore semaphore = new Semaphore(5);
//機器數目, 限制了最多5個併發, 默認是不公平的構造能夠加true
for(int i=0;i<N;i++)
new Worker(i,semaphore).start();
@Override
public void run() {
try {
semaphore.acquire();
// 拿憑證,總共5張憑證,沒拿到會阻塞, 不想阻塞可用tryAcquire
System.out.println("工人"+this.num+"佔用一個機器在生產...");
Thread.sleep(2000);
System.out.println("工人"+this.num+"釋放出機器");
semaphore.release();
// 釋放憑證
} catch (InterruptedException e) {
e.printStackTrace();
}
}
4: ReentrantLock
java.util.concurrent包,用於實現同步功能,與synchronized類似可是面向對象更靈活
ReentrantLock takeLock = new ReentrantLock();
// 獲取鎖
takeLock.lock();
try {
// 業務邏輯
} finally {
// 釋放鎖
takeLock.unlock();
}
5: ReentrantReadWriteLock
4是其父類,根據名字能夠看到這個類區分了讀寫鎖,與4的優點是線程大多在數據結構中讀取數據而少有修改時這個就有用了。
讀寫鎖要實現的功能是三點: 多個讀互相不干擾;多個寫操做必須獨佔鎖;讀和寫操做要上鎖!(@hxx第一個分號我我爲何要用黑色,由於這就是讀寫鎖出現的意義,提高了讀的性能,否則就用4了)
如何實現的呢? 看先代碼!
如下這段代碼來自jdk文檔中demo,寫的很是好!!
class CachedData { Object data; volatile boolean cacheValid; ReentrantReadWriteLock rwl = new ReentrantReadWriteLock(); void processCachedData() { rwl.readLock().lock();
//step1 @hxx 任何人均可以讀數據,由於沒人寫,提升性能 if (!cacheValid) { // @hxx 若是有緩存了,就不用去load數據庫寫緩存了,至關於if(cache.get(key) == null) // Must release read lock before acquiring write lock rwl.readLock().unlock(); // @hxx 爲何 拿「寫鎖」 前要釋放掉 「讀鎖」?? 要判斷沒有人拿 「讀鎖」 才能夠寫嗎,是這樣實現讀寫互斥的嗎? 若是是,那麼我在這裏不釋放,是否是就違背了機制,try後,確實是的 rwl.writeLock().lock();
// @hxx 從這裏開始,保證一次只有一個線程進來啦 begin!! // Recheck state because another thread might have acquired // write lock and changed state before we did. if (!cacheValid) { data = ... cacheValid = true; } // Downgrade by acquiring read lock before releasing write lock
// @hxx,我先那個讀鎖,哈哈, 在我釋放讀鎖以前,誰也別想拿寫鎖,由於寫鎖拿到的前提是沒有人拿讀鎖 rwl.readLock().lock(); rwl.writeLock().unlock(); // Unlock write, still hold read
// @hxx 從這裏開始,保證一次只有一個線程進來啦 end!! } use(data); // step2 @hxx 我在讀數據不怕別人寫,真的爽! rwl.readLock().unlock(); // @hxx 如今我釋放了讀鎖,去拿寫鎖吧! } }
ps: 上面代碼。緩存一旦初始化成功後,後續的邏輯就只會走
step1 + step2 了,就只有讀鎖共享了!
6: ReentrantReadWriteLock.ReadLock 和ReentrantReadWriteLock.WriteLock
看jdk文檔裏面。覺得又是一個新的東西,其實就是5中代碼
ReentrantReadWriteLock.writeLock() 返回的對象
ReentrantReadWriteLock.readLock() 返回的對象
略過
7: wait(), notify()
java.lang.Object 的方法
8: Condition接口 (須要與ReentrantLock配合使用)
條件變量很大一個程度上是爲了解決Object.wait/notify/notifyAll難以使用的問題,@hxx也就是消費者生產者代碼中判斷隊列是否滿,是否空的條件!
代碼以下:
final Lock lock = new ReentrantLock();
final Condition notFull = lock.newCondition();
final Condition notEmpty = lock.newCondition();
private Queue<Integer> buffer = new LinkedList<>();
int max = 100;
int putptr, takeptr, count;
public void put(Object x) throws InterruptedException {
lock.lock();
// 先拿鎖
try {
while (max == buffer.size())
notFull.await();
// 不滿,則能夠放
buffer.add(1);
// 提醒能夠取
notEmpty.signal();
} finally {
// 記得釋放鎖
lock.unlock();
}
}
public Object take() throws InterruptedException {
lock.lock();
try {
while (count == 0)
notEmpty.await();
//不空, 能夠取
int x= buffer.poll();
// 提醒可放
notFull.signal();
return x;
} finally {
lock.unlock();
}
}