阻塞式 vs 非阻塞式 I/O 总结

• 阻塞：调用 accept()/ read()后，线程原地卡死，数据不来永远等着，什么都干不了。
• 非阻塞：调用 accept()/ read()后，线程立刻返回，有就处理，没有就接着干别的。

线程一旦进入 read(connA)，就卡死在里面，根本没机会回去调下一次 accept()。后面的客户端 B 连上了也无人理睬。

要解决只能：每 accept 一个连接，立刻丢给一个新线程去慢慢 read，主线程赶紧回去继续 accept。

这就是阻塞模型的致命缺陷：连接数 = 线程数，根本无法支撑高并发场景。

所有调用都不卡，线程可以在 N 个连接之间飞速跳来跳去：

← 一轮循环，全照顾到了，谁都不耽误 →

但棍子转得再快，99% 的时间你问每个连接「有数据吗？」，回答都是「没」，CPU 在空转，大部分转圈是白费的。

所以有了第三层 — Selector：

第一步解决"能管多个" → 第二步解决"不白费 CPU"

// ========== 阻塞模式 ==========
ServerSocketChannel ssc = ServerSocketChannel.open();
ssc.bind(new InetSocketAddress(8080));
while (true) {
    SocketChannel conn = ssc.accept();        // ← 卡死
    new Thread(() -> {
        conn.read(buf);                       // ← 卡死
    }).start();
}

// ========== 非阻塞模式 ==========
ServerSocketChannel ssc = ServerSocketChannel.open();
ssc.configureBlocking(false);
ssc.bind(new InetSocketAddress(8080));
while (true) {
    SocketChannel conn = ssc.accept();        // ← 立刻返回（null 或连接）
    if (conn != null) {
        conn.configureBlocking(false);
        int n = conn.read(buf);              // ← 立刻返回（0 或有数据）
    }
}

// ========== Selector 模式 ==========
Selector sel = Selector.open();
ServerSocketChannel ssc = ServerSocketChannel.open();
ssc.configureBlocking(false);
ssc.register(sel, SelectionKey.OP_ACCEPT);   // 让 OS 帮你盯着
while (true) {
    sel.select();                             // ← 没事件就睡，不烧 CPU
    for (SelectionKey key : sel.selectedKeys()) {
        if (key.isAcceptable()) { /* 新连接 */ }
        if (key.isReadable())   { /* 有数据 */ }
    }
}

Netty、Redis、Nginx、Tomcat NIO 能支撑几万并发连接，底层全是这套 Selector 机制。