线程池代替进程池

  

一．问题引入

刚进入一家新公司，在公司的一些培训中得知，我们的服务端系统中，底层库的任务调度用的是进程池的实现，也就是创建许多子进程来进行执行业务处理，进程池技术是比较早的一种技术了，在现在众多高性能服务端程序中，包括开源著名的apache,nginx…，大多采用线程池来实现，下面说一下采用线程的一些好处。

 

二．线程的优点

线程（thread）技术早在60年代就被提出，但真正应用多线程到操作系统中去，是在80年代中期，solaris是这方面的佼佼者。传统的Unix也支持线程的概念，但是在一个进程（process）中只允许有一个线程，这样多线程就意味着多进程。现在，多线程技术已经被许多操作系统所支持，包括Windows/NT，当然，也包括Linux。

　　为什么有了进程的概念后，还要再引入线程呢？使用多线程到底有哪些好处？什么的系统应该选用多线程？我们首先必须回答这些问题。

　　使用多线程的理由之一是和进程相比，它是一种非常"节俭"的多任务操作方式。我们知道，在Linux系统下，启动一个新的进程必须分配给它独立的地址空间，建立众多的数据表来维护它的代码段、堆栈段和数据段，这是一种"昂贵"的多任务工作方式。而运行于一个进程中的多个线程，它们彼此之间使用相同的地址空间，共享大部分数据，启动一个线程所花费的空间远远小于启动一个进程所花费的空间，而且，线程间彼此切换所需的时间也远远小于进程间切换所需要的时间。据统计，总的说来，一个进程的开销大约是一个线程开销的30倍左右，当然，在具体的系统上，这个数据可能会有较大的区别。

　　使用多线程的理由之二是线程间方便的通信机制。对不同进程来说，它们具有独立的数据空间，要进行数据的传递只能通过通信的方式进行，这种方式不仅费时，而且很不方便。线程则不然，由于同一进程下的线程之间共享数据空间，所以一个线程的数据可以直接为其它线程所用，这不仅快捷，而且方便。当然，数据的共享也带来其他一些问题，有的变量不能同时被两个线程所修改，有的子程序中声明为static的数据更有可能给多线程程序带来灾难性的打击，这些正是编写多线程程序时最需要注意的地方。

　　除了以上所说的优点外，不和进程比较，多线程程序作为一种多任务、并发的工作方式，当然有以下的优点：

　　1) 提高应用程序响应。这对图形界面的程序尤其有意义，当一个操作耗时很长时，整个系统都会等待这个操作，此时程序不会响应键盘、鼠标、菜单的操作，而使用多线程技术，将耗时长的操作（time consuming）置于一个新的线程，可以避免这种尴尬的情况。

　　2) 使多CPU系统更加有效。操作系统会保证当线程数不大于CPU数目时，不同的线程运行于不同的CPU上。

3) 改善程序结构。一个既长又复杂的进程可以考虑分为多个线程，成为几个独立或半独立的运行部分，这样的程序会利于理解和修改。

  

三．线程池原理

传统服务端程序利用线程技术响应客户请求，每来一个客户请求，服务端就会启动一个线程处理请求，结果后线程自动退出，这样做似乎效率提高了，但是如果请求很频繁，就会导致服务端频繁地创建线程，销毁线程，比较消耗CPU资源，所以才会需要进一步地改进，这样线程池技术就出现了。

线程池的原理：系统预先启动一定数量的线程，构成一个线程池，并利用手段将它们处于阻塞状态，在阻塞状态下的线程是不消耗CPU资源的，每一个客户请求视为一个任务，将这些任务都放入一个队列中，并通知线程池中的线程取出任务队列中的任务请求进行处理。可将任务请求看作是生产者，将处理任务的线程池看作是消费者，这就是生产者消费者模型:

    这会涉及到任务队列在多线程中的同步问题，以后再细节讨论如何处理同步。 

 

四．高并发高性能服务端设计

设计高性能服务端程序，线程池只是其中提升服务器性能的一种方式，其它还有：网络IP模型Epoll,IOCP,内存池（开源库nedmalloc）、数据库缓存系统(开源库memcache)、数据库连接池。。。许多提升性能的实现都已经有开源代码可用了。

另外还有通信协议上的选择也会影响服务端性能，对于大批量小数据多客户端并发，可以考虑用UDP协议，由于UDP是一种无连接传输协议，可以有效的降低系统开销，特别对大批量小数据的请求，效果明显，而TCP在这种情况对系统的消耗是很大的，往往会导致连接被拒绝，或者socket句柄已经存在的错误。有人可能就会问了，在服务端可以采用短连接，这样就可以节约资源。其实不然，大量socket的创建与销毁本来就是一种对系统性能的极度消耗，有时这种还没有直接使用长连接来的效率高。

本人个人兴趣方面是高并发高性能服务端设计，经验还不算丰富，一直在积累中，有兴趣的同学可以向我提建议，也可以找我讨论。

本人联系方式：

QQ：176013544