阻塞 vs 非阻塞：IO 与 NIO 的正面对决

原文来自于：zha-ge.cn/java/20

阻塞 vs 非阻塞：IO 与 NIO 的正面对决

引子：一次性能危机的觉醒

那是一个月黑风高的晚上（好吧，其实是普通的工作日下午），我们的在线客服系统突然死机了。监控显示服务器 CPU 不高、内存充足，但就是响应不过来。用户投诉电话一个接一个，我坐在工位上，感觉像是坐在火山口。

经过一番排查，罪魁祸首竟然是我们用的传统 BIO（阻塞 IO）。每个客户端连接都占用一个线程，而这些线程大部分时间都在傻傻地等待数据，就像排队买奶茶的人群------每个人占着位置，但收银员可能去厕所了。

这次事故让我开始重新审视 IO 和 NIO 的选择，也由此开启了一段"阻塞与非阻塞的爱恨情仇"。

探索：传统 BIO 的温柔陷阱

最初选择 BIO，是因为它写起来简单直观，就像谈恋爱时的初恋------纯真美好：

java 复制代码

// BIO 的典型写法，简单粗暴
ServerSocket server = new ServerSocket(8080);
while (true) {
    Socket client = server.accept(); // 阻塞等待连接
    new Thread(() -> {
        try (BufferedReader reader = new BufferedReader(
                new InputStreamReader(client.getInputStream()))) {
            String message = reader.readLine(); // 阻塞等待数据
            // 处理消息...
        }
    }).start();
}

这种方式在用户量少的时候，表现得像个乖巧的小绵羊。但当并发量上来后，问题就暴露了：

线程开销大：每个连接一个线程，1000 个连接就是 1000 个线程
资源浪费：大部分时间线程都在等待，CPU 却要维护这些"摸鱼"的线程
扩展性差：线程数量有上限，达到瓶颈后就是灾难

就像一家餐厅，每个顾客都配一个专属服务员，服务员大部分时间在等顾客点菜，结果人工成本爆炸，效率却低得可怜。

转折：初遇 NIO 的复杂美

听说 NIO 能解决 BIO 的问题，我满怀期待地开始学习，结果第一眼看到代码就懵了：

java 复制代码

// NIO 的经典套路，看起来就很"专业"
Selector selector = Selector.open();
ServerSocketChannel serverChannel = ServerSocketChannel.open();
serverChannel.configureBlocking(false); // 非阻塞模式
serverChannel.register(selector, SelectionKey.OP_ACCEPT);

while (true) {
    selector.select(); // 阻塞等待事件
    Set<SelectionKey> keys = selector.selectedKeys();
    for (SelectionKey key : keys) {
        if (key.isAcceptable()) {
            // 处理连接事件...
        } else if (key.isReadable()) {
            // 处理读事件...
        }
    }
    keys.clear();
}

这代码看起来就像高数课本------明明每个字都认识，连在一起就不知道在说什么了。各种 Channel、Selector、Buffer 概念满天飞，学习曲线陡得像珠穆朗玛峰。

踩坑瞬间：NIO 的那些"惊喜"

刚开始用 NIO 时，我踩了不少坑：

忘记切换非阻塞模式：结果 NIO 表现得和 BIO 一样，白忙活
Buffer 的 flip() 和 clear()：经常忘记调用，导致数据错乱
空轮询 Bug：在某些 Linux 版本上，selector.select() 可能立即返回，CPU 飙到 100%

最让人崩溃的是，写了半天代码，性能测试结果竟然还不如原来的 BIO！当时的心情就像精心准备了一桌菜，结果客人说还不如泡面好吃。

解决：找到平衡点的艺术

经过反复实践和调优，我终于理解了 IO 和 NIO 各自的适用场景：

java 复制代码

// 现代化的解决方案：结合 Netty 框架
EventLoopGroup bossGroup = new NioEventLoopGroup(1);
EventLoopGroup workerGroup = new NioEventLoopGroup();

ServerBootstrap bootstrap = new ServerBootstrap()
    .group(bossGroup, workerGroup)
    .channel(NioServerSocketChannel.class)
    .childHandler(new ChannelInitializer<SocketChannel>() {
        protected void initChannel(SocketChannel ch) {
            ch.pipeline().addLast(new MyServerHandler());
        }
    });
// ...

选择策略总结：

场景	推荐方案	理由
连接数 < 1000，处理简单	BIO	开发效率高，维护成本低
高并发，长连接	NIO	资源利用率高，扩展性好
复杂业务逻辑	BIO + 线程池	平衡性能与开发效率
对性能要求极高	NIO + Netty	专业框架，久经考验

经验启示

这次 IO 与 NIO 的较量让我明白了几个道理：

技术选型没有银弹。BIO 简单但不适合高并发，NIO 高效但学习成本高。就像选择交通工具，短途走路最方便，长途还得坐飞机。

理解原理比记住 API 更重要。当你理解了阻塞和非阻塞的本质区别，就知道什么时候该用什么技术了。

渐进式优化策略。先用 BIO 快速实现功能，遇到性能瓶颈再考虑 NIO。过早优化是万恶之源，过晚优化是灾难之始。

现在回头看那次性能危机，虽然当时很痛苦，但它让我真正理解了 IO 模型的精髓。有时候，最好的老师不是教科书，而是生产环境的那一声声报警。

技术如人生，没有完美的选择，只有合适的决定。你的项目适合用哪种 IO 模型呢？