共计 1702 个字符，预计需要花费 5 分钟才能阅读完成。
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 摄像头工具的辅助，定位起来是不是就容易很多了？
本次分享临时到这里了，心愿能给大家带来一些播种，兴许有些同学也有了更多疑难须要被解答，那就请持续关注咱们，或者扫描二维码分割咱们，谢谢大家～
