CountDownLatch

實(shí)現(xiàn)原理

CountDownLatch使用構(gòu)造函數(shù)給AQS中的status賦值，調(diào)用await()方法的線程會進(jìn)行AQS中的等待隊(duì)列中，然后調(diào)用countDown()方法的線程會對status進(jìn)行-1，直到status=0時喚醒AQS等待隊(duì)列中的線程 使用場景

CountDownLatch中調(diào)用await方法線程需要等待所有調(diào)用countDown方法的線程執(zhí)行，這就很適合一個業(yè)務(wù)需要一些準(zhǔn)備條件，等準(zhǔn)備條件準(zhǔn)備好之后再繼續(xù)執(zhí)行，如果一些復(fù)雜的聚合查詢，還有一些類似于廣播消息的功能。

CountDownLatch 構(gòu)造函數(shù)

public CountDownLatch(int count) {
if (count < 0) throw new IllegalArgumentException("count < 0");
this.sync = new Sync(count);
}

這個構(gòu)造器沒有干別的，就是給state變量賦值。

countDown()方法

public voidcountDown(){
sync.releaseShared(1);
}
 
public final boolean releaseShared(int arg){
if(tryReleaseShared(arg)){
doReleaseShared();
return true;
}
return false;
}
 
protected boolean tryReleaseShared(int releases){
// Decrement count; signal when transition to zero
for(;;){
int c =getState();
if(c ==0)
return false;
int nextc = c-1;
if(compareAndSetState(c, nextc))
return nextc ==0;
}
}
 

實(shí)際上CountDownLatch就是通過覆蓋tryReleaseShared方法來給state-1，然后返回state是不是等于0了，等于0了就調(diào)用doReleaseShared();方法unpark等待隊(duì)列中的線程，也就是調(diào)用await()方法的線程

await()方法

public voidawait() throws InterruptedException {
sync.acquireSharedInterruptibly(1);
}

實(shí)際上就是通過tryAcquireShared方法判斷state是不是等于0，是的話返回1，不是的話返回-1，當(dāng)返回-1時就說明countDown方法調(diào)用的不到構(gòu)造器賦值的數(shù)量，則進(jìn)入AQS等待隊(duì)列中，直到countDown方法調(diào)用到賦值的數(shù)量被unpark。

CountDownLatch使用的是SHARED節(jié)點(diǎn)，當(dāng)head的下一個節(jié)點(diǎn)被unpark并獲取到資源時會繼續(xù)喚醒下一個節(jié)點(diǎn)，使得調(diào)用await方法的線程看似是同時被喚醒

CyclicBarrier

感覺這個類沒什么使用場景，他有兩個構(gòu)造器：一個是傳同時運(yùn)行線程的數(shù)量，一個是傳同時運(yùn)行線程的數(shù)量和達(dá)到規(guī)定數(shù)量后運(yùn)行的Runable的run方法，實(shí)在是沒想到什么場景下會用。

實(shí)現(xiàn)原理

在初始化時傳入count值，在每次調(diào)用await方法時會count--,當(dāng)count還大于0時使用當(dāng)前l(fā)ock的condition的await方法讓當(dāng)前線程進(jìn)入到condition的等待隊(duì)列中，當(dāng)count等于0時執(zhí)行構(gòu)造器中傳入的Runable的run方法，然后再調(diào)用condition的signalAll方法喚醒condition等待線程中所有等待的線程，再把count重置為初始值，然后所有線程都繼續(xù)執(zhí)行，看起來就像count數(shù)量的線程一批一批的執(zhí)行，所以實(shí)際上cyclicBarrier就是借助了ReentrantLock的condition的await方法讓線程進(jìn)行等待count數(shù)量的線程就位，然后使用condition的signalAll方法通知所有線程一起執(zhí)行，最后重置count如此往復(fù)。

semaphore

semaphore一個典型的用戶場景就是限流，像hystrix就是提供了兩種限流方式：線程池和semaphore。semaphore允許規(guī)定數(shù)量的線程同時運(yùn)行，但超過后的線程就需要等待前面的某個線程執(zhí)行完后才能執(zhí)行。這就很適合做限流

實(shí)現(xiàn)原理

首先回顧一下鎖的實(shí)現(xiàn)原理：當(dāng)state是0時線程可以加鎖成功，state就是代表同一線程的加鎖次數(shù)（讀寫鎖次數(shù)含義會不一樣），不是同一個線程加鎖時只要state不是0就要進(jìn)入AQS等待隊(duì)列中進(jìn)行park，釋放鎖時state--，直到state等于0后去喚醒AQD等待隊(duì)列中的線程

semaphore則有點(diǎn)跟加鎖過程相反：先給state賦值為允許同時運(yùn)行的線程數(shù)，當(dāng)有線程調(diào)用acquire()方法時state--，直到state為0再有線程調(diào)用acquire()方法時要進(jìn)入AQS等待隊(duì)列中進(jìn)行park，直到有之前的線程調(diào)用release()方法給state++去喚醒AQS等待隊(duì)列中的線程

到此這篇關(guān)于Java中的CountDownLatch、CyclicBarrier和semaphore實(shí)現(xiàn)原理詳解的文章就介紹到這了,更多相關(guān)CountDownLatch、CyclicBarrier和semaphore原理內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論