Tomcat的次要工作是：监听用户通过浏览器发送的网络申请，而后把申请连贯上你的应用程序，做信息替换。在这个过程中，Tomcat里有acceptor、poller、 exec等等这些线程在做这个工作。不过网上很多敌人都认为poller是Tomcat里做socket申请数据读写的线程，然而事实真的是这样吗？
以往，Tomcat的工作就像一个黑盒子一样被封装好在底层架构里，咱们看不到。本次咱们借助了kindling摄像头工具做了个试验，让大家看到每个申请过去之后，所有工作线程的执行实况，以此来确认poller是不是做socket的读写的？首先，咱们先简略回顾一下Tomcat的工作流程：它有两大外围组件，connector和container，其中container装着你的利用程序代码。打个比方，如果这是剧本杀，用户是玩家，你的程序代码是通关宝藏，那connector就是NPC。
然而实际上，真正的网络申请，要远比剧本杀简单的多，所以Tomcat也设计了线程池来应答大量的并发状况。当初咱们再来明确文章一开始提出的疑难：poller线程到底是不是Tomcat里执行socket的读写的线程？下图是我用kindling的摄像头工具捕获记录了一次申请的执行状况。
大家能够先疾速通过下面两张图，略微了解一下这个工具怎么用。我交代一下设置的试验场景：一共做了5个并发申请，每次相隔100ms收回，申请的实现代码是sleep(1000)ms，配置的Tomcat最大的线程数是3。所以这也是一个资源饥饿的场景：并发数有5个，可是线程只有3个，咱们一会也能够看看Tomcat是怎么应答的。我这里用工具捕获的是第一个申请的执行记录。
咱们能够从下面两张图看到，本次申请，最开始是由acceptor先做cpu-on，建设socket连贯，而后把连贯事件交给poller治理，大家留神看，poller执行的工夫戳是.319，而acceptor是318，所以poller 肯定切实acceptor之后才开始执行的。之后，申请事件被交由Tomcat的线程池调配线程exec-1来执行，也就是图中黑线那段。futex代表该线程夯住，或者说在期待，确实，因为我的实现代码写的就是“sleep(1000)ms”。
如上图所示，咱们能够看到，申请流的读写是由执行线程exec-1来做的，netRead即网路流的读写。同理，申请报文的会写也是由exec-1来做的。如下图所示。（这里有两个netwrite是因为报文可能太大，写了两次，第三个netread是exec-1执行下一个申请的事件，因为工夫相差太小，简直重叠了）
至此，咱们能够明确开始提出的疑难了：Tomcat里对于申请流的读写不是由poller线程，而是由exec执行线程来做的。咱们再持续看，5个并发申请，Tomcat只有3个线程，它会怎么应答？
如上图所示，等了大略100ms左右，我的第2个申请进来了，Tomcat线程池调配给了exec-3来执行，同理，第三个申请调配给了exec-2来执行。不过第4、5个申请状况就不一样了。如下图所示，第4、5个申请从客户端发出请求，acceptor建设好连贯，poller做好申请事件治理之后，期待了一段时间，它们才被exec线程执行。因为此时Tomcat没有多余的线程了，它们须要期待有exec线程空下来，能力被执行。
这里反映一种什么景象？对于客户端来说，我前3个申请都很失常，可是第4、5个申请是有一点慢的，它在期待了一段时间之后才开始执行。不过对于服务端来说，它的响应工夫没有任何问题，因为服务端的响应工夫，不是从建设连贯开始，而是从exec线程真正解决这个申请开始计算的。这也是咱们生产环境上常见然而由非常难以排查的资源饥饿的问题，因为从外表上你很难发现症结。然而如果你懂一些Tomcat的原理，再加上kindling摄像头工具的辅助，定位起来是不是就容易很多了？
本次分享临时到这里了，心愿能给大家带来一些播种，兴许有些同学也有了更多疑难须要被解答，那就请持续关注咱们，或者扫描二维码分割咱们，谢谢大家～