servlet是单实例多线程的，还是多实例多线程的

Servlet类本质上也是一个普通的类，并且Servlet容器默认只允许单个实例存在。当请求达到服务器的时候，Servlet实例如果已经存在的话则直接加载该实例，如果该Servlet类还未实例化则会先初始化这个Servlet。当请求到达Web服务器时，Web服务器中有一个线程池，它会从线程池中取一个工作线程，通过该线程调用请求的Servlet。因此，对Servlet来说，可以同时被好几个请求调用。请求结束后，线程放回线程池。

这种设计带来的好处是，Servlet单实例，减少了生成Servlet的开销。通过线程池响应请求，避免了不断创建线程和销毁线程的开销，提高了性能。但是这种多线程操纵单实例的模式，也会有一些副作用，那就是可能造成数据的不一致。

Tomcat既支持阻塞式IO，也支持非阻塞式IO。

如果要使用NIO，需要修改server.xml的配置。

<Connector executor="tomcatThreadPool" port="8080" [color=red]protocol="org.apache.coyote.http11.Http11NioProtocol"[/color] connectionTimeout="20000"

redirectPort="8443" URIEncoding="UTF-8"/>

web服务器一般有两种处理http请求的机制，阻塞和非阻塞，阻塞式因为每一个连接都产生一个线程，当线程数达到一定数量的时候，CPU用于线程切换的时间会变多，整体的性能会下降，所以线程池的数量要控制在一定的数量内，这是就需要引入非阻塞的机制，就是把连接先缓冲在一个队列中，然后再分给后台的线程池中的空闲线程慢慢处理。

Comet属于长连接，所以对于web服务器的吞吐量要求要更高，也就是要具备处理大量http请求的能力，所以必须使用Http11NioProtocal来提高吞吐量。

至于把连接缓存在队列中，依然排队等待的问题，和阻塞式处理方式比，至少客户端不会收到500 connection refused，只是感觉响应慢一些，还有因为comet属于消息推送，一般客户端的http请求是异步的，比如通过ajax在后台发起http请求，所以对于这种情况，连接缓存在等待队列中也没有关系，因为是异步的，而且用户也看不到，所以对用户的使用也没有影响。

下面看一下这两种方式的区别：

1.Http11Protocal

使用阻塞IO,服务器端使用Socket类和ServerSocket类负责请求的接入

一个请求接入线程，专门负责请求的接入accept，接入后把socket扔给后面的线程池，线程池中有具体的处理线程，负责后续的处理，一个线程对应一个请求，直到请求处理完毕并返回response，这个线程数就是web服务器能承载的最大线程数，如果线程池中没有空闲线程，那么下一个请求就无法接入，如果ServerSocket的等待队列也满了的话，客户端就会收到500 connection refused。

2.Http11NioProtocal

使用非阻塞IO，服务器端使用SocketChannel类和ServerSocketChannel类负责请求的接入

这种方式也有一个请求接入线程，专门负责请求的接入accept，但是接入后不是直接扔给后面的处理线程池，而是又多了一个或两个中间线程，这个中间线程里面有一个队列，接入后直接把SocketChannel以及对应的Selector监听信息包装成一个事件对象扔到中间线程的队列中（如果有两个中间线程，那么平均使用这两个线程，这次是线程1，下次是线程2，在下次是线程1，以此类推，所以每个中间线程会处理多个连接），这个队列可以容纳足够多的事件对象，Selector相当于对socket状态进行监视的监听器。这个中间线程不断地对这个事件队列进行循环处理，当Selector中有需要处理的事件时（比如socket read就绪，socket write就绪），再把socket转给后面的处理线程池进行后续的处理。

前面提到的中间线程可以有一个或者两个，每个里面都有一个队列，所以可以容纳足够多的socket连接。这样即使后面的线程池中没有空闲线程，一样可以对请求进行接入，然后缓存在中间线程的队列中。这样就加大了web服务器的吞吐量。comet长连接很多时也可以应付得了。

这种方式不单单是对连接进行缓存，前面提到了中间线程对Selector中的事件进行监视，直到有事件到达时才把socket转给后台线程池进行处理，这样就减少了线程池中的处理线程的等待时间，此外，对每个SocketChannel都分配了readbuffer和writebuffer,这样可以减少实际的socket流的读写次数，以减少IO等待。

为什么要用线程池？诸如Web 服务器、数据库服务器、文件服务器或邮件服务器之类的许多服务器应用程序都面向处理来自某些远程来源的大量短小的任务。请求以某种方式到达服务器，这种方式可能是通过网络协议（例如 HTTP、FTP 或 POP）、通过 JMS 队列或者可能通过轮询数据库。不管请求如何到达，服务器应用程序中经常出现的情况是：单个任务处理的时间很短而请求的数目却是巨大的。构建服务器应用程序的一个过于简单的模型应该是：每当一个请求到达就创建一个新线程，然后在新线程中为请求服务。实际上，对于原型开发这种方法工作得很好，但如果试图部署以这种方式运行的服务器应用程序，那么这种方法的严重不足就很明显。每个请求对应一个线程（thread-per-request）方法的不足之一是：为每个请求创建一个新线程的开销很大；为每个请求创建新线程的服务器在创建和销毁线程上花费的时间和消耗的系统资源要比花在处理实际的用户请求的时间和资源更多。除了创建和销毁线程的开销之外，活动的线程也消耗系统资源。在一个 JVM 里创建太多的线程可能会导致系统由于过度消耗内存而用完内存或“切换过度”。为了防止资源不足，服务器应用程序需要一些办法来限制任何给定时刻处理的请求数目。线程池为线程生命周期开销问题和资源不足问题提供了解决方案。通过对多个任务重用线程，线程创建的开销被分摊到了多个任务上。其好处是，因为在请求到达时线程已经存在，所以无意中也消除了线程创建所带来的延迟。这样，就可以立即为请求服务，使应用程序响应更快。而且，通过适当地调整线程池中的线程数目，也就是当请求的数目超过某个阈值时，就强制其它任何新到的请求一直等待，直到获得一个线程来处理为止，从而可以防止资源不足。

---