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

LimitLatch依賴內部類Sync進行線程同步，而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)達到***連接數(shù)，則需要當前線程等待資源釋放。該方法最終會調用到LimitLatch的內部類Sync的acquireSharedInterruptibly方法，即AQS的acquireSharedInterruptibly方法。

從內部類Sync的重載方法我們能看到Sync是一個共享模式的同步器，重載了tryAcquireShared和tryReleaseShared兩個方法，而兩個方法之所以能夠如此簡單，就是因為父類AQS在背后默默完成了其他所有的排隊、等待、激活等一系列邏輯。

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

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

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

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

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

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

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

寫到這里，問題又來了，這個功能完全可以由JDK自帶的Semaphore類來完成啊。如果非要再寫一個那一定是因為性能的原因了，畢竟該類要使用在接收Socket的前面，對性能有直接影響。下面代碼為Semaphore類(JDK1.8)的FairSync重寫的tryAcquireShared方法，本質上與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個資源以及64線程競爭32個資源，循環(huán)300w次。測試結果竟然是LimitLatch性能要比Semaphore性能低近10%左右，這個。。。一定是我打開的方式不對。

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

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

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