你是否曾遇到这样的场景？ ● 用户量激增，Spring Boot 应用 CPU 飙升、响应延迟； ● 线程池被打满，大量请求排队甚至超时； ● 服务器配置强劲（多核、大内存），却只能支撑几百并发连接？ 问题的根源，常常不在于业务代码本身，而在于底层 I/O 模型的选择。 在 Java 生态中，I/O 模型经历了从 BIO（阻塞 I/O）→ NIO（非阻塞 I/O）→ AIO（异步 I/O） 的演进

在构建现代高性能网络服务时，开发者常常面临一个根本性问题：如何用有限的系统资源（尤其是线程和内存）高效处理成千上万的并发连接？ 传统的“一个连接一个线程”的阻塞 I/O 模型在面对 C10K（1 万个并发连接）甚至 C10M（100 万个并发连接）挑战时早已力不从心。而像 Nginx、Redis、Kafka、Netty 这样的系统却能轻松支撑数十万并发连接——它们的秘密武器，正是 I/O 多路复用