这篇文章给大家介绍LimitLatch在Tomcat 中的应用是怎样的，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
创新互联长期为千余家客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为印台企业提供专业的成都网站建设、网站设计，印台网站改版等技术服务。拥有十余年丰富建站经验和众多成功案例,为您定制开发。
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%左右，这个。。。一定是我打开的方式不对。
关于LimitLatch在Tomcat 中的应用是怎样的就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。