Java · BIO/NIO 与 Netty 模型

场景 1 · 静态资源节点 2TB/天: transferTo 零拷贝分发

read/write 循环把文件搬进用户态再搬出去, CPU 全程做搬运工 — 内核能直达的事别经过你。

try (FileChannel file = FileChannel.open(src, StandardOpenOption.READ);
     SocketChannel out = socket.getChannel()) {
    long pos = 0, size = file.size();
    while (pos < size) {
        pos += file.transferTo(pos, size - pos, out);  // 内核里直送 socket
    }
}
// 单次上限 2GB (内部 32 位计数), 循环搬直到返回推进为止
// 实测 1GB 文件: CPU 时间 4.1s → 0.6s, 耗时 18s → 7s (万兆网卡)

场景 2 · 网关 40 万包/秒: 池化 DirectByteBuffer 降 GC

每包 new 一个堆内缓冲, 年轻代直接被 IO 垃圾淹没; Netty 默认就是池化 direct, 显式配明白。

Bootstrap b = new Bootstrap()
    .group(new NioEventLoopGroup())
    .channel(NioSocketChannel.class)
    .option(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT)
    .option(ChannelOption.RCVBUF_ALLOCATOR,
            new AdaptiveRecvByteBufAllocator(64, 4096, 65536));
// 容器兜底: -XX:MaxDirectMemorySize=2g -Dio.netty.maxDirectMemory=2147483648
// 效果: IO 缓冲不进堆, young GC 38 次/分钟 → 4 次/分钟

场景 3 · TCP 拆包: 长度前缀解码的两种写法

TCP 是字节流没有消息边界, 半包粘包是常态 — 二进制协议首选现成解码器。

// 2 字节长度头 + body: 用现成的, 别手撕边界
pipeline.addLast(new LengthFieldBasedFrameDecoder(65535, 0, 2, 0, 2));
//              maxFrameLength  lengthFieldOffset=0  lengthFieldLength=2  剥掉 2B 头
pipeline.addLast(new StringDecoder(StandardCharsets.UTF_8));
pipeline.addLast(new BusinessHandler());

// 手写才需要: 累积 ByteBuf → 够读头再读长度 → body 够了才切给下游,
// 不够就 return 等下次 channelRead 续 — "半包"不是错误是常态

场景 4 · IM 接入层: 单 Selector 线程挂 5 万长连接

长连接心跳用轮询扫表是灾难 — select 带超时醒来顺手清理空闲连接。

Selector selector = Selector.open();
ServerSocketChannel ssc = ServerSocketChannel.open();
ssc.bind(new InetSocketAddress(8899), 1024);   // backlog
ssc.configureBlocking(false);
ssc.register(selector, SelectionKey.OP_ACCEPT);

while (!Thread.currentThread().isInterrupted()) {
    int n = selector.select(1000);            // 最多等 1s, 醒来顺带清心跳
    if (n == 0) { reapIdleConnections(); continue; }
    var it = selector.selectedKeys().iterator();
    while (it.hasNext()) {
        var key = it.next();
        it.remove();                        // 不 remove 会重复处理同一事件
        dispatch(key);
    }
}

4C8G 单机 5 万连接, CPU 常态 15% — BIO 同规模要 5 万线程, 直接不可行。

场景 5 · write 半包: OP_WRITE 只在写不完时注册

大响应写一半内核缓冲满了, 剩余数据挂起等插座可写 — 注册时机就是全部。

void flushPending(SocketChannel ch, SelectionKey key, ByteBuffer remain) {
    while (remain.hasRemaining()) {
        int w = ch.write(remain);
        if (w == 0) {                          // 内核发送缓冲满, 写不动了
            key.interestOps(key.interestOps() | SelectionKey.OP_WRITE);
            key.attach(remain);                   // 挂在 key 上, 可写事件里接着写
            return;
        }
    }
    key.interestOps(key.interestOps() & ~SelectionKey.OP_WRITE);  // 写完立刻取消
}

场景 6 · 500MB 视频上传: 通道对通道流式写盘

不能 readAllBytes (OOM), 也不必用户态中转 — transferFrom 直接落盘。

try (SocketChannel in = socket.getChannel();
     FileChannel out = FileChannel.open(tmp, CREATE, WRITE, TRUNCATE_EXISTING)) {
    long total = 0;
    while (total < contentLength) {
        long n = out.transferFrom(in, total, 1 << 20);  // 每次 1MB
        if (n <= 0) break;                // 对端提前断开, 保留已完成部分
        total += n;
        progress.report(total, contentLength);
    }
    out.force(true);                   // 数据+元数据强制落盘, 防掉电
}

场景 7 · 配置热加载: WatchService 替代 30s 轮询

NIO.2 的目录监听让"改完秒级生效"变成一行注册, 不再空转 lastModified。

WatchService watcher = FileSystems.getDefault().newWatchService();
dir.register(watcher, StandardWatchEventKinds.ENTRY_MODIFY);

WatchKey key = watcher.take();               // 阻塞到有事件, 不烧 CPU
for (WatchEvent<?> e : key.pollEvents()) {
    log.info("config changed: {}", e.context());
    configReloader.reload();
}
key.reset();                                // 不 reset 后续事件收不到
// 遍历大目录同理: Files.newDirectoryStream 惰性迭代, 不吃内存

场景 8 · Netty ByteBuf 释放的 finally 模板

引用计数的内存, 谁消费谁释放 — 忘 release 池化堆外只会越涨越高。

public void channelRead(ChannelHandlerContext ctx, Object msg) {
    ByteBuf buf = (ByteBuf) msg;
    try {
        int len = buf.readShort() & 0xFFFF;    // 无符号语义, 手动去符号位
        process(buf.readBytes(len));
    } finally {
        ReferenceCountUtil.release(msg);   // 不释放 → 池化堆外泄漏
    }
}
// SimpleChannelInboundHandler 会自动 release — 但只对"进来的"消息负责

场景 9 · 压测连接风暴: SO_BACKLOG / SO_REUSEADDR 调优

压测报告 "connection reset / accept queue overflow" — 全连接队列被打满, Java 侧参数还要和内核对齐。

ServerSocketChannel ssc = ServerSocketChannel.open();
ssc.setOption(StandardSocketOptions.SO_REUSEADDR, true);   // 重启不等 TIME_WAIT
ssc.bind(new InetSocketAddress(port), 4096);      // 全连接队列 (backlog)

// 配套内核参数: net.core.somaxconn=4096 — Java 侧大于它会被截断
// Netty 写法: .option(ChannelOption.SO_BACKLOG, 4096)
// 心跳踢人: .childOption(SO_KEEPALIVE, true) + IdleStateHandler(60, 0, 0)

场景 10 · Direct buffer memory OOM 排查 (堆正常)

症状: OutOfMemoryError: Direct buffer memory, 但堆 dump 干干净净 — 泄漏在堆外。

// 原因: 堆外 direct 用量撞上 -XX:MaxDirectMemorySize (默认 ≈ Xmx)

// 排查三连:
// 1. NMT: java -XX:NativeMemoryTracking=summary -jar app.jar (压测后 jcmd 1 VM.native_memory)
// 2. Netty 自检: -Dio.netty.leakDetection.level=paranoid — 日志直接打泄漏栈
// 3. pmap <pid> | grep -i anon 定位增长区间, 对照请求量找源头
// 常见根因: 忘 release / release 后继续用 / 上限设得比 Netty 池还小