LimitLatch 在 Tomcat 中的應用
Tomcat的LimitLatch類用于控制網絡通信的socket接收上限，在Tomcat7時引入，實現簡單，借此可以學習一下線程同步的相關知識。
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方法獲取資源，如果已經達到***連接數，則需要當前線程等待資源釋放。該方法最終會調用到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原子操作結果與設定的共享資源數量上限進行比較，如果超出上限則目前無法獲取資源，由AQS放入等待隊列等待下次觸發。LimitLatch中定義了released屬性，該屬性為true時，無論如何都會獲取到共享資源。
- public boolean releaseAll() {
- released = true;//標志位置為ture后，后續均可獲取資源
- return sync.releaseShared(0);//通知等待線程重新獲取資源
- }
這里就有一個問題了，既然無論如何都會獲取到資源，LimitLatch就沒有存在的必要，那為何還要這樣一個看似多余的released 屬性呢?這里其實考慮到一個狀態變更的問題，當由一個LimitLatch控制資源獲取量變更為無需LimitLatch時，僅僅將LimitLatch置為null從而跳過資源競爭是不夠的。
如果之前存在在等待隊列中等待資源的線程，而此時沒有資源釋放，那么在狀態變更后線程仍然會處于等待狀態，這與“***制”的狀態是不符的，此時需要將released屬性置為true，然后通過一次資源釋放由AQS觸發所有等待線程重新獲取資源，這個時候所有線程均會獲取資源立即返回。
- protected boolean tryReleaseShared(int arg) {
- count.decrementAndGet();//自減釋放資源
- return true;
- }
資源釋放時的代碼就更簡單了，直接將代表資源的原子變量AtomicLong自減從而釋放資源就完成了。而后續的喚醒等待資源的線程等工作已經由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個資源，循環300w次。測試結果竟然是LimitLatch性能要比Semaphore性能低近10%左右，這個。。。一定是我打開的方式不對。
我們回顧一下，當前使用的環境為Windows，JDK版本為1.8，而tomcat7引入LimitLatch的時候正是JDK1.6橫行的時代。筆者將JDK切換到1.6進行測試，果然結果變為兩者不相上下;而后將測試代碼上傳到了服務器，在Linux、JDK1.6環境下重新測試，結果LimitLatch扭轉乾坤，反超Semaphore性能20%左右，切換到JDK1.8性能領先Semaphore約40%!很明顯Tomcat更注重的是Linux服務器下的性能，至于兩者性能對比結果在不同環境下不同的原因，歡迎各位大牛一起討論。
【本文為51CTO專欄作者“侯樹成”的原創稿件，轉載請通過作者微信公眾號『Tomcat那些事兒』獲取授權】
