#万能生活指南#

大家好，我是小米，一个热爱折腾代码、咖啡不离手的31岁程序员。最近又陪着几位朋友刷面试题，刷到了一道看似“简单”，但经常让人翻车的题：

“Tomcat 有哪几种 Connector 运行模式？说说它们的区别和应用场景。”

很多人一听这题，脑子里立刻闪过一句话：“Connector？是那玩意儿负责接收请求的吗？”

没错！但是——要真答得漂亮，还得深入到“BIO、NIO、APR”三种运行模式的原理和使用场景里去。

今天，小米就带你一口气把这道题，从“面试背诵版”讲到“架构理解版”，再到“实战调优版”。

故事的开头：Tomcat是怎么接请求的？

有次在公司上线项目，夜半我还在调试Tomcat性能问题。线上用户一多，Tomcat 的线程数就爆了。那时我一脸懵：“这玩意儿到底是怎么处理请求的？”

后来，我才真正理解：Tomcat 的世界，其实分为两个关键角色——Connector 和 Container。

Connector 是门卫，负责“接活”——接受 HTTP 请求。Container 是大厨，负责“做饭”——处理 Servlet 逻辑。

而这道题中的 Connector 运行模式，说的就是“门卫接活的三种姿势”：

BIO（阻塞 I/O）NIO（非阻塞 I/O）APR（Native 底层优化 I/O）

别急，我们一个个拆开说。

第一代门卫：BIO 模式（Blocking I/O）

想象一下，门口只有一个门卫老张。每当有客户上门（一个 HTTP 请求），老张就亲自接待，全程陪聊，直到客户满意离开。

问题来了——如果客户多了呢？

没错，老张要累趴。

这就是 BIO 模式：

每个请求都由一个独立线程处理。如果请求阻塞或等待，线程就卡死。对系统资源消耗大，不适合高并发。

Tomcat 在 7.0 以前，默认就是这种模式。配置上，它对应的是：

protocol="org.apache.coyote.http11.Http11Protocol"

这个模式的优点是实现简单，调试方便，但在如今的互联网场景中，几乎没人再用了。

不过面试官喜欢问，因为它是理解后面两种模式的基础。

第二代门卫：NIO 模式（Non-blocking I/O）

后来公司请来了新门卫——小李。小李聪明得很，他采用了“轮询制”：

有人来时，先登记一下；一旦后厨（Servlet）有空，就通知来客进来。

这样他一个人就能同时应付很多客户。

这就是 NIO 模式 的思想：

使用 Java NIO 库（非阻塞 I/O）；通过 Selector 机制同时管理多个连接；不再为每个请求开新线程，而是复用线程池。

对应的配置是：

protocol="org.apache.coyote.http11.Http11NioProtocol"

这个模式在 Tomcat 8 以后成为默认模式。

性能比 BIO 高出一大截，能抗住几千甚至上万并发连接。

可以说，NIO 是现在最常见、最稳定的生产配置。

第三代门卫：APR 模式（Apache Portable Runtime）

有一次项目上线到 Linux 服务器上，运维哥说：“小米啊，你这 Tomcat 再怎么调线程数也没用，CPU 都跑不动了！”

这时我发现 Tomcat 还有一个隐藏大招——APR 模式。

APR（Apache Portable Runtime）不是 Java 写的，而是基于 C 语言 实现的一套本地库。通俗点讲，就是 Tomcat 找了一个会用“汇编技能”的超级门卫。APR 直接调用底层 Socket API，绕过了 JVM 的一些性能瓶颈，提供更高效的 I/O。

优点非常明显：

基于本地方法调用（JNI），速度快；利用操作系统特性（如 sendfile、epoll）；性能逼近 Nginx。

配置时写法是：

protocol="org.apache.coyote.http11.Http11AprProtocol"

但要注意，APR 依赖于系统环境，要提前安装 Tomcat Native 库。否则 Tomcat 启动时会自动回退到 NIO 模式。

三种模式的对比总结

面试时，别只背这个表。你要顺势解释：

“Tomcat 从 8.0 开始默认使用 NIO，因为它在纯 Java 层实现高并发已足够。只有极致性能或特定系统需求时，才考虑 APR 模式。”

如何判断当前模式？

在 Tomcat 启动日志里会打印类似信息：

看到了吧？那一串 “http-nio-8080” 就告诉你当前模式是 NIO。如果是 BIO，就是 “http-bio-8080”；如果是 APR，就是 “http-apr-8080”。

面试官延伸问：那怎么选择？

这题很常见，我帮你准备三种“风格化回答”，面试时可以灵活切换：

稳妥型回答：“一般选择 NIO，性能和兼容性都好。BIO 只适合低并发环境，APR 性能更强，但配置复杂。”架构型回答：“我们会根据部署平台选择：内网服务或小型系统用 NIO；高性能 API 网关或长连接业务（比如 WebSocket）会考虑 APR。”进阶型回答：“其实 Tomcat 9 后 NIO2 模式也可选（基于 Java AIO 实现），理论上支持更高并发，不过生态兼容性还在完善。”实战：我如何把 NIO 性能调到飞起？

那次优化项目性能，我做了三个关键动作：

线程池参数优化：调整 maxThreads、minSpareThreads，让 Tomcat 线程池不浪费。开启 Keep-Alive 与压缩：提高连接复用率，减少 TCP 建连次数。监控连接状态：借助 JMX 观察连接数、请求处理时间，定位慢请求。

最终，我们的系统从 2000 QPS 提升到了近 9000 QPS，Tomcat 仍旧稳得一匹。

从那以后，我对 Connector 模式算是彻底开窍了。

结语：别只记答案，要理解背后的设计哲学

很多面试题其实不是考死记硬背，而是想看你能不能从设计角度理解。

Tomcat 为什么要提供三种模式？

因为世界没有万能的方案——每个模式，都有它的“场景哲学”：

BIO： 简单直白，适合教学与低并发；NIO： 平衡之选，适合绝大多数应用；APR： 极致性能，适合专用高性能服务器。

所以，下一次当你面对面试官问出“Tomcat 有哪几种 Connector 运行模式？”

请不要急着背答案，而是微笑着说：

“让我讲个故事吧，从那年我第一次调 Tomcat 性能开始……”

——那一刻，你已经赢了。

END

我是小米，一个喜欢分享技术的31岁程序员。如果你喜欢我的文章，欢迎关注我的“软件求生”，获取更多技术干货！