LimitLatch在Tomcat 中的應(yīng)用是怎樣的

這篇文章給大家介紹LimitLatch在Tomcat 中的應(yīng)用是怎樣的，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

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

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)前線程等待資源釋放。該方法最終會調(diào)用到LimitLatch的內(nèi)部類Sync的acquireSharedInterruptibly方法，即AQS的acquireSharedInterruptibly方法。

從內(nèi)部類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原子操作結(jié)果與設(shè)定的共享資源數(shù)量上限進(jìn)行比較，如果超出上限則目前無法獲取資源，由AQS放入等待隊列等待下次觸發(fā)。LimitLatch中定義了released屬性，該屬性為true時，無論如何都會獲取到共享資源。

public boolean releaseAll() {     

   released = true;//標(biāo)志位置為ture后，后續(xù)均可獲取資源    

    return sync.releaseShared(0);//通知等待線程重新獲取資源  

  }

這里就有一個問題了，既然無論如何都會獲取到資源，LimitLatch就沒有存在的必要，那為何還要這樣一個看似多余的released 屬性呢？這里其實考慮到一個狀態(tài)變更的問題，當(dāng)由一個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方法，本質(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個資源以及64線程競爭32個資源，循環(huán)300w次。測試結(jié)果竟然是LimitLatch性能要比Semaphore性能低近10%左右，這個。。。一定是我打開的方式不對。

關(guān)于LimitLatch在Tomcat 中的應(yīng)用是怎樣的就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。