Tomcat的LimitLatch類用于控制網(wǎng)絡(luò)通信的socket接收上限，在Tomcat7時(shí)引入，實(shí)現(xiàn)簡單，借此可以學(xué)習(xí)一下線程同步的相關(guān)知識(shí)。

LimitLatch依賴內(nèi)部類Sync進(jìn)行線程同步，而Sync繼承自大家熟悉的AbstractQueuedSynchronizer。AQS是java.util.concurrent的核心組件，諸多常用的線程同步工具類都能夠找到他的影子，讀者可以翻閱ReentrantLock、CountDownLatch、Semaphore等類的源碼。

//if we have reached max connections, wait 
countUpOrAwaitConnection(); 
SocketChannel socket = null; 
try { 
      // Accept the next incoming connection from the server socket 
     socket = serverSock.accept(); 
     …… 

不管是NIO還是BIO，Tomcat在接收socket前，都要通過countUpOrAwaitConnection方法獲取資源，如果已經(jīng)達(dá)到***連接數(shù)，則需要當(dāng)前線程等待資源釋放。該方法最終會(huì)調(diào)用到LimitLatch的內(nèi)部類Sync的acquireSharedInterruptibly方法，即AQS的acquireSharedInterruptibly方法。

從內(nèi)部類Sync的重載方法我們能看到Sync是一個(gè)共享模式的同步器，重載了tryAcquireShared和tryReleaseShared兩個(gè)方法，而兩個(gè)方法之所以能夠如此簡單，就是因?yàn)楦割怉QS在背后默默完成了其他所有的排隊(duì)、等待、激活等一系列邏輯。

protected int tryAcquireShared(int ignored) {            
 long newCount = count.incrementAndGet();         
    if (!released && newCount > limit) {//自增后沒有超過資源上限則獲取成功                // Limit exceeded                
       count.decrementAndGet();//資源獲取失敗，回退                
       return -1;         
    } else { 
                return 1;       
      }  
 } 

在獲取共享資源時(shí)，LimitLatch.Sync使用了原子變量AtomicLong，利用其自增的CAS原子操作結(jié)果與設(shè)定的共享資源數(shù)量上限進(jìn)行比較，如果超出上限則目前無法獲取資源，由AQS放入等待隊(duì)列等待下次觸發(fā)。LimitLatch中定義了released屬性，該屬性為true時(shí)，無論如何都會(huì)獲取到共享資源。

public boolean releaseAll() {      
   released = true;//標(biāo)志位置為ture后，后續(xù)均可獲取資源     
    return sync.releaseShared(0);//通知等待線程重新獲取資源   
  } 

這里就有一個(gè)問題了，既然無論如何都會(huì)獲取到資源，LimitLatch就沒有存在的必要，那為何還要這樣一個(gè)看似多余的released 屬性呢?這里其實(shí)考慮到一個(gè)狀態(tài)變更的問題，當(dāng)由一個(gè)LimitLatch控制資源獲取量變更為無需LimitLatch時(shí)，僅僅將LimitLatch置為null從而跳過資源競爭是不夠的。

如果之前存在在等待隊(duì)列中等待資源的線程，而此時(shí)沒有資源釋放，那么在狀態(tài)變更后線程仍然會(huì)處于等待狀態(tài)，這與“***制”的狀態(tài)是不符的，此時(shí)需要將released屬性置為true，然后通過一次資源釋放由AQS觸發(fā)所有等待線程重新獲取資源，這個(gè)時(shí)候所有線程均會(huì)獲取資源立即返回。

protected boolean tryReleaseShared(int arg) {    
         count.decrementAndGet();//自減釋放資源      
       return true;     
    } 

資源釋放時(shí)的代碼就更簡單了，直接將代表資源的原子變量AtomicLong自減從而釋放資源就完成了。而后續(xù)的喚醒等待資源的線程等工作已經(jīng)由AQS代勞了。

寫到這里，問題又來了，這個(gè)功能完全可以由JDK自帶的Semaphore類來完成啊。如果非要再寫一個(gè)那一定是因?yàn)樾阅艿脑蛄?，畢竟該類要使用在接收Socket的前面，對性能有直接影響。下面代碼為Semaphore類(JDK1.8)的FairSync重寫的tryAcquireShared方法，本質(zhì)上與LimitLatch并無什么不同，都是CAS自旋：

protected int tryAcquireShared(int acquires) {             
for (;;) {               
 if (hasQueuedPredecessors())             
       return -1;               
 int available = getState();     
           int remaining = available - acquires;     
           if (remaining < 0 ||                    compareAndSetState(available, remaining))     
               return remaining;          
      } 
   } 

話不多說，開始性能測試，測試場景分為64線程競爭64個(gè)資源以及64線程競爭32個(gè)資源，循環(huán)300w次。測試結(jié)果竟然是LimitLatch性能要比Semaphore性能低近10%左右，這個(gè)。。。一定是我打開的方式不對。

我們回顧一下，當(dāng)前使用的環(huán)境為Windows，JDK版本為1.8，而tomcat7引入LimitLatch的時(shí)候正是JDK1.6橫行的時(shí)代。筆者將JDK切換到1.6進(jìn)行測試，果然結(jié)果變?yōu)閮烧卟幌嗌舷?而后將測試代碼上傳到了服務(wù)器，在Linux、JDK1.6環(huán)境下重新測試，結(jié)果LimitLatch扭轉(zhuǎn)乾坤，反超Semaphore性能20%左右，切換到JDK1.8性能領(lǐng)先Semaphore約40%!很明顯Tomcat更注重的是Linux服務(wù)器下的性能，至于兩者性能對比結(jié)果在不同環(huán)境下不同的原因，歡迎各位大牛一起討論。

【本文為51CTO專欄作者“侯樹成”的原創(chuàng)稿件，轉(zhuǎn)載請通過作者微信公眾號(hào)『Tomcat那些事兒』獲取授權(quán)】

戳這里，看該作者更多好文