前段时间把手里的 Java 面试题重新整理了一遍，发现 BIO、NIO、AIO 和 Netty 这部分几乎是每次面试必问，而且问法越来越刁钻。有人能背出概念，但一提到 Selector 的底层模型就解释不清；有人用过 Netty，但被追问 EventLoop 的线程分配和内存泄漏又当场卡壳。这篇把整理出来的 35 道高频题和答案完整摊开，覆盖原理、组件、源码场景、手写代码和线上问题排查，适合准备 Java 后端岗位面试的同学，也适合刚接触 Netty、想快速搭建完整知识框架的人。建议边看边动手写，别只背答案。
1. BIO、NIO、AIO基础题与原理拆解
1.1 五个绕不开的IO模型概念题
第1题：BIO、NIO、AIO三者的核心区别是什么？
BIO 是同步阻塞 IO，一个客户端连接对应一个线程，线程在读写数据时会被卡住，直到操作完成。连接少的时候没问题，连接一多，线程数会暴涨，CPU 大量时间浪费在线程切换上。NIO 是同步非阻塞 IO，核心是 Channel、Buffer、Selector，一个线程通过 Selector 监控大量连接，只有当某个 Channel 有读或写事件时才去处理，不用每个连接都开一个线程。AIO 是异步非阻塞 IO，应用发起读写后直接返回，由操作系统在数据复制完成后通知应用，不需要应用线程自己等。不过 Linux 下的 AIO 实现一直不够成熟，Netty 虽然支持 AIO，但默认并没有选择它，这一点面试时最好主动说出来。
第2题：同步、异步、阻塞、非阻塞四个概念怎么区分？
同步和异步关注的是消息通知方式。同步是调用方主动去获取结果，异步是被调用方完成后再通知调用方。阻塞和非阻塞关注的是调用方在等待结果时的状态，阻塞表示线程挂起等待，非阻塞表示线程可以先去干别的事。四个组合里，BIO 是同步阻塞，NIO 是同步非阻塞，AIO 是异步非阻塞。很多候选人把“非阻塞”就当成“异步”，其实是错的。一个很经典的例子：你去餐厅吃饭，站在取餐口一直等饭做好，这是同步阻塞；取完号坐在旁边刷手机，过一会儿去看一眼好了没，这是同步非阻塞；留了个手机号，人家做好后打电话叫你来取，你去拿现成的，这才是异步。
第3题：为什么说NIO是同步非阻塞？明明用了Selector，为什么不算异步？
Selector 确实帮我们解决了“同时等待多个连接”的问题，但它的 select 方法只是告诉你哪些 Channel 就绪了，真正执行 read/write 时，还是由当前线程自己把数据从内核缓冲区拷贝到用户缓冲区，这个拷贝过程是同步的，应用线程必须参与完成并等待结果。异步的定义是发起 IO 操作后整个读写由内核完成，完成后再回调通知。NIO 不具备这个特征。Netty 里很多写法看起来像异步，比如 ChannelFuture 和回调，那是 Netty 框架在 IO 事件处理之外做的异步包装，底层的数据读写仍然离不开线程的同步处理。面试时如果能把这个底层差异讲清楚，印象分会高很多。
第4题：BIO、NIO、AIO各自的适用场景是什么？
BIO 适合连接数量少、并发压力不大的传统业务，比如企业内部的简单数据上报接口，模型直观，出了问题好排查。NIO 适合高并发、长连接类的场景，比如网关、IM、消息推送，连接数可能几万甚至几十万，但每条连接不是时刻都在读写。AIO 在理论上适合大量 IO 操作且希望系统自动回调的场景，但实际项目里很少直接用 Java 的 AIO，因为性能没有碾压 NIO，编程模型也复杂。Netty 虽然没有默认用 AIO，但它在 NIO 之上通过事件循环和 Future 把异步体验做到了很高的水平，所以掌握 Netty 其实比单纯研究 AIO 更实用。
第5题：什么是IO多路复用？它和普通阻塞IO的底层差异在哪里？
简单说，IO 多路复用就是一个线程能盯住多个 socket，内核负责监控这些 socket 的状态，哪个有动静了就通知线程去处理。BIO 是每个 socket 派一个线程去 read，read 不出来线程就睡在那，这种方式在线程数少时没问题，但一万个连接就得一万个线程，调度成本高得吓人。多路复用把“等待”这件事集中到内核，select、poll 需要遍历所有 fd，复杂度高；epoll 改成了事件回调机制，只通知真正就绪的 fd，所以能撑起百万连接。Netty 在 Linux 下优先使用 epoll，这也是它能支撑高并发的底层原因。
1.2 NIO核心组件与细节追问
第6题：NIO的三大组件是什么？各自的作用是什么？
三大组件是 Buffer、Channel、Selector。Buffer 是内存缓冲区，所有数据读写都必须经过 Buffer，NIO 不像 BIO 那样直接操作流，而是读到 Buffer 里再处理，写数据也是先写入 Buffer 再通过 Channel 写出。Channel 是双向通道，既能读也能写，常见的有 SocketChannel、ServerSocketChannel、FileChannel。Selector 是选择器，把多个 Channel 注册到它上面，通过 select 方法监听事件，解决了一个线程管理多个连接的问题。理解三者的关系可以类比成：Channel 是一条水管，Buffer 是一个水桶，Selector 是一个监督员，监督员同时看着很多水管，哪条水管有水来了就叫人去接。
第7题：Buffer的flip和clear有什么区别？为什么要调flip？
Buffer 里有 position、limit、capacity 三个关键属性。往 Buffer 里写数据时，position 表示当前写到哪了，limit 等于 capacity。写完想读数据，必须调用 flip，把 limit 设置到当前 position，再把 position 重置为 0，这样读的时候才不会越界。clear 的作用是准备重新写数据，把 position 设置为 0，limit 设置为 capacity，但并不会真正清空旧数据，只是让你覆盖它。很多人写 NIO 程序忘记 flip 导致读出来的数据不对，或者读到空内容，核心原因就是对这三个属性没理解透。面试时可以手画一下状态变化过程，会显得基本功很扎实。
第8题：Selector的keys和selectedKeys有什么区别？
keys 是当前所有注册到 Selector 上的 Channel 对应的 SelectionKey 集合，不管事件是否就绪，里面都有。selectedKeys 是 select 方法返回后，那些已经有事件发生、需要处理的 SelectionKey 集合。每次处理完事件后要调用 iterator.remove()，把这个 key 从 selectedKeys 里移除，否则下次 select 返回后它还留在集合里，会重复处理已经处理过的事件。这也是很多 NIO 程序偶发重复读写问题的来源。Netty 在它自己的 NioEventLoop 里已经把这层封装好了，但手写 NIO 时这一步特别容易踩坑。
第9题：什么是空轮询？NIO的bug是怎么回事？
Java NIO 在 Linux 上使用 epoll 时，某些版本的 JDK 存在一个 bug：即使没有事件就绪，select 方法也可能被唤醒，而且返回值是 0，如果程序没有检测到这个情况继续循环，就会导致空转，CPU 飙高。Netty 通过记录 select 方法空转的次数，如果连续多次空转，就重建 Selector 来规避这个问题。手写 NIO 时也可以在循环里判断 select 返回值是否大于 0，再配合一定的 sleep 避免空转。面试时说出这个 bug 的根源和 Netty 的解决策略，说明你真的深入看过源码，而不只是用过 API。
第10题：直接内存和堆内存缓冲区有什么区别？
直接内存缓冲区是 DirectBuffer，数据分配在操作系统内存中，不在 JVM 堆内，避免了 Java 堆和内核之间的数据复制。堆内缓冲区是 HeapBuffer，创建和回收由 GC 管理，但进行 IO 时需要先从堆复制到堆外内存，多一次拷贝。直接内存的申请和释放成本比堆内存高，所以不能滥用。Netty 的 ByteBuf 默认使用池化直接内存，在高并发下减少拷贝，但需要小心释放，否则容易内存泄漏。面试中如果被问“为什么 Netty 要分堆内外”，可以从 GC 压力和零拷贝两个角度答。
2. Netty核心组件与线程模型
2.1 EventLoop和Reactor模型高频问答
第11题：Netty的Reactor模型与传统NIO编程有什么关系？
传统手写 NIO 时，你要自己维护一个 Selector，自己写 while 循环 select，再根据返回的事件去处理 accept、read、write，代码很容易写散。Netty 把这件事抽象成了 Reactor 模式，并且实现了主从多 Reactor：bossGroup 中的 EventLoop 负责 accept，workerGroup 中的 EventLoop 负责读写，每个 EventLoop 内部就是一个不断 select 的事件循环。你可以把 EventLoop 看成“带任务队列的线程 + Selector”，它本质上就是传统 NIO 编程里那个 while 循环的封装。回答时可以从单线程 Reactor、多线程 Reactor、主从 Reactor 的演进讲起，Netty 是主从 Reactor 的典型实现。
第12题：bossGroup和workerGroup分别负责什么？
bossGroup 负责监听服务端端口，接收客户端连接，收到连接后把对应的 SocketChannel 注册到 workerGroup 的某个 EventLoop 上。workerGroup 负责后续该连接的读写、编解码、业务处理传播。实际开发中 bossGroup 的线程数可以设置得很少，通常 1 个就够了，因为 accept 事件本身不是高负载操作；workerGroup 的线程数一般设置为 CPU 核数的两倍，但具体要看业务是否偏 IO 密集。如果业务 handler 里包含重计算，还需要把业务逻辑挪到独立业务线程池，而不是盲目加大 worker 线程数。面试官问两者的分工，实际上是在考察你是否真的理解 Netty 的事件处理模型。
第13题：EventLoop的线程数如何设置？一个EventLoop可以注册多个Channel吗？
Netty 的 NioEventLoopGroup 默认线程数不设置时是 CPU 核数的两倍，可以通过构造方法传入自定义数量。每个 EventLoop 会绑定一个线程，可以注册多个 Channel，但一个 Channel 在其生命周期内只会绑定到一个 EventLoop。这意味着同一个 Channel 的所有 IO 事件和执行任务，都在同一个线程里顺序执行，避免了锁竞争。这也是 Netty 高性能的一个关键点。但要注意，正因为一个 EventLoop 管理多个 Channel，如果某个 Channel 的处理逻辑阻塞了这个 EventLoop，其他连接也会跟着受影响，这也是下一题为什么要强调 handler 不能耗时的原因。
第14题：ChannelPipeline中的handler执行顺序是什么？
ChannelPipeline 是一个双向链表，每个节点是一个 ChannelHandlerContext，内部持有 handler。事件的传播方向决定了顺序：Inbound 事件（如 channelRead、channelActive）从链表头部往尾部传播，先添加的 handler 先执行；Outbound 事件（如 write、flush）从链表尾部往头部传播，后添加的 handler 先执行。调用 ctx.fireChannelRead() 才会继续传给下一个 Inbound handler，不调用传播就会停止。对于 Outbound，ctx.write() 会从当前节点往前找 Outbound handler。面试时能画出入站和出站的执行路径，比单纯背顺序要加分。
第15题：为什么handler里不能做耗时操作？耗时的逻辑应该放哪？
Netty 的 IO 线程就是 EventLoop 线程，所有注册在同一个 EventLoop 上的 Channel 都由这一个线程驱动。如果在 handler 的 channelRead 里做耗时的数据库查询、远程 RPC 调用或大文件处理，整个 EventLoop 会被卡住，其他连接到这个 EventLoop 的所有读写都会延迟，严重时心跳超时、连接被误判为死连接。正确做法是把耗时任务提交到独立的业务线程池，比如自建的 ThreadPoolExecutor，或者使用 Netty 提供的 DefaultEventExecutorGroup，把对应的 handler 指定到 DefaultEventExecutorGroup 上执行，隔离慢任务对 IO 线程的影响。回答时如果能主动提这个方案，面试官会认为你有线上经验。
2.2 ChannelHandler、ByteBuf与编解码核心题
第16题：ByteBuf与ByteBuffer有什么区别？为什么Netty要自己实现ByteBuf？
JDK 的 ByteBuffer 只有一个 position，读和写要手动 flip，容量固定，不能自动扩容。Netty 的 ByteBuf 把读指针 readerIndex 和写指针 writerIndex 分开，读写不需要 flip，还支持动态扩容、池化、引用计数、直接内存和堆内存统一抽象。计算可读长度直接用 writerIndex - readerIndex，语义非常清晰。此外 ByteBuf 提供了 slice、duplicate、CompositeByteBuf 等零拷贝能力。面试时可以提一句：Netty 不需要每次 IO 都重新分配一个 ByteBuffer，而是通过池化复用来减少 GC 压力和内存分配开销，这是高并发下性能稳定的重要原因。
第17题：什么是零拷贝？Netty的零拷贝体现在哪几个地方？
零拷贝的意思是尽量避免在内核态和用户态之间、或在用户态内存各处之间复制数据。Netty 里的零拷贝主要有几个层面：一是使用 DirectBuffer，让 ByteBuf 本身就处于堆外内存，减少 JVM 堆到系统缓冲区的一次复制；二是 CompositeByteBuf 能把多个 ByteBuf 组合在一起，逻辑上是一个完整的缓冲区，但物理上并不合并；三是 ByteBuf 的 slice、duplicate 方法可以在原缓冲区基础上创建视图，不用拷贝数据；四是 FileRegion 包装文件，支持 transferTo 系统调用，直接在操作系统层面把文件数据发送到 socket，无需经过用户态。面试时不要只答一个点，分层次说会更有说服力。
第18题：粘包拆包怎么解决？Netty提供了哪些解码器？
TCP 是字节流协议，底层没有消息边界，应用层发多次 send 的数据可能被合并成一个包，也可能一个包被拆成多个片段。解决思路就是让接收端知道每条消息的边界。Netty 提供了很多现成解码器：FixedLengthFrameDecoder 固定长度，LineBasedFrameDecoder 按换行符，DelimiterBasedFrameDecoder 按自定义分隔符，LengthFieldBasedFrameDecoder 按消息头里的长度字段读取完整帧。实际生产中用 LengthFieldBasedFrameDecoder 最多，因为它能适应大部分私有协议。需要注意的是，LengthFieldBasedFrameDecoder 有很多参数，lengthFieldOffset、lengthFieldLength、lengthAdjustment、initialBytesToStrip 这几个如果配置错，半包问题依旧会出现。
第19题：如何自定义一个协议？一般包含哪些字段？
自定义协议的核心是让收发双方都能从字节流里准确提取出一条消息。常见设计是：魔数 + 版本号 + 消息类型 + 序列化方式 + 消息长度 + 消息体 + 可选扩展字段。魔数用于快速校验是否是合法报文，比如 4 个字节；版本号用于协议升级兼容；消息类型用来区分请求、响应、心跳；序列化方式决定 body 解析方式；长度字段最关键，接收端读完长度后就知道要再读多少字节才算一条完整消息。设计时还要考虑字节序、大端还是小端、是否带 CRC 校验。回答时可以顺便提一下，如果协议里没有长度字段，就只能用固定长度或分隔符，灵活性很差。
第20题：编码器解码器怎么选择继承哪个类？
Netty 里做编码器通常继承 MessageToByteEncoder，把 Java 对象编码成字节写入 ByteBuf；如果要编码成另一个对象类型，可以继承 MessageToMessageEncoder。解码器通常继承 ByteToMessageDecoder，从 ByteBuf 中读取字节并解码成一个或多个对象；如果担心粘包和半包，可以在这个类之前加一个 FrameDecoder，或者继承 ReplayingDecoder，让 Netty 自动在可读字节不足时等待，相当于简化了半包判断逻辑。如果解码的是对象到对象，就继承 MessageToMessageDecoder。一个容易忽略的细节是：ByteToMessageDecoder 默认会累加接收到的字节，所以不需要自己保存上次剩余的包，但这个类处理完消息要记得是否及时释放引用计数。
3. Netty高级特性与线上排障
3.1 高并发与内存话题
第21题：Netty的Future和Promise有什么区别？
Netty 的 Future 继承自 java.util.concurrent.Future，但增加了添加监听器的功能，能够异步回调。Promise 是 Future 的一个可写实现，除了能读取结果，还允许通过 setSuccess、setFailure 来手动完成，后续可以通过 listener 拿到成功或失败结果。简单理解：Future 是只读的结果容器，Promise 是可以在任务流程任意节点写入结果的容器。在自定义异步逻辑时经常会用 Promise，例如你发起一个远程调用，先创建一个 Promise 返回给上层，等底层真正的响应到来后再 setSuccess。面试时把这个“可写”特性说出来，基本就到位了。
第22题：Netty如何实现心跳机制？IdleStateHandler的使用要点是什么？
心跳是为了探测连接是否还活着，通常客户端定时发心跳包，服务端定期检测是否有数据往来。Netty 里可以直接在 pipeline 里添加 IdleStateHandler，参数包括读空闲时间、写空闲时间、全部空闲时间和时间单位。比如 new IdleStateHandler(120, 0, 0) 表示 120 秒内没有读事件就会触发 userEventTriggered，会收到 IdleStateEvent。这时候可以关闭连接，或者发送一个 ping 探测包。要注意的是，IdleStateHandler 本身不发送心跳，只负责触发事件，真正的心跳逻辑要自己实现。线上常见误区是把读空闲时间设置得太短，导致一些慢业务连接被误杀，建议结合业务压测来调。
第23题：连接断了怎么自动重连？
客户端和服务端断连后，Netty 会在客户端侧触发 channelInactive。重连的基本思路是：在 channelInactive 里拿到当前 Bootstrap，重新调用 connect，然后做 channel 关闭清理。为了防止断网后频繁重连打崩服务端，通常要加延迟和重试上限。常见做法是使用定时器，按指数退避策略延时重连，例如 1 秒、2 秒、4 秒、8 秒，最多重试 N 次。还可以在重连前判断当前是否已关闭，避免重复发起。服务端一般不主动往客户端重连，客户端断开后清理对应资源，等待新的连接即可。面试时能说出退避策略，说明你考虑过真实网络环境。
第24题：写数据时为什么要判断Channel.isWritable？
每个 Channel 有一个写缓冲，也就是 ChannelOutboundBuffer。如果客户端消费速度慢，服务端又不停写数据，这个缓冲会不断增长，最终可能导致内存溢出。Netty 提供了高水位和低水位机制，当缓冲超过高水位时，Channel 自动变为不可写，isWritable 返回 false。官方建议写数据前先判断 isWritable，如果不是可写状态，就不要继续写，可以把数据暂存到队列里，等待 ChannelWritabilityChanged 事件恢复后再补发。这个机制就是背压的一种实现。比较常见的是推送场景，某个客户端网速慢，如果服务端不限制发送速度，堆外内存占用会暴涨。
第25题：Netty如何防止内存泄漏？
ByteBuf 使用引用计数来管理生命周期，每次 retain 会增加引用计数，release 会减少，当引用计数归零后内存会被回收。使用池化 ByteBuf 时尤其要注意：你在 handler 里通过 context.alloc().buffer() 创建的 ByteBuf，如果不进行 release，它会一直留在池里占着内存，最终造成泄漏。在 ChannelInboundHandler 的 channelRead 中，如果这个 msg 没有被 SimpleChannelInboundHandler 自动释放，用完必须 ReferenceCountUtil.release(msg)。对于 ctx.writeAndFlush(msg)，Netty 会在写完自动释放。面试时最好补充一句：可以通过修改 JVM 参数 -Dio.netty.leakDetection.level=PARANOID 来开启更激进的内存泄漏检测，但生产环境要评估性能影响。
第26题：什么是背压？水位线怎么设置？
背压就是当消费端处理不过来时，把压力反向传递给上游，让上游降低发送速率。Netty 的写缓冲水位线由 WriteBufferWaterMark 控制，默认低水位是 32KB，高水位是 64KB。当一个 Channel 的写缓冲数据量超过高水位时，它会被标记为不可写；降到低水位以下时恢复可写。你可以通过 ChannelConfig.setWriteBufferWaterMark 自定义这两个值。如果消息体比较大，例如每条几十 KB，默认水位会导致 isWritable 频繁变为 false，这时可以适当调高，但也别太高，否则内存压力会转移到 Netty 外部队列。面试被问到高并发下如何保证不 OOM，背压是一个重要的回答方向。
第27题：NioEventLoop里跑了一个耗时任务会有什么后果？
后果很直接：这个 EventLoop 线程被阻塞，所有绑定在该线程上的 Channel 都无法执行 IO 事件。假如这个 EventLoop 上注册了一千个连接，这一千个连接相当于全部暂停。最典型的线上问题就是某个业务 handler 里执行了同步数据库查询，导致大量连接心跳超时、服务端看起来像是假死。千万不要直接用 channel.eventLoop().execute() 去执行耗时任务，因为这个任务还是在同一个 EventLoop 线程里执行。正确做法是把耗时任务提交到独立的业务线程池，或者用 DefaultEventExecutorGroup 将某个 handler 单独放到另一个线程组里。这部分也是面试官区分“用过 Netty”和“真正理解 Netty”的关键。
第28题：ctx.write和ctx.channel().write区别？
ctx.write 会从当前 ChannelHandlerContext 开始，向前查找第一个可写方向的 Outbound handler，影响范围是当前 handler 之后的部分链路。ctx.channel().write 会从 pipeline 的尾部开始，往前穿透整个 Outbound 链，所以它会先经过所有 Outbound handler，包括当前 handler 后面的所有节点。通常更推荐 ctx.write，因为它更精准，不会重复触发当前 handler 之前已经经过的编码节点。如果错误地使用 channel().write，可能导致某些 handler 被跨越或者执行顺序不符合预期，比如本应该在当前 handler 产生的包还要再经过一次编码。面试时能说出这个区别，会让人觉得你看过源码。
3.2 源码与设计类难题
第29题：Netty的Unsafe为什么叫Unsafe？有什么作用？
这里的 Unsafe 不是 JDK 里的 sun.misc.Unsafe，而是 Netty 内部 Channel 实现的一个接口，通常名为 Unsafe，定义在 io.netty.channel 中。它的作用是封装底层的 socket 操作，比如 connect、read、write、flush、close、shutdown 等。这些方法直接操作 JDK 原生的 Channel，不保证 API 稳定，只供 Netty 内部使用，所以命名为 Unsafe，提示外部使用者不要直接调用。面试时如果能把 Netty Unsafe 和 JDK Unsafe 区分开，说明你读过 Netty 源码目录结构。可以进一步说，DefaultChannelPipeline 的很多操作最终都会回调到 Pipeline 里的 unsafe 方法。
第30题：Netty如何解决NIO空轮询bug？
Netty 在 NioEventLoop 的 run 方法中记录 select 方法被唤醒但没有任何事件发生的次数 selectCnt。每次空转，selectCnt 会累加。当空转次数超过一个阈值，默认是 512 次，Netty 就会调用 rebuildSelector 重建一个 Selector，并把原来注册的所有 Channel 重新注册过去，然后重置计数。这个过程发生在 Linux 上，目的是规避某些 JDK 版本 epoll 空轮询导致 CPU 100% 的问题。实现细节包括：rebuildSelector 会先创建一个新的 Selector，再对旧 selector 的 keys 遍历重新注册。你可以理解为 NioEventLoop 里有一层“保护罩”，虽然这个 bug 在新版本 JDK 中少见，但 Netty 依然保留了这个机制。
第31题：谈谈你对Netty中Pipeline链表结构的理解？
ChannelPipeline 是一个 ChannelHandlerContext 组成的双向链表，每个 Context 包装一个 ChannelHandler，并且标记是否为 Inbound 或 Outbound。链路入口是 HeadContext，出口是 TailContext。每次事件到来，会从 head 或 tail 开始，按照 Inbound 或 Outbound 的方向逐个调用对应的 handler。这种设计的好处是：处理器可以动态插拔，你可以通过 pipeline.addLast 在任意位置加 handler，执行顺序由链表顺序决定。再往深一点，pipeline 的传播调用是递归的，每个 Context 都会调用 next 节点的方法，如果中间有一个 handler 没有调用 fireChannelRead，后面的 handler 就不会执行。这既是优势也是容易出坑的地方。
4. 手写题与场景设计实战
4.1 手写NIO和Netty服务端
第32题：手写一个NIO服务端，需要哪些步骤？
步骤大概分六步：第一步，创建 ServerSocketChannel，配置为非阻塞模式；第二步，绑定监听端口；第三步，创建 Selector；第四步，把 ServerSocketChannel 注册到 Selector 上，并设置监听 OP_ACCEPT；第五步，进入 while 循环，调用 select() 等待事件；第六步，拿到 selectedKeys 后遍历，如果当前 key 是 Accept 事件，就调用 accept() 获取 SocketChannel，并配置非阻塞、注册 OP_READ；如果是 Read 事件，就把数据读到 ByteBuffer，flip 后处理。两个容易踩的坑：处理完一个事件后必须从 selectedKeys 里 remove；ByteBuffer 读完要 clear 或 compact，否则下次读会出错。答题时能说出这两点，面试官会觉得你真的写过。
第33题：用Netty实现一个简单聊天室，核心代码框架是什么？
核心包括：创建两个 NioEventLoopGroup，boss 和 worker；用 ServerBootstrap 组装 server，指定 channel 类型为 NioServerSocketChannel，配置 child Option；在 childHandler 的 ChannelInitializer 里加入 LengthFieldBasedFrameDecoder 或者 DelimiterBasedFrameDecoder，再加 StringDecoder/StringEncoder，最后加自定义 ChatHandler。ChatHandler 里维护一个静态 ChannelGroup，保存所有在线连接；在 channelRead 里接收到消息后，通过 ChannelGroup.writeAndFlush 把消息广播给所有客户端。还需要重写 channelActive 和 channelInactive，管理连接加入和移出。这套代码结构几乎是聊天室的模板，重点不是背代码，而是说出每个组件在链路中的作用。
第34题：如何设计一个百万连接推送系统？
我会优先选择 Netty 做接入层。接入层的 bossGroup 线程数设小一点，workerGroup 根据 CPU 核数设置，开启 TCP_NODELAY 和 SO_KEEPALIVE。每个客户端连接对应一个 Channel，但要避免在 Channel 里保存太多业务对象，否则百万连接会吃掉大量内存。客户端的基础信息可以存 Redis，Channel 和用户 ID 的映射关系可以用 ConcurrentHashMap 维护。服务端与业务层之间用 MQ 解耦，推送数据不直接写 Channel，而是发到消息队列，由独立的推送线程池根据映射关系写到对应连接。还要注意操作系统文件描述符限制、Netty 的堆外内存参数、连接空闲心跳策略。回答时重点突出“控制内存”和“异步解耦”，而不是简单说“用 Netty”。
第35题：线上Netty内存泄漏怎么排查？
首先开启 Netty 自带的内存泄漏检测，把日志级别设到 PARANOID，通常在测试环境复现问题，然后看日志里报告的泄漏对象分配位置。如果生产环境不方便开 PARANOID，可以观察 JVM 的堆外内存和 DirectBuffer 占用，用 jcmd 或 NMT 查看是否有持续增长。定位到可疑 handler 后，重点检查 channelRead 中是否释放了 msg，如果继承的是 SimpleChannelInboundHandler，它会自动 release，如果不是，就需要手动释放。还有一类问题是自己创建的 ByteBuf 没有 release，比如通过 Unpooled.buffer 创建的临时缓冲区。排查时可以用 MAT 分析堆转储，但堆外内存不能用普通堆分析，需要结合 Netty 的监控指标。最后养成习惯：写数据的场景，ctx.writeAndFlush 会在写完自动释放，手动创建的缓存区一定要遵循“谁分配谁释放”。
写完这 35 道题，我自己在项目里最深的感受是：Netty 的坑大多不在 API 本身，而是在对线程模型和内存模型的理解上。面试官问到“EventLoop 里不能做耗时任务”这类题时，如果只背结论，很难解释清楚为什么。建议找一台 linux 机器，改用 NIO 写一个简单的 echo 服务，再对比用 Netty 写的版本，跑一下高并发压测，你会发现很多抽象概念会突然变得很具体。
