Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2420643
  • 博文数量: 392
  • 博客积分: 7040
  • 博客等级: 少将
  • 技术积分: 4138
  • 用 户 组: 普通用户
  • 注册时间: 2009-06-17 13:03
个人简介

范德萨发而为

文章分类

全部博文(392)

文章存档

2017年(5)

2016年(19)

2015年(34)

2014年(14)

2013年(47)

2012年(40)

2011年(51)

2010年(137)

2009年(45)

分类:

2010-09-21 13:33:19

我看了一下Apache1.3.7的源代码,主要是看了一下其中SOCKET网络服务的结构,其中使用select   +   thread   pool的过程大体如下:

首先创建一个全局的job_list链表,用于存放使用select方式(accept)得到的新的socket句柄.

  然后再创建一个工作者线程池,每个工作者线程都运行一个叫child_sub_mail()的线程安全函数,这个函数调用remove_job(),进入阻塞方式,直到从job_list得到一个已经accepted的新的socket句柄,接下来就循环处理这个socket上的读写请求直到这个socket断开,然后再调用remove_job()来处理下一个socket连接.remove_job()同时把该socket从job_list链表里删除。

    在主进程中,当一个新的socket连接被建立,apache就调用add_job()把新的socket句柄加入job_list.这样就会被work_thread   pool里面空闲的work_thread
马上从job_list发现并接管对该socket的所有I/O请求。

当然还有线程安全退出和对socket异常错误的处理,apache都处理的相当的好。

不妥之处欢迎指正,如果有详细的分析就更好。当然apache的这种模式也不是十全十美的。比如work_thread_pool中应当有多少个线程?能不能根据软硬件环境自动调整线程池的大小(工作者线程数目)?使空闲的线程数不至于过多,也不至于当一个accepted   socket加入job_list后得不到及时的处理。如果使用select+process(fork)方式在大型机环境下性能是不是要好于上面的模式?
 
 
 
 
现在考虑这样一个情景。你要做一个高性能的通讯程序,现在按照传统方式开始做。客户端就不写了。服务器端的代码大致如下:
//建立一个服务器端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();
}
阅读(5470) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~