服务器程序使用线程池，比如开始的时候派生1000个线程来处理客户请求，当有1001个客户都请求连接那应该怎么办？

线程池的出发点不是说增加连接的吞吐量，而是减少系统建立线程、撤销线程的开销

池内的线程是一直在的，通常是完成一项特定的任务，而这个任务常常是重复性较高的，
当工作完成后，这个线程就马上又可以进入空闲状态，为下一次工作服务

一个用户的连接，通常不是一个任务就完成的，也不大可能由一个线程从头到尾来负责（当然一般的应用中也可以这样做）

如果池内的线程确实不够用，也可以动态地变化池的大小，以容纳更多的工作线程

服务器程序使用线程池，比如开始的时候派生1000个线程来处理客户请求，当有1001个客户都请求连接，那么这个客户只能等到下一个线程空闲时，来处理它。apache就这样做的，在listen的第二个参数里指定等待的连接的最大个数，如果超过这个数，客户的connect会失败。

线程池不是这样用的。
线程的创建和销毁是极耗系统资源的。上千个线程争夺CPU时间，结果是所有的线程都没有时间。
即使有1000个客户请求，绝大多数应用中每个客户每秒钟交换消息的信息量是很少的。所以线程池的一个线程足以及时的响应几十或上百个服务请求。
线程池中的线程数目是不变的。每收到一个请求，就将它分配给一个线程来处理。线程太多了，会使整个系统性能下降，太少了，又不能充分利用CPU。所以线程数目和CPU数目，系统性能有关。
在我们的系统中，每秒钟要处理100多个呼叫，每个呼叫持续几分钟，用SUN的NETRA220,只需要7，8个线程组成的线程池就搞定了。

要用集群了，把连接改到那个特定的IP就该可以了

1 一个线程不一定对应一个连接
2 一个机器不可能建立那么多连接，实际应用中，甚至连1000个都不能。

有些服务器的设计确实是先创建一定数量的线程，而且可能线程数就定下来了。

这样做的好处是不用再为线程的创建和撤消已经相关资源的分派开销时间。
另外，一个连接是一个任务，而线程则是用来执行任务的资源。就进程和CPU的关系差不多。

任务的执行可以是分时的。就是说一个连接可以不是时时刻刻都有一个线程为他做处理的。
这样，第1001个连接到来时，只不过会导致系统的整体响应速度有所下降而已。
当然，如果实际应用不允许这样的情况发生，就只好把第1001个挂起了。

如果是集群，那么肯定有一个负载平衡的部分，直接把这个连接送到还有空线程的服务器上去。

机群技术俺不怎么懂，不敢胡说了：）

1000万,别开玩笑了,一台服务器肯定是不可能完成的.有这么强的网卡吗?有这么强的操作系统吗?
应该使用集群,负载均衡的办法

可以参考LVS的实现

不过1000万实连接实在太吓人了

mark