一次面试里我问候选人“NIO的水平触发和边缘触发到底有什么区别”对方答得很快“水平触发就是有数据就一直通知边缘触发就是只在有新数据的时候通知一次。”然后我接着问“那你觉得Java的Selector默认是哪种如果要把代码改成边缘触发应该注意什么”他愣了一下说“Java好像没有边缘触发吧”——能答到这个程度说明概念是懂的但离能落地还差一截。这道题是典型的“细说八股”。它看起来只要背概念实际上是在考察三件事你懂不懂操作系统的IO多路复用懂不懂Java NIO的底层实现懂不懂网络编程里的边界情况。今天我们不背概念直接把底层原理、代码实验、面试回答和生产踩坑一次性讲清楚争取下次再被问到你能答出点别人答不出来的东西。1. 面试前先看明白水平触发和边缘触发到底在说什么1.1 从一道高频面试题说起“水平触发Level-TriggeredLT和边缘触发Edge-TriggeredET有什么区别”这道题在NIO相关岗位的面试里几乎必考。但它最烦人的地方在于概念本身特别简单简单到背一遍就能说出来可一旦落到代码上很多人的理解就支离破碎了。我见过不少候选人能把定义倒背如流但接着问“为什么Java NIO默认是水平触发”“ET模式下read应该怎么写”就答不上来。原因很简单大多数人只是把结论记住了没有理解这两个词背后对应的系统状态变化。所以这篇文章不只是为了过面试更是为了让你在写网络编程时心里对“事件通知”这件事有清晰的模型。理解了通知机制你才能理解为什么有些代码会CPU飙高、为什么连接读不到数据、为什么Netty要在某些场景下特意换成ET模式。1.2 用门铃和水位报警器把概念讲透先用两个生活里的东西把直觉建立起来。水平触发你可以把它想象成一个水位报警器。只要水位超过警戒线报警器就会一直响直到水位降到警戒线以下才停。对应到网络编程里内核的socket接收缓冲区只要有未读数据epoll就会一直通知你“这个fd可以读了”你读一部分也没关系只要没读完下一次调用还会通知你。边缘触发更像是一个门铃。只有你按下按钮的那一瞬间门铃才响一次。如果你没听到就错过了除非有人再按一次。对应到网络编程里只有数据从“无”到“有”进入缓冲区的那一刻epoll才通知你一次。通知完了就不再管了哪怕缓冲区里还堆着数据没有新数据进来就再也不会通知你。为什么叫“水平”和“边缘”其实是从信号处理里借来的词。“水平”对应的是高电平区间只要电平在高位状态就是true“边缘”对应的是电平的上升沿和下降沿只有电平跳变的那一瞬才触发。理解了这两个词你就能明白LT关注的是“条件是否满足”ET关注的是“条件是否从无到有发生跳变”。2. 底层原理epoll的两种通知模型2.1 epoll_wait到底返回什么Java NIO的Selector在Linux系统上底层用的就是epoll。理解LT和ET本质上是要理解epoll的事件通知逻辑。epoll_wait这个系统调用的作用是返回一批“就绪”的文件描述符。比如某个Socket的接收缓冲区来了数据这个fd就处于“可读”状态epoll_wait就会把它返回到用户态。但在LT模式下epoll_wait的做法是只要这个fd仍然就绪每次调用都会把它返回给你。哪怕你已经读了一部分数据缓冲区里还剩一点下次再调用epoll_wait它照样把这个fd塞给你。ET模式则不同。它只在fd的就绪状态发生“从0到1”变化的那一刻返回一次。第一次有数据到达时epoll_wait返回这个fd但是如果这次你没有把数据读完缓冲区里还剩着数据在没有任何新数据进来的情况下你再调用epoll_wait这个fd不会再出现了。我用伪代码表示一下// LT模式每次都能返回同一个fd只要它仍有未读数据 while (1) { epoll_wait(epfd, events, MAX_EVENTS, -1); // 假设只有fd5有数据且你一直不读完 // 那么每次epoll_wait都会返回5 } // ET模式只有状态跳变的那一刻才返回一次 epoll_wait(epfd, events, MAX_EVENTS, -1); // 第一次数据到达返回fd5 epoll_wait(epfd, events, MAX_EVENTS, -1); // 数据没读完但没新数据不返回fd5 // 直到又有新数据到达fd5才再出现一次从设计哲学上来讲LT更安全。因为事件通知是重复的你这次没处理完下次还能接着处理不容易丢事件。但代价是频繁的epoll_wait调用会产生多余的系统开销。ET更高效一个就绪事件只通知一次减少了事件数量但它把“读干净”的责任完全交给了程序员——如果你没把数据读完后果自负。2.2 Java NIO和epoll的关系以及Netty的差异Java NIO的Selector在Linux上的实现主要藏在sun.nio.ch.EPollSelectorImpl这个类里。它内部通过EPollArrayWrapper调用epoll_create、epoll_ctl、epoll_wait这几个native方法。关键问题是JDK在向epoll注册事件时使用的events参数里没有EPOLLET这个flag。而epoll在没有EPOLLET的情况下默认就是水平触发。这段源码逻辑可以简单理解为Java的Selector并没有把设置ET的开关暴露给开发者。你注册OP_READ、OP_WRITE、OP_ACCEPT底层都会翻译成epoll事件但永远是LT模式。所以在Java原生NIO的世界里你操作的就是水平触发没有选择余地。这里顺手澄清一个常见误区非阻塞和LT/ET不是一回事。SocketChannel.configureBlocking(false)只是让读和写不阻塞线程它表示“一次read没有数据时立刻返回0而不是卡住线程”跟“事件触发策略”是两个维度。你可以非阻塞LT比如Java NIO默认就是这样也可以在Netty里非阻塞ET。如果你确实想用ET模式在JDK层面是没有办法的只能走Netty的Epoll运输层。Netty里有两个事件循环实现NioEventLoopGroup用的是JDK的Selector所以是LTEpollEventLoopGroup是Netty自己封装的原生epoll可以用ET。配置方式如下EventLoopGroup group new EpollEventLoopGroup(); ServerBootstrap bootstrap new ServerBootstrap(); bootstrap.group(group) .channel(EpollServerSocketChannel.class) .childOption(ChannelOption.EPOLL_MODE, EpollMode.EDGE_TRIGGERED);用表格对比一下维度NioEventLoopGroupEpollEventLoopGroup底层实现JDK SelectorepollNetty封装的原生epoll默认触发模式LTLT是否支持ET不支持支持配置EPOLL_MODE为EDGE_TRIGGERED使用前提跨平台任何JDK都能跑仅限Linux系统这个现实意味着你在Java原生NIO里写代码只需要考虑LT的语义不用为了ET去循环读数据。但如果你接了Netty并开了ET或者你去写C/C网络库那就要遵循ET的规则。3. 动手验证用一段Java代码看清LT的重复通知3.1 实验设计光说原理不够我建议你亲手跑一个实验把LT的“重复通知”现象直接看在眼里。实验思路很简单服务端用Selector监听连接和读事件客户端连上来之后发送5个字节的数据。服务端在处理OP_READ的时候故意每次只读1个字节然后返回。理论上如果是LT模式由于缓冲区还剩4个字节没读select会立刻再次返回这个fd又会出现在selectedKeys里直到全部读完。这个实验能直观回答一个问题水平触发所说的“一直通知”到底是怎么个“一直”法。3.2 代码与执行结果import java.io.IOException; import java.net.InetSocketAddress; import java.nio.ByteBuffer; import java.nio.channels.SelectionKey; import java.nio.channels.Selector; import java.nio.channels.ServerSocketChannel; import java.nio.channels.SocketChannel; import java.util.Iterator; public class LtDemo { public static void main(String[] args) throws Exception { Selector selector Selector.open(); ServerSocketChannel serverChannel ServerSocketChannel.open(); serverChannel.bind(new InetSocketAddress(8080)); serverChannel.configureBlocking(false); serverChannel.register(selector, SelectionKey.OP_ACCEPT); // 客户端线程连上后发送5个字节然后睡1秒 new Thread(() - { try (SocketChannel client SocketChannel.open(new InetSocketAddress(127.0.0.1, 8080))) { ByteBuffer buffer ByteBuffer.wrap(hello.getBytes()); while (buffer.hasRemaining()) { client.write(buffer); } Thread.sleep(1000); } catch (Exception ignored) {} }).start(); System.out.println(server start, waiting for connect...); while (true) { int n selector.select(); if (n 0) { continue; } IteratorSelectionKey iterator selector.selectedKeys().iterator(); while (iterator.hasNext()) { SelectionKey key iterator.next(); iterator.remove(); if (key.isAcceptable()) { ServerSocketChannel server (ServerSocketChannel) key.channel(); SocketChannel socket server.accept(); socket.configureBlocking(false); socket.register(selector, SelectionKey.OP_READ); System.out.println(accept a connection); } else if (key.isReadable()) { SocketChannel socket (SocketChannel) key.channel(); // 关键点故意只分配1字节的缓冲区 ByteBuffer buf ByteBuffer.allocate(1); int len socket.read(buf); if (len 0) { byte[] data new byte[len]; buf.flip(); buf.get(data); System.out.println(本次读到 len 字节内容: new String(data)); System.out.println(缓冲区可能还有数据继续select...); } else if (len 0) { System.out.println(客户端关闭连接); key.cancel(); socket.close(); } } } } } }运行后你会看到类似这样的输出server start, waiting for connect... accept a connection 本次读到 1 字节内容: h 缓冲区可能还有数据继续select... 本次读到 1 字节内容: e 缓冲区可能还有数据继续select... 本次读到 1 字节内容: l 缓冲区可能还有数据继续select... 本次读到 1 字节内容: l 缓冲区可能还有数据继续select... 本次读到 1 字节内容: o 缓冲区可能还有数据继续select... 客户端关闭连接客户端只发了一次数据服务端却连续读了5次。原因就是LT模式会在每次select时检查到这个fd的接收缓冲区仍然有数据就再次返回它。服务端每次只读1字节剩余的数据一直让这个fd处于“可读”状态于是就有了“一次发送多次通知”的效果。3.3 换成ET模式后会怎样如果你把同样的逻辑放到ET模式下结果会完全不同。第一次数据到达时epoll_wait会返回这个fd一次你只读了一个字节剩下的4个字节就留在内核缓冲区里了。此时你再调用epoll_wait如果客户端没有发送新的数据这个fd根本不会出现在返回列表里——剩下的4个字节只能一直躺在缓冲区里“吃灰”。更严重的是如果客户端一直不发送新数据服务端就永远没有机会去读那4个字节。直到某天客户端又发了一个字节epoll_wait再次返回这个fd你才有机会把新老数据一起读出来。这就是ET模式下漏读的核心原因。4. ET模式实操如何做到“读干净”4.1 核心代码while加read读完为止如果你真的要在ET模式下工作那就必须遵守一条铁律每次收到读事件必须循环调用read直到确认缓冲区里没有剩余数据了才能停下来。一个典型的ET读取代码如下private void handleRead(SelectionKey key) throws IOException { SocketChannel channel (SocketChannel) key.channel(); ByteBuffer buffer ByteBuffer.allocate(1024); while (true) { buffer.clear(); int read channel.read(buffer); if (read 0) { buffer.flip(); handle(buffer); // 继续循环因为缓冲区可能还有更多数据 } else if (read 0) { if (buffer.position() buffer.capacity()) { // 缓冲区满了但可能还有数据需要扩容或先处理已读部分 growBuffer(channel, buffer); } else { // 真的没有数据了结束循环 break; } } else { // read -1对端关闭 channel.close(); key.cancel(); break; } } }这段代码的核心点就是那个while(true)循环。你不能读到一份数据就break那样一定会漏。必须不停地读直到read返回0或者-1才代表本次事件处理完毕。4.2 read返回0的两种含义别再傻傻break这里有一个很容易踩的坑很多人写的ET循环看到read返回0就break结果照样漏数据。问题在于read返回0并不一定代表“没有数据了”。在非阻塞SocketChannel中read返回0有两种可能。第一种是内核缓冲区确实没有数据了这是正常情况可以结束循环。第二种是你传入的ByteBuffer已经写满了没有剩余空间导致数据读不进来read函数只能返回0。怎么区分这两种情况看buffer的position和capacity。如果position已经等于capacity说明缓冲区满了如果position还小于capacity说明缓冲区还有空间但读不到数据那才是真的没数据了。if (buffer.position() buffer.capacity()) { // 缓冲区写满可能需要扩容 // 对于Java NIO可以考虑使用更大的缓冲区或动态分配 } else { // 真的没有数据了 break; }这个细节在面试里几乎没人会主动提但生产环境中漏读问题十有八九就出在这里。如果你的ByteBuffer分配得比单次数据量还小这种场景极大概率会发生。4.3 accept也要循环处理不只是read需要循环accept在ET模式下同样需要循环。正常LT模式下如果你一次只accept一个连接TCP的全连接队列里还剩下别的连接下一次select也会因为OP_ACCEPT事件再次通知你所以不会出大问题。但ET模式下连接到达的通知也只触发一次如果你只accept了一个队列里剩下的连接就没人管了直到有新的连接进来你才有机会处理旧连接。所以ET下的accept要写成这样private void handleAccept(SelectionKey key) throws IOException { ServerSocketChannel serverChannel (ServerSocketChannel) key.channel(); while (true) { SocketChannel channel serverChannel.accept(); if (channel null) { break; } channel.configureBlocking(false); channel.register(selector, SelectionKey.OP_READ); } }另外一个跟“连接风暴”相关的经验是即使循环accept也建议限制单次循环处理的数量。比如每次循环最多处理16个连接就主动break把剩下的留到下一个事件循环再处理。这样做的目的是防止某一次循环里accept了成百上千个连接让其他已经就绪的读写通道等待过久同时也避免EventLoop线程被单个ServerSocketChannel占住太长时间。Netty内部对accept也是类似的做法不会在一个循环里无限accept。5. 面试怎么答从概念到原理的高分框架5.1 递进式回答五层讲清楚如果你只想背一个面试回答框架我推荐按下面这五层来讲。每一层都比上一层的“含金量”更高。第一层是概念层。水平触发是“只要满足条件就持续通知”边缘触发是“状态从无到有跳变时通知一次”。这一层30秒讲完就行。第二层是原理层。Linux的epoll_wait在LT模式下每次调用都会返回所有“仍然就绪”的fd在ET模式下只有fd就绪状态发生跳变才返回一次。到这里面试官会觉得你对操作系统有概念。第三层是Java层。JDK的Selector底层用的是epoll但在注册事件时没有使用EPOLLET并且没有暴露设置ET的API所以Java NIO本身就是LT。这一点很多人不知道说出来就是加分项。第四层是代码层。在ET模式下read和accept都必须用while循环读到彻底没有数据为止否则会漏事件。核心判断是read返回0时要区分是缓冲区满了还是没有数据。第五层是场景层。LT适合绝大多数业务系统简单安全ET适合代理、网关、推送这类高并发、短连接密集、对事件通知次数敏感的基础设施场景。Netty的EpollEventLoopGroup可以配置EPOLL_MODE为EDGE_TRIGGERED来启用ET。如果你能把五层都讲出来这道题基本就是满分回答。5.2 面试官可能追问的五个问题问题一为什么Java NIO不把边缘触发暴露出来核心原因是LT更安全。JDK面向的是通用场景选择LT可以让普通开发者即使读数据时漏读一部分下一次select还会通知不至于凭空丢数据。ET要求程序员必须把数据读干净编码压力大容易出错JDK选择不提供也是合理的。问题二ET模式下read循环读到什么程度才算结束读到read返回0并且确认是“真的没有数据”而不是“缓冲区已满”或者read返回-1对端关闭。源码级回答是read返回0且buffer.hasRemaining()为true时结束。问题三半包黏包和LT/ET有关系吗没有关系。半包黏包是TCP流式传输的固有现象因为TCP本身不保证消息边界。无论LT还是ET都需要在业务层通过固定长度、分隔符或LTV编码等方式解决消息边界问题。触发模式只影响“什么时候通知你”不影响“你怎么解析数据”。问题四OP_WRITE在LT模式下会不会导致忙循环会。因为LT下OP_WRITE只要发送缓冲区可写就会持续就绪而TCP的发送缓冲区绝大多数时候都是可写的。正确做法是只在需要写大量数据时才临时注册OP_WRITE写完立刻取消注册恢复成只监听OP_READ。问题五Netty开启了ET之后有什么必须注意的注意事项就是事件处理里必须把数据读干净尤其是read的循环条件要写对。Netty里的NioSocketChannel读数据是通过递归处理的不会因为一次read没读完就漏数据但如果你自己在Netty里做了额外的读操作还是要小心。6. 生产环境里踩过的坑与排查思路6.1 selectedKeys不remove导致空转这是Java NIO最常见的一个坑而且和LT的重复通知叠加在一起特别容易让人误判。Selector每次select之后会把就绪的SelectionKey放入selectedKeys集合。这个集合是复用的不会自动清空。如果你在遍历selectedKeys的时候没有调用iterator.remove()这个key就会一直留在集合里。下次select之后即使没有新事件这个旧key也还在代码就会以为通道仍然就绪继续处理一遍。如果通道真的可读LT又会让它继续就绪就形成了一个死循环CPU直接飙升。正确写法是IteratorSelectionKey iterator selector.selectedKeys().iterator(); while (iterator.hasNext()) { SelectionKey key iterator.next(); iterator.remove(); // 必须删掉否则key会残留 // ...处理业务 }这个坑的本质是“事件处理完事件状态要清掉”跟LT的“底层仍就绪时继续通知”是两个概念。别把两者搞混。6.2 OP_WRITE常驻导致CPU 100%我在一个推送网关项目里踩过一次。当时的代码逻辑是给每个连接都注册了OP_WRITE想在数据发送时感知可写状态。结果上线后CPU直接跑到100%把服务打挂了一台。原因就是我上面提到的LT模式下OP_WRITE只要发送缓冲区可写就会一直就绪。而TCP的发送缓冲区几乎不会满相当于