tomcat的线程模型
现在考虑这样一个情景。你要做一个高性能的通讯程序,现在按照传统方式开始做。客户端就不写了。服务器端的代码大致如下:
//建立一个服务器端socket
ServerSocket socket = new ServerSocket(port,backlog);
//开始监听
while((Socket socket = socket.accept())!=null) {
//开一个线程,处理收到的socket。
Thread t = new BusinessThread(socket);
t.start();
//其他事情,例如计数,计算收到了多少个请求。
count++;
}
它的缺点是什么:
开辟线程比较浪费时间和资源。
1、可能开辟到一定程度的时候,资源全被线程吃掉,导致性能下降。2、线程的数目不可控,因为你不知道这个线程什么时候结束。
现在开始第一次改进。解决开辟线程浪费的时间和资源。最基本的思路,大家都应该能想到,我们用个线程池来做这个事情。假设线程池里有了一些事先做好的线程。
//建立一个服务器端socket
ServerSocket socket = new ServerSocket(port,backlog);
//开始监听
while((Socket socket = socket.accept())!=null) {
//开一个线程,处理收到的socket。
ControlRunnable r = ThreadPool.getWorkThread();
if(t != null) {
ThreadPool.touch(r,socket); ==> > 将该线程需要的数据绑定。
ThreadPool.runIt(r); ==> > 运行完後需要将该线程放回去:Thread.release(r)。
} else {
wait();
//线程池中暂时没有空闲线程可供使用。
}
}
ThreadPool.getWorkThread() {
if(totalThread - busyThread - 1 < 0)
return null; //没有可用的线程了。
r = pool[totalThread - busyThread - 1];
pool[totalThread - busyThread - 1] = null;
busyThread++;
return r;
}
Thread.release(r) {
pool[totalThread - busyThread] = r;//注意这里busyThread不可能为0
busyThread--;
}
这个程序的缺点是什么?
getWorkThread()和r.release()需要同步。否则会发生混乱。这样造成一个后果,就是由于getWorkThread在等待,导致很多socket连接被拒绝(超过了backlog)。
第二次改进:防止过多socket被拒绝。思路:保证连接能很快收到。我们可以在这里放一个队列,以便接收请求。
另外线程池中有很多线程在这里监听这个队列,当这个队列中有内容时,其中一个线程取出socket进行处理。
//建立一个服务器端socket
ServerSocket socket = new ServerSocket(port,backlog);
//开始监听
while((Socket socket = socket.accept())!=null) {
queue.putConnection(socket);
queue.notify();//通知线程池中的线程去处理。
}
线程中的处理过程:
while(true) {
Socket s = (Socket)queue.get();
if(s != null) {
//业务处理
} else {
wait();
}
}
putConnection的过程:
putConnection(s) {
if(queue.size> MAX_LENGTH)
write(s, "服务器忙 ");
queue.put(s);
}
这个程序的缺点:1、queue在get的时候都需要同步。(注意put可以不同步,因为队列是2头的,我只需要同步取的那头,放的那头由于只有一个线程在放,因此可以不同步)
2、工作线程和主线程需要切换後才开始运行业务。
所以这个线程模型不是最优的。这个就是Master Slave Worker Thread 模型。
第三次改进:这就是Leader Follower Worker Thread。tomcat所用的线程模型。
思路:线程池中有很多线程处于等待工作状态,只有一个线程的处于监听状态(这就是leader线程),接收到socket後就去处理(变成了follower线程),同时通知另一个线程进入监听状态。
//建立一个服务器端socket
ServerSocket socket = new ServerSocket(port,backlog);
//开始监听
Socket socket = socket.accept()
ThreadPool.notify()
//做业务处理
.....
//业务处理完成
returnControlToThreadPool();
}
缺点:returnControlToThreadPool()时需要同步,但这是在业务已经处理完成的情况下。并且很难有大量线程同时做这个操作,可以忽略不计。
欢迎高手一起讨论,群:8990357
[解决办法]
关注
[解决办法]
LZ强悍!
最近我也有要写个服务端的任务,最初采用的就是线程池(也就是你的1版本),遇到的问题也是相同的.
如果是用C++来写的话,IO完成端口模型是目前性能最高的,在JAVA中设计起来感觉难度要大一些了(可能是我的JAVA不熟的原因:) ),如果按照LZ的说法,显然也无法解法恶意连接的问题,
继续寻找设计方案中,欢迎一起讨论(Q:710502169)
[解决办法]
关注,本人也在做类似的代码。
[解决办法]
第三次改进(详细解释):这就是Leader Follower Worker Thread。tomcat所用的线程模型。
思路:线程池中有很多线程处于等待工作状态,只有一个线程的处于监听状态(这就是leader线程),接收到socket後就去处理(变成了follower线程),同时通知另一个线程进入监听状态。
//建立一个服务器端socket
leader线程 线程池中的某一空闲线程
//开始监听
Socket socket = socket.accept() wait();
ThreadPool.notify() =====通知另一个线程进入接受状态=========> socket.accept();
//做业务处理 //做业务处理
..... .......
//业务处理完成 //业务处理完成
returnControlToThreadPool(); returnControlToThreadPool();
注意这里的leader线程,ThreadPool.notify()这句仅仅是发一个通知,然后进行业务处理,这样在没有线程切换的情况下就进行处理。
tomcat的源码这个地方是一个读起来比较困难的地方,必须了解它的线程模型才能继续下去。
tomcat这部分的相关源码参见
org.apache.tomcat.util.threads.ThreadPool(这是该线程模型中最重要的类,和它的内部类ControlRunnable)
org.apache.tomcat.util.threads.ThreadPoolRunnable
org.apache.tomcat.util.threads.ThreadWithAttributes(绑定线程的参数,类似ThreadLocal)
org.apache.coyote.http11.Http11BaseProtocol(主要是该类中的内部类Http11ConnectionHandler)
org.apache.tomcat.util.net.PoolTcpEndpoint
缺点:returnControlToThreadPool()时需要同步,但这是在业务已经处理完成的情况下。并且很难有大量线程同时做这个操作,可以忽略不计。
[解决办法]
关注
[解决办法]
看下
[解决办法]
我也正在做相关的工作,关注。
[解决办法]
学习……
[解决办法]
mark
[解决办法]
真有奉献精神
[解决办法]
学习!
[解决办法]
顶一下