Tomcat线程池实现简介(二)

 ThreadPool提供的仅仅是线程池的实现，而如何使用线程池也是有很大学问的。让我们看看Tomcat是如何使用ThreadPool的吧。

Tomcat有两种EndPoint，分别是AprEndpoint和PoolTcpEndpoint。前者自己实现了一套线程池（其实这和Tomcat 老版本的方案是相同的，至今Tomcat中还保留着老版本的线程池，PoolTcpEndpoint也有类似的代码，通过“策略”可以选择不同的线程池方 案）。我们只关注PoolTcpEndpoint如何使用ThreadPool的。

首先，PoolTcpEndpoint创建了一个ThreadPoolRunnable实例——LeaderFollowerWorkerThread，实际上该实例就是接收（Accept）并处理（Process）用户socket请求。接着将该实例放进ThreadPool中并运行，此时就可以接收用户的请求了。

当有Socket请求时，LeaderFollowerWorkerThread首先获得了Socket实例，注意此时LeaderFollowerWorkerThread并没有急着处理该Socket，而是在响应Socket消息前，再次将LeaderFollowerWorkerThread放进ThreadPool中，从而它（当然是另外一个线程了）可以继续处理其他用户的Socket请求；接着，拥有Socket的LeaderFollowerWorkerThread再来处理该用户的Socket请求。

整个过程与传统的处理用户Socket请求是不同的，也和Tomcat老版本不同。传统的处理方法是：有一个后台运行的监听线程负责统一处理接收（注意只 是“接收”）Socket请求，当有新的Socket请求时，将它赋值给一个Worker线程（通常是唤醒该线程），并有后者处理Socket请求，监听 线程继续等待其他Socket请求。所以整个过程中有一个从Listener到Worker切换的过程。

而新版本Tomcat很有创造性的使用了另外一种方法，正如前文所描述的，接收和处理某个用户Socket请求的始终是由一个线程全程负责，没有切换到其 他线程处理，少了这种线程间的切换是否更有效率呢？我还不能确认。不过这种使用方式确实有别于传统模式，有种耳目一新的感觉。