LimitLatch 在 Tomcat 中的应用 - HelloWorld开发者社区

本文的作者是我之前一起从事应用服务器研发的同事杨高强，高强现就职于某互联网巨头，功底深厚，技术牛X。以下为正文部分

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服务器下的性能，至于两者性能对比结果在不同环境下不同的原因，欢迎各位大牛一起讨论。

讲到这里，读者是不是对AQS的源码也非常感兴趣了呢，赶紧读起来吧？

☆★☆更多精彩内容☆★☆****

一台机器上安装多个Tomcat 的原理(回复001)

监控Tomcat中的各种数据 (回复002)

启动Tomcat的安全机制(回复003)

乱码问题的原理及解决方式(回复007)

Tomcat 日志工作原理及配置(回复011)

web.xml 解析实现(回复 012)

线程池的原理( 回复 014)

Tomcat 的集群搭建原理与实现（回复 015)

类加载器的原理 (回复 016)

类找不到等问题 (回复 017)