面经策

为什么不选择使用原生的 NIO 而选择使用 Netty 呢？ ​

  • 标签：Netty、后端

🏛 业务架构师 ​

我不选原生 NIO 的理由是工程经济学，不是 NIO 不好：

  • NIO 的 API 是"半成品"：Selector、Channel、Buffer 语义底层（OP_ACCEPT/READ 事件分发、buffer 的 flip/clear 状态机），正确使用需要深厚功底——业务团队直接裸写，等于把网络协议栈的坑全部自己趟一遍；
  • 已知的坑很深：JDK NIO 的空轮询 bug（Linux 上 select 空转打满 CPU）、epoll 边沿触发的编程陷阱、TCP 断连重连处理、ByteBuf 管理与内存泄漏——每一项都是可以拖垮服务的事故源；
  • Netty 把这些全部解决并封装：Reactor 线程模型（boss/worker）、成熟的事件分发、内置编解码器与粘包拆包（LengthFieldBasedFrameDecoder 等）、对象池与零拷贝、空轮询自动重建 Selector、开箱即用的心跳与断线重连——十几年生产环境锤炼的正确性，免费继承。

自研 vs Netty 的账：自研协议栈 = 3~5 个高级工程师 × 半年 + 持续踩坑修复；用 Netty = 一周上手 + 社区持续兜底。除非网络框架本身就是你的核心业务（中间件公司做通信产品），自研没有任何商业合理性——研发预算要花在业务差异点上，通用问题买成熟方案。

同款逻辑可以推广到很多选型题：RPC 用 Dubbo 而不是手写 HTTP 调用、锁用 Redisson 而不是自研——架构师的职责是识别"哪里是业务阵地、哪里是别人已经打完的仗"，把兵力集中在前者。

一句话：Netty 是"原生 NIO 的生产可用化"，选它不是能力问题，是资源投放的理性决策。

🏗 系统架构师 ​

不用原生 NIO 而用 Netty，因为原生 NIO 是"半成品零件"，Netty 是"成品发动机"，差距在五方面：

  • Bug 与稳定性：JDK Selector 的空轮询 bug（select 不阻塞空转烧 CPU，Netty 用重建 Selector 自愈）；epoll 的一些边缘问题 Netty 都做了防御；
  • API 易用性：原生 Buffer 的 flip/rewind 状态管理反人类，容易写出翻转错位的 bug；ChannelFuture 事件驱动异步模型直接可用；Netty 的 ByteBuf 双指针（readIndex/writeIndex）+ 引用计数 + 池化，杜绝 flip 类错误并降 GC 压力；
  • 粘包拆包/编解码：原生要自己处理消息边界，Netty 提供 LengthFieldBasedFrameDecoder 等开箱解码器全家桶与自定义编解码框架；
  • 线程模型：原生要自己搭 Reactor 多线程模型（主从 Selector、事件分发、线程切换），Netty 的 Boss/Worker EventLoopGroup + Pipeline 是现成的高并发骨架；
  • 性能优化集成：池化直接内存、零拷贝（CompositeByteBuf/FileRegion）、GC 友好（对象池）、背压机制，都是调过多年生产参数的成果。

架构判断：网络框架是典型"高投入高频复用"组件，自研等于重新踩一遍别人踩过的坑。我做技术选型的原则：底层基础设施选生态最成熟者，业务差异化才自研——Netty 之于 TCP，就像 Spring 之于 Java 应用，是行业共识资产的复用。

💻 全栈开发专家 ​

结论：原生 NIO 能用但"脏活太多"，Netty 把这些脏活工程化了。我对比着说：

1. JDK NIO 的 epoll 空轮询 bug：select() 假唤醒导致 CPU 100%，JDK 多年不修；Netty 检测到空轮询计数超阈值自动重建 Selector 见避。

2. API 堪称反人类：

  • ByteBuffer 的 flip/rewind/clear 指针操作极易出错；
  • Selector 事件循环、线程编排全要自己写，几百行 boilerplate；
  • SocketChannel 的配置（TCP_NODELAY、SO_KEEPALIVE）要逐个手调。

Netty 给 ByteBuf（读写双指针 + 池化 + 引用计数）、ChannelPipeline（编解码器即插即用）、EventLoopGroup（主从 Reactor 模型开箱即用）。

3. 粘包拆包要自己实现：长度字段、分隔符解码器 Netty 全有，一行 addLast。

4. 性能优化已内建：堆外内存池化（jemalloc 思路）、对象复用（FastThreadLocal）、零拷贝（CompositeByteBuf/slice）——自己写 NIO 很难做到这个水平。

5. 稳定性细节：连接超时、空闲检测（IdleStateHandler 心跳）、优雅关闭、异常处理链，Netty 都封装好了。

我的类比：原生 NIO 之于 Netty，就像 Servlet 之于 Spring MVC——不是不能用，是每个项目都在重复造轮子，而且造得还不如它稳。真正读一两个 Netty 的 pipeline 实现，反过来还能加深对 NIO 的理解。