在这里我先简单的说下bio和nio的区别
这里我以电话客服的情况来解释
bio
一个客户对应一个客服，
假如客户比较麻烦，中途不挂电话，或者去做其他事情了，而客服资源会被一直占用
导致的后果是系统处理能力大大降低
Nio
中间加入了一个协调员，假如遇到比较麻烦的用户，请求可以先到协调员这里，当用户准备好以后，在转接给客服。
那这两种方式有啥区别呢？
理论上来说，如果是完全没有网络延迟，阻塞的情况下，其实这两者的性能差不多。
但是实际情况下，服务器根本无法确定客户端的网络情况，所以，一般不使用bio
Tomcat处理请求核心流程图
Acceptor （Acceptor的作用是控制与tomcat建立连接的数量，但Acceptor只负责建立连接）
接收socket线程，这里虽然是基于NIO的connector，但是在接收socket方面还是传统的serverSocket.accept()方式，获得SocketChannel对象，然后封装在一个tomcat的实现类org.apache.tomcat.util.net.NioChannel对象中。然后将NioChannel对象封装在一个PollerEvent对象中，并将PollerEvent对象压入一个队列中里。这是典型的生产者-消费者模式，Acceptor与Poller线程之间通过queue通信，Acceptor是生产者，Poller是消费者。
Poller （socket内容的读写）
Poller线程中维护了一个Selector对象，NIO就是基于Selector来完成逻辑的。
Poller是NIO实现的主要线程。首先作为消费者，从队列中取出PollerEvent对象，然后将此对象中的channel以OP_READ事件注册到Selector中，然后Selector执行select操作，遍历出可以读数据的socket，并从Worker线程池中拿到可用的Worker线程，然后将socket传递给Worker。这个过程是典型的NIO实现。
Worker （执行相关业务逻辑）
Worker线程拿到Poller传过来的socket后，将socket封装在SocketProcessor对象中。然后从Http11ConnectionHandler中取出Http11NioProcessor对象，从Http11NioProcessor中调用CoyoteAdapter的逻辑，跟BIO实现一样。在Worker线程中，会完成从socket中读取http request，解析成HttpServletRequest对象，分派到相应的servlet并完成逻辑，然后将response通过socket发回client。
核心参数说明
|
参数名称 |
可选值 |
参数解释 |
|
protocol |
HTTP/1.1 org.apache.coyote.http11.Http11NioProtocol |
网络传输协议 bio Nio |
|
maxThreads |
工作线程的最大线程数 |
|
|
minSpareThreads |
工作线程的最小线程 |
|
|
connectionTimeout |
连接超时（当请求数量超过了 maxConnections，系统会继续接收连接但不会超过acceptCount的值 ） |
|
|
acceptCount |
等待队列的长度 |
|
|
acceptorThreadCount |
Acceptor线程数量 |
|
|
maxConnections |
最大连接数 |
|
|
pollerThreadCount |
Poller线程数量（nio独有） |
|