连接器在Tomcat中是一个主要的组件，叫做Tomcat前端，这个前端框架不是常日我们讲的Web前端，那是structs，javascript，jsp这些内容，这里讲的因此NIO的办法，来描述从socket要求到Request工具的过程，而我们理解的Tomcat后端，常日因此CoyoteAdapter为分界点，后端框架通过Mapper进行映射，可以总结为下面的示意图：
Tomcat前端接管的是Socket要求，通过前端框架组件进行http解析，并基于Connector配置的属性做进一步的处理，转化为Tomcat内部的Request工具。
这个位置相称于是一个分界点，也便是CoyoteAdapter类，之后通过Mapper类直接找到Tomcat后端容器中的对应的Servlet，这个中会传给Engine，Host，Context等各种后端容器组件的解析。
末了，转化为Servlet规范的httprequest，作为参数传到业务实现的Servlet中，完玉成部要求的过程。
到这里为止，Tomcat前端这块就很清晰明了，在没有见到架构图之前，我们推测，该当貌似有这些处理机制：
1).该当会有线程池做线程支撑的
2).解析http的组件
3).很多线程池是分开的，例如事情线程池和前端socket处理线程池
4).由于我们这篇文章剖析的是NIO，以是肯定会有Selector的内容
下面这两张图便是NIO完全的业务流程图和关键组件架构图
2、图解tomcat前端详细流程（源码详细剖析解读见视频）事情流程的源码注释：
3、源码解读tomcat前端关键组件初始化和启动过程（详细剖析解读见视频）4、Http11NioProtocol（源码详细剖析见视频）http1.1的协议类，实际上这个类的初始化是由对应的Connector类进行初始化，我们可以看看server.xml中关于连接器的配置：
对应的协议是HTTP/1.1，对付Connector来讲，有很多的协议处理器：
对付普通的NIO连接器，其便是Http11NioProtocol这个类。
从源码剖析上来看，直策应用当前哨程高下文的类加载器进行加载Http11NioProtocol，并对其布局方法进行初始化。
Http11NioProtocol作为协议的实现者，它持有两大组件：
一是Endpoint，默认的便是NioEndpoint，这个类是线程池，socoket的转接类，将NIO通道中的socket组包，交给handler来进行处理。
二便是Handler，也便是Http11ConnectionHandler，设置给Endpoint，这个Http11ConnectionHandler类紧张的浸染是将前面组包socket包，转换成内部的Request工具，末了发给Tomcat的后端。
这两大组件实在也便是上图的最紧张的核心部分，是Tomcat前端框架的灵魂。
5、NioEndPoint（源码详细剖析见视频）NioEndPoint类持有三大线程池：
Acceptor（tomcat9版本独立出来了）
PollerEvent
Poller（相称于是reactor）
Worker（exec即SocketProcessor）
从以下类的注释就可以看出来：
a.socket acceptor线程池
这个线程池中里面的每一个线程中运行的便是NioEndPoint.Acceptor类。这个Acceptor紧张的浸染并不是直接将这个socket的流取过来，双方进行交互，如果这么做的话，那Tomcat基本就和一个普通的socket程序没有什么差异了。
这个Acceptor首先根据是否是SSL配置，利用Tomcat自身扩展的NioChannel来包装SocketChannel，之以是包装的目的是要给对NIO的channel加很多的功能，NioChannel持有socketChannel的一个引用，如果是SSL配置的话，那么就启用的是SecurityNioChannel类进行包装。
b.PollerEvent数组
PollerEvent是poller线程池处理的任务单元，这个类也是一个Runable线程。
PollerEvent不单单还有前面包装的NioChannel，还持有NioEndPoint.KeyAttachment类的一个引用，KeyAttachment类的浸染紧张是对Connector中的一些socket属性进行解析，然后设置到对应的SocketChannel通道中。
由于Tomcat作为前真个做事器，网络要求很多，以是对付一个Poller线程池，上述的从Acceptor过来的PollerEvent事宜会非常的多，因此这里采取一个行列步队的模式做一下缓冲
c.socket poller线程池
Poller中掩护者的是一个Selector工具，其实在Tomcat的前端中存在了n多个的Selector工具，当前这个Selector紧张是用于从Acceptor传过来的NioChannel进行感兴趣事宜的NIO注册操作，并轮询感兴趣的事宜发生。
这里还有一个Queue行列步队，这里采取的是SynchronizedQueue，须要把稳的是，这里并不是JDK包中的SynchronizedQueue同步队列，而是tomcat中自定义实现的SynchronizedQueue，不要产生稠浊，实现思路很大略，便是一个普通的数组演化的。
总结一下便是，poller线程紧张是完成了NIO的selectkey的操作，这一步比较关键，之以是在前面又加了一个Acceptor线程，是由于每一次数据报进来后，都须要对其进行“加工一下”，再转发给poller进行selectkey感兴趣事宜的获取。
到这里为止，poller线程仍旧没有进行处理，它连续将接力棒交卸给事情线程池。
d.事情线程池
poller线程中末了一步时候processKey方法，这个方法终极会调用processSocket方法：
SocketProcessor是事情线程池中的事情方法，上述事情线程池中一共有两个选择，当JDK5之前，SocketProcessor类本身也是一个Runable线程，直接可以实行run方法，这就没有什么线程池的观点了；而在JDK5之后，ThreadExecutor是JDK默认的线程池，Tomcat中集成了进来，也便是调用其executor.execute方法，将SocketProcessor任务传进去。
对付Tomcat的事情线程池的分解，在前面已经做过专题的讲解。
SocketProcessor任务中，一共分两个步骤，第一步是进行socket的handshake，也便是握手，对付正常的http来讲没有什么多余的操作，对付SSL可以看到在握手阶段，按照SSL的会话的交互，双方进行密码协商，这一步默认的话是调用JSSE的SSLEngine进行交互，返回SSLEngineResult，当握手成功后，该要求就可以交给给handler进行处理，这个handler便是下面要讲的Http11ConnectionHandler。
6、Http11ConnectionHandler（源码详细剖析见视频）Http11ConnectionHandler两个剖析重点：
1)、Http11ConnectionHandler持有Http11NioProcessor类，Http11NioProcesso卖力解析http协议。
2)、Http11NioProcesso解析完http协议，攒出request和response通报给CoyoteAdaptor，经由容器层层转发后抵达业务Servlet。
到这里为止，NIO的前真个逻辑就完成了。
7、总结NIO的前端框架紧张是由三个不同的线程依次分工协作：
1)、Acceptor线程将socketchannel取出， 通报给Poller线程（会产生线程壅塞，因此包装成PollEvent加入缓存行列步队）。
2)、Poller线程实行的便是NIO的selectkey，拿到通道中感兴趣的事宜，轮询获取，然后将感兴趣的selectkey和keyattachment通报给事情线程池进行处理。 3)、事情线程池调用http11ConnectionHandler进行http协议的解析，然后将解析出来的内容包装成Request，Reponse工具，通报给分界点CoyoteAdapter，终极实行到业务中。
七、BIO连接器前端整体框图1、BIO框图源码解读（tomcat8.5后抛弃）（源码详细剖析解读见视频）上一讲讲解过NIO的框图，可以看到，NIO通道是目前Tomcat7往后的默认的通道的推举配置，在Tomcat6和以前的配置中，BIO是主流的配置。
只须要修正protocol协议部分即可，而后续还有APR协议，NIO2.0的协议，都是修正这个字段。
对付BIO的整体框图，基本和NIO保持类似，整体流程变革不大，如下图所示：
2、Http11Protocol类详解
与NIO一样，这个Http11Protocol是默认的BIO的http1.1协议的处理类，Tomcat除了有NIO，BIO，实在还有两个通道：
1)、APR是高性能通道，
2)、NIO2是基于纯异步IO的通道，这个会在后面的Tomcat中进行讲解。
Http11Protocol类中，依然持有Endpoint和handler的引用，只不过，BIO对应的Endpoint是JIOEndpoint，对应的handler是Http11ConnectionHandler。
3、JIoEndPoint（tomcat7.x版本）JIoEndpoint是BIO的端点类，它和NIO一样，也是掩护着线程池，只不过由于没有Selector.select，没有SocketChannel的通道的注册，以是比较NIO模式，没有Poller线程是非常随意马虎理解的，反倒是NIO的三个线程不随意马虎理解，BIO可以看做便是基于Socket进行操作。
首先，初始化的JIoEndpoint的时候，会调用bind方法绑定Serversocket到对应的端口，bind方法是初始化布局JIoEndpoint的主要步骤，他的紧张浸染便是建立ServerSocketFactory。
根据SSL信道或者是普通的http的信道，Tomcat都实现了ServerSocketFactory，普通的http通道的ServerSocketFactory便是DefaultServerSocketFactory类，其工厂方法便是创建ServerSocket，很随意马虎理解。
对付SSL通道的ServerSocketFactory是JSSEServerSocketFactory这个类创建的是SSLServerSocket。
其次，JIoEndpoint启动的时候，会将Acceptor线程和事情线程池启动起来。
除此之外，还启动了一个专门的线程，这个线程便是检讨异步要求的Timeout的，后续会有专门的先容针对付Tomcat的异步要求。
事情线程池，利用的便是JDK自带的ThreadPoolExecutor。
可以从线程的堆栈看到，对应的http-bio-8443-exec-n 这种线程都是事情线程池。
如果在tomcat中没有指定事情线程池的设置，那么都走的是JDK自带的ThreadPoolExecutor的默认值。
JIoEndpoint是BIO的端点类，它和NIO一样（NIO里面是NioEndpoint），也是掩护着线程池，只不过由于没有Selector.select，所有只有2个线程池：
1）acceptor
2）worker（exec）
4、Acceptor线程Acceptor线程的紧张浸染和NIO一样，如果没有网络IO数据，该线程会一贯serversocket.accept壅塞住。
当有数据的时候，首先将socekt数据设置Connector配置的一些属性，然后将该接力棒通报给事情线程池。
末了一步processSocket方法，也是非常大略。
直接调用事情线程池，将SocketProcessor作为事情任务传入到事情线程池中实行。
这一步比较NIO的架构，短缺了NIO通道中的PollerEvent一个缓存行列步队，NIO中有这样的一个行列步队是由于须要从Acceptor到Poller线程，中间通报须要一个缓存的地方，而可以看到上述的BIO中的代码，如果事情线程池已经满载了，会根据JDK的ThreadPoolExecutor的策略是缓存，还是直接谢绝，或者是timeout等待，只不过BIO将这块的策略决议确定交给了ThreadPoolExecutor来做了。
对付Acceptor线程中还有一个主要的浸染，便是掌握连接的个数，这个在NIO通道的剖析中没有讲解，这里看一下，Acceptor线程在while轮询的时候，每一次最开始都会检讨一下当前的最大的连接数超出没有，如果超出了，就直接按照既定的序列调用LimitLatch进行锁定。
我们创造，实际上LimitLatch也是模拟JDK中的读写锁，内部持有一个Sync的类，这个类继续了JDK中隐蔽功与名的AQS行列步队，这个AQS行列步队还是比较著名的，之前我的课中在剖析JDK源码的时候，多次在n个并发类中都看到过他的踪迹，实在现险些全部是CAS锁的实现。
5、SocketProcessor线程SocketProcessor是事情任务，用于传入到事情线程池中，输入便是Acceptor传过来的socketWapper包装。
如果是SSL交互的话，Tomcat开放了握手的这个环节，但是并没有对应的实现，这个是由于SSL下的握手实现在SUN的包中做的，JDK供应的SSLServerSocket的接口已经隐蔽了这个细节，我们可以从handshake这个第二步看到（这部分视频中有详细剖析）
Tomcat中直接就可以拿到SSLSession，这个类可以得到相称于SSL已经是握手成功了，否则就会涌现失落败。
对付为什么保留beforeHandShake和handshake这两个步骤，是为了和NIO通道中的SSLEngine交互的接口做个兼容而已。
暂且不用管它，最主要的步骤便是第3步，也便是handler.process这一步，通过Http11ConenctionHandler进行处理http协议，并封装出Response和Request两个工具，通报给后真个容器。
SocketProcessor事情任务便是将Acceptor传过来的socketWapper包装传入到事情线程池中。
6、总结BIO的流程基本上和NIO通道一样，BIO的构造由于短缺了selector和轮询，比较NIO少了一部分的内容，整体上便是利用的ServerSocket来进行通信的，一线程一要求的模式，代码看起来清晰易懂。但是，由于BIO的模型比较掉队，在大多数的场景下，不如NIO，而现在Tomcat新版本也是NIO是默认的配置，8.5版本之后完备抛弃了BIO通道。
八、Tomcat的BIO和NIO通道及对性能的影响1、BIO的缺陷前面两个章节，我们分别看了BIO和NIO两种Tomcat通道的实现办法。
BIO的办法，便是传统的一线程，一要求的模式，也便是说，当同时有1000个要求过来，如果Tomcat设置了最大Accept线程数为500，那么第一批的500个线程直接进入线程池中进行实行，而别的500个根据Accept的限定的数量在做事器真个操作系统的内核位置的socket缓冲区进行壅塞，一贯到前面500个线程处理完了之后，Acceptor组件再逐步的放进来。
剖析一下，这种模式的好处便是可以让一个要求在cpu轮转韶光片切换中最大限度地实行，如果业务要求不是很永劫光的事务处理，常日在一个韶光片内肯定能做完当前的要求，这样的效率算是相称的高了，由于其减少了最耗时也是最头疼的线程高下文切换。
1.但是，如果事务实行比较长的韶光，例准期待一个IO数据库的操作，那么这个事情线程就会根据cpu轮转不断地进行切换，由于要求数在大并发的时候有很多，以是不得不设置一个很高的Accept线程数，那么从cpu的耗费的资源上来看，乃至有70%的韶光摧残浪费蹂躏在线程切换中，而没有真正的韶光去做要求处理和业务，这是第一个问题。
2.其次，BIO每一次链接的建立和开释都须要重新来过一遍，例如一个socket进来之后，常日会对其SocketOptions的属性进行设置，包括各种Connector中配置都要与其进行逐一对应，加上前面说的socket的建立，很多要求通道的资源的初始化都得重新创建，得不到复用，这个是第二个问题。
3.末了，BIO的办法，网络IO的壅塞等待是会让Accept线程事情效率降落很多的。
以是，基于这3个问题，特殊是末了一个问题，引出了NIO的模型。
总结一下便是：
1、如果IO处理韶光长，那么bio大多数韶光耗在线程切换中
2、IO通道得不到复用
3、Acceptor线程事情效率较低
2、NIO的办理之道
NIO的架构分为三个线程池，这里再次梳理一下：
1）Acceptor专门接socket要求，当创造又要求进来后，基于Tomcat配置的SocketOptions和一些属性的设置完毕，包装成SocketChannel，也便是NIO的socket通道抽象，塞入PollerEvent直接扔到行列步队当中。
2）Poller线程从行列步队中挨个获取PollerEvent，调用Poller线程自己持有的selector选择器，注册SocketChannel到当前的selector选择器中，然后进行selectKey的事情，这样Acceptor通报过来的SocketChannel中感兴趣的事宜，就会被轮询出来，当吸收事宜吸收之后，须要注册OP_READ事宜或者OP_WRITE事宜，当OP_READ事宜或者OP_WRITE事宜发生时，开始调用事情线程池。
3）事情线程池便是SocketProcessor，这个便是详细的事情线程，SocketProcessor的任务便是Poller线程从SocketChannel通道中轮询出来的数据包，进行解析，通报给后真个handler进行http的解析，解析出来的Request，Reponse工具，，直接调用CoyoteAdapter通报到后真个容器，通过Mapper，映射到对应的业务Servlet中。可以看到，从SocketProcessor一贯到终极的业务Servlet实现，这些都是一个线程，这个线程便是事情线程。
比拟Tomcat的BIO的架构，由于没有selector轮询的操作，以是并没有Poller线程，BIO中的Acceptor线程的浸染依然是对socket大略的处理和属性包装，然后将socket直接扔到事情线程中来。NIO相称于是多了一个线程池，从流程上来讲，该当是多了一道手续，但是通过NIO本身基于事宜触发的机制造成，Acceptor线程没必要设置得过多，这样从线程的数量上来看，大大地减少线程切换的频率，其次基于事宜进行触发，将Acceptor线程实行效率中的网络IO延迟降落到最低，大大提升了Acceptor线程的实行效率。从这两点上来看，Tomcat的NIO在前面剖析的BIO的三个问题中第一个问题，和第三个问题都有所改进，特殊是第三个问题，全面进行了升级。
但是，对付BIO中的第一个问题，由后端事务韶光过长导致事情线程池一贯在运行，并且运行在一个高峰的数值，不断地进行切换，这种问题，NIO通道也没办法进行处理，这个是由业务来决定的，NIO只能担保降落的是Acceptor线程线程数，对业务帮助也是无能为力的，如果要提升这部分的效率，那就须要运用进行修正，优化JDBC和数据库，或者将业务切段来做，让事务韶光只管即便掌握在一个可控的范畴之内。
对付第二个问题，无论是纯挚的NIO和BIO通道都没有办法进行办理，但是HTTP协议中对链接的复用进行更新，在HTTP1.1中，这个keepalive是加到http要求头中的：
Keep-Alive: timeout=5, max=100 timeout：过期韶光5秒（对应httpd.conf里的参数是：KeepAliveTimeout）；
max是最多能承受一百次要求的共享复用，便是在timeout韶光内又有新的连接过来，同时max会自动减1，直到为0，逼迫断掉。
对应的Tomcat的做事器真个配置：
keepAliveTimeout：表示不才次要求过来之前，tomcat保持该连接多久。这便是说如果客户端不断有要求过来，且为超过过期韶光，则该连接将一贯保持。
maxKeepAliveRequests：表示该连接最大支持的要求数。超过该要求数的连接也将被关闭（此时就会返回一个Connection: close头给客户端）。
如果配置了上述的内容，可以办理BIO上面提出的第二个问题，当一个页面中的第一个要求后，后面的连接可以复用这个socket或者是socketchannel，不用再accept三次握手或者SSL握手了，相称于高效的推动了整体Tomcat的韶光链条的处理效率，而对付keepAlive属性的加入，通过BIO和NIO比拟测试创造，相称于放大了NIO的上风，导致NIO的测试结果要明显高于BIO一个水平线上，这也便是目前http1.1协议中，为什么Tomcat后续版本默认便是NIO的缘故原由；而如果没有keepAlive属性加入，在大多数的场景下，NIO并没有拉开与BIO太大的差距，乃至有一些场景上，Tomcat的BIO模式反倒是比NIO要高。
这里纯挚的比拟性能没有任何的意义，由于性能测试是测试在不同运用类型，不同硬件环境，不同软件版本，乃至是不同jdk性能差异都很大，客不雅观成分很多。
NIO优点总结一下便是：
增加了poller线程池做轮询
提高了acceptor实行效率
3、NIO vs BIO以下4个场景分别是：单线程BIO，多线程BIO，仿照NIO，NIO
4个场景最大的不同便是处理IO流部分，以是性能的高低直接取决于如何处理IO这一步。
由于演示步骤比较繁芜，详细的剖析请大家不雅观看视频，这里不再赘述了。
4、总结1）、BIO比NIO少了poller线程池的轮询机制，要求模式为一线程一要求的模式，这就导致了BIO中存在大量的线程高下文切换。
2）、NIO的多路复用的实质是用更少的线程处理多个IO流。
