面试的时候，Java面试官把“NIO水平触发和边缘触发有什么区别”这个问题抛出来，十个人里至少有六个会脱口而出：水平触发只要缓冲区有数据就一直通知，边缘触发只在状态变化时通知一次。这个答案对吗？对，但它只能算是一句“定义”，离“理解”还差着十万八千里。真正被追问到两三轮的时候，你会发现自己对底层的事件分发逻辑、JDK的Selector实现、Netty为什么默认不用边缘触发，其实都是一笔糊涂账。
这篇文章我打算把水平触发（LT）和边缘触发（ET）这件事掰开揉碎，从事件模型讲到内核通知机制，再落到具体代码和真实选型上。不会写成教科书，而是站在“踩过坑、排查过线上问题”的视角讲经验。无论你现在是准备面试，还是在项目里纠结该用哪种触发方式，读完之后都能有一个相对完整的判断。我们直接开始。
1. 一句话回答：触发方式决定“同一份数据会通知你几次”
1.1 触发模型的本质
水平触发和边缘触发，本来不是Java的东西，它们是操作系统事件通知机制的两种工作模式。Java NIO只是通过Selector把这套机制适配成了大家能用的API，所以你要理解NIO里的这两者区别，就得先理解文件描述符的“就绪状态”。
一个socket连接对应的文件描述符，在大致上会有两个和读写密切相关的就绪条件：
- 读就绪：内核接收缓冲区里有数据可以读。
- 写就绪：内核发送缓冲区有空闲空间可以写。
水平触发（Level Triggered，LT）的意思是，只要这个条件成立，比如接收缓冲区里还有数据没读完，那每次事件循环去查询的时候，操作系统都会告诉你的程序“你可以读了”。换句话说，通知次数取决于当前状态是否满足，而不是“变化”本身。
边缘触发（Edge Triggered，ET）的意思是，只在状态发生变化的那个瞬间通知一次。比如接收缓冲区从空变成非空，这是一条“上升沿”，操作系统给你一次读事件。如果你这次没有把缓冲区里的数据读干净，没关系，操作系统不会因为剩下的数据再给你补一次通知，直到下一次缓冲区又经历“从无到有”的变化，事件才会再次出现。
我经常用一个很生活化的类比来描述：水平触发像手机上的微信公众号角标，只要你有未读消息，那个红点就一直挂着；边缘触发像系统通知栏的弹窗，消息到达那一刻弹一次，你没点掉它就没了，下一条消息进来才会再弹一次。
1.2 先记住三句话：LT一直说、ET只说一次、Java默认LT
在继续往下走之前，先把结论立住，后面所有内容都在解释这三句话：
- 水平触发：状态满足就重复通知，读取时机宽松。
- 边缘触发：状态变化才通知，必须自己把数据处理完，否则会错过。
- Java NIO标准库的Selector默认并只使用水平触发语义，这是为了保证跨平台一致性和编程安全性。
注意第三点，很多人默认Java NIO也支持边缘触发，这是个误区。标准JDK里的Selector没有对外暴露设置边缘触发的API，你在Linux上用默认的SelectorProvider，拿到的就是基于epoll实现但行为等同于水平触发的Selector。真正想用边缘触发，要么通过JNI或JNA自己封装epoll，要么在Netty这类框架里使用它提供的native epoll传输。这个我们后面用一整节展开。
2. 底层差异：从epoll的内核事件分发看LT和ET
2.1 epoll_wait到底在忙什么
在Linux上，Java NIO的Selector底层走的是epoll。epoll有三大关键操作：epoll_create、epoll_ctl、epoll_wait。其中最重要的理解点是，它内部维护了一个事件表，每次你往Selector上注册channel的OP_READ、OP_WRITE等interestOps时，底层就相当于是做了一次epoll_ctl的添加或修改操作。
当某个文件描述符上确实发生了感兴趣的事件，内核会把这个fd放进一个“就绪队列”。应用线程调用epoll_wait的时候，内核把就绪队列里有事件的文件描述符拷贝到用户态，然后返回数量。Java NIO中selector.select()阻塞返回，本质就是在做这件事。
那水平触发和边缘触发的区别，就是在这个“就绪队列”进出规则上体现出来的。
2.2 LT和ET在内核里的处理差异
我用比较通俗的方式描述内核行为，不去抠那些太底层的链表细节，但方向是对的。
在水平触发模式下，只要fd还处于可读状态，内核就会认为这个事件一直“有效”。即使epoll_wait通知过你了，你没有读，那么下一次再调用epoll_wait，它依然会把这个fd重新拿出来告诉你。内核等于是在做“状态检查”，状态没解除，通知就不停。
在边缘触发模式下，内核只会在fd状态发生跃迁时，比如从“不可读”变成“可读”，把这个fd连同事件加入就绪队列。epoll_wait被唤醒返回一次之后，这个fd就会从就绪状态中清除。接下来如果你不处理，内核不会再把它塞回去。只有后面再一次发生新的数据到达、状态重新改变，它才会再次进入就绪队列。
简洁地说：LT是“当前状态是否满足”，ET是“是否发生状态变化”。
这里有一个经典误区：有人认为ET比LT性能高，因为通知次数更少。但要注意，通知次数少带来的前提是，你的业务代码必须在一次通知里把能读的数据全部读完，而且还得读对。如果没读完，数据就滞留在内核缓冲区里，而事件却不会再来了，这会直接导致业务卡死或者数据滞后。ET不是免费的午餐，它是把“处理时机”的责任从内核移交给了应用程序。
2.3 为什么JDK选择LT而不是ET
如果你写过一段时间的Java NIO，应该能体会到，Selector的编程模型对开发者已经不算友好了：SelectionKey的迭代、selectedKeys()的清理、interestOps的修改，每一步都可能出问题。如果JDK再默认启用边缘触发，那普通开发者在“读了一次没读完”的情况下，会面临大量莫名其妙的事件丢失问题。
因此，Java标准库宁可牺牲一些极端性能，也要把行为保持在最容易理解的水平触发上。这样对于99%的中间件和业务场景，你只需要在读完后自行决定是否继续关注读事件，整个生命周期是可控的。
另外还有一个原因：Java是跨平台的。Windows上Java NIO的Selector底层是IOCP模型，macOS上是kqueue，这些系统的通知模型不是完全对应的。为了不让同一段代码在不同系统上跑出完全不同的语义，JDK统一选择水平触发，是最安全的兼容方案。
3. 代码层面的差别：一个read循环就看出真相
理论说完，一定要落到代码。笔试和面试里最常见的场景，就是让你读SocketChannel的数据。在LT和ET两种语义下，代码写法天差地别。
3.1 标准NIO的LT写法
这是用Java原生Selector处理读事件最常见的代码：
while (selector.select() > 0) { Set<SelectionKey> selectedKeys = selector.selectedKeys(); Iterator<SelectionKey> iterator = selectedKeys.iterator(); while (iterator.hasNext()) { SelectionKey key = iterator.next(); iterator.remove(); if (key.isReadable()) { SocketChannel channel = (SocketChannel) key.channel(); ByteBuffer buffer = ByteBuffer.allocate(4096); int num = channel.read(buffer); if (num == -1) { channel.close(); continue; } if (num > 0) { buffer.flip(); // 处理一个buffer的数据 handleBuffer(buffer); } // num == 0 时什么都不做也没关系 } } }这段代码是典型LT风格。它只读了一次，每次最多读满一个ByteBuffer。如果一次没把对端发来的全部数据读完，内核缓冲区里还剩数据，没关系，下一次selector.select()返回时，这个channel还会出现在selectedKeys()里，你会再次进入if (key.isReadable())，继续读。
所以LT给开发者留了很大的容错空间：你可以一次读一截，慢慢处理。代价是如果业务处理太慢，而数据又一直没读完，这个fd会一直被报告为可读，处理不当会出现忙循环。
3.2 模拟ET的“读干净”循环
如果我们要在Java里面手动模拟边缘触发语义，或者你用了某种支持ET的底层封装，那么读事件的经典写法就变了：
while (selector.select() > 0) { Set<SelectionKey> selectedKeys = selector.selectedKeys(); Iterator<SelectionKey> iterator = selectedKeys.iterator(); while (iterator.hasNext()) { SelectionKey key = iterator.next(); iterator.remove(); if (key.isReadable()) { SocketChannel channel = (SocketChannel) key.channel(); ByteBuffer buffer = ByteBuffer.allocate(4096); while (key.isValid()) { int num = channel.read(buffer); if (num > 0) { buffer.flip(); // 处理这次读到的数据 handleBuffer(buffer); buffer.clear(); } else if (num == 0) { // 当前内核缓冲区已经没有数据可读，本次事件处理结束 break; } else { // num == -1，对端关闭 channel.close(); break; } } } } }注意这里内层多了一个while(true)循环，不停地读，读到channel.read()返回0才结束。
为什么必须这样？因为边缘触发只给你一次通知。如果内核缓冲区里还有20KB数据，你只读4KB就停手，剩下16KB就“无事件可等”了，平台不会再通知你这个channel可读了。除非对端又发了新数据，否则16KB会一直躺在内核缓冲区里，业务上表现为“消息延迟”或“永远收不到”。
所以“把数据读干净”不是性能建议，而是ET模式下的生存法则。
3.3 常见错误：key不取消、读到0不跳、半包问题
在实际写ET风格代码时，我发现最常见的错误有三个。
第一个错误是把LT的思维套进ET。读了一次ByteBuffer满就break出来，然后下次等select()通知。如果你真正接了ET底层，这种代码几乎必挂。正确的做法是循环读，直到返回0。但这里也有一个隐藏风险：如果对端是长时间持续发大流量的连接，channel.read()可能一直返回大于0，从而导致单个连接霸占整个线程，其他连接饿死。所以一些优化实现会为这个循环设置次数上限或字节数上限，超过阈值后主动退出，并重新注册读事件，利用“新数据到达”作为下一次触发条件。
第二个错误是读到了0但没有区分“非阻塞模式”和“暂时无数据”。NIO里非阻塞SocketChannel.read()返回0是正常情况，表示当前内核缓冲区为空。如果写成“读到0就重新注册读事件”也不是不行，但在真ET下，重新注册不会立刻触发，必须在循环外等待下一次状态变化。更粗暴的错误是把返回0当成异常处理，直接把连接关了，那线上就会出现大量“连接被重置”的报错。
第三个错误是把LT/ET和TCP的“半包问题”混为一谈。TCP是流式协议，一个完整的业务消息可能分多个TCP包到达，也可能一次到达多个消息。LT和ET只决定“告诉你有数据可读几次”，并不解决“应用层应该读多少数据算一个完整消息”的问题。不过LT有个很迷惑人的地方：如果你在一个LT事件里只读了一部分数据，业务逻辑没处理好，下次select()还会通知你，问题不容易立刻暴露。而ET模式下，你只有一次机会，没读完就真的错过了。所以ET对应用层协议解析的严谨度要求更高。
4. 实战选型：别被网上“ET性能高”带偏
4.1 LT能应付90%的场景
我在实际项目中看到太多人为了“性能”去追求边缘触发，结果系统没快多少，反而引入一堆难排查的事件丢失问题。其实水平触发已经能覆盖绝大多数业务场景。
举个例子，你做一个RPC框架，连接数几千，每个连接上的消息量并不夸张，用LT写起来干净利落。数据来了就读，没读完下次再读，逻辑非常直观。因为selector.select()返回的每个可读channel，本质上都是“有数据等待处理”，你不需要担心漏事件。对于大多数企业级应用，性能瓶颈往往在业务处理、反序列化、数据库访问上，根本不在“多一次epoll_wait返回”上。
在Netty中，默认的NIO传输事件循环也是水平触发风格。Netty的核心处理在ChannelPipeline里，通过自动读取机制和DefaultMaxMessagesRecvByteBufAllocator控制每次读多少，如果用LT，读不干净后面还有机会，容错性很强。这也是为什么大多数人不需要碰ET的原因。
4.2 真要用ET，有哪些路子
标准JDK没有给ET开入口，但如果你确实想用，有几条实际路线。
第一，自己用JNI封装Linux epoll，手动设置EPOLLET标志。这条路适合对Linux系统编程非常熟悉的人，要自己管理事件循环和内存，工作量和维护成本都很高。
第二，用Netty的native epoll transport。Netty在Linux下提供了EpollServerSocketChannel、EpollSocketChannel等类，内部通过JNI直接调用epoll。它暴露了一个配置项EpollChannelOption.EPOLL_MODE，可以设置为EpollMode.EDGE_TRIGGERED来开启边缘触发模式。代码大致是这样：
EventLoopGroup group = new EpollEventLoopGroup(); try { ServerBootstrap bootstrap = new ServerBootstrap(); bootstrap.group(group) .channel(EpollServerSocketChannel.class) .childOption(EpollChannelOption.EPOLL_MODE, EpollMode.EDGE_TRIGGERED) .childHandler(new ChannelInitializer<SocketChannel>() { @Override protected void initChannel(SocketChannel ch) { ch.pipeline().addLast(new MyHandler()); } }); ChannelFuture future = bootstrap.bind(8080).sync(); future.channel().closeFuture().sync(); } finally { group.shutdownGracefully(); }但要注意，即使Netty提供了这个开关，也并不意味着你可以无脑开启。Netty内部对ET模式做了很多额外的约束和适配，比如读循环后要判断是否需要继续注册读事件，管道中的autoRead机制也要配合。在生产环境开启前，必须压测确认读事件处理没有遗漏。
第三，使用基于JNA或JNI的第三方轻量级封装，但这类库生态比较小，遇到问题基本只能自己扛。
4.3 高并发网关案例的取舍复盘
我之前维护过一个长连接网关，峰值连接数十几万，单连接流量不算大，但整体事件量很大。当时团队讨论要不要切ET，理由是减少epoll_wait的重复唤醒次数。
后来我们做了一轮对比压测发现，在同样读取逻辑、同样业务处理的前提下，LT和ET的事件吞吐差距并没有想象中大。因为LT虽然会重复返回仍有数据的fd，但只要你read()读得足够快，下一次select()返回时很多fd的缓冲区已经空了，并不会造成大量无效唤醒。反而是ET模式下为了保证“读干净”，需要频繁调用read()直到返回0，这里增加的系统调用次数和忙循环，抵消了一部分事件通知的收益。
最终我们没有切换到ET，而是通过优化业务线程池、减少ByteBuffer分配次数、采用直接内存等方式把瓶颈转移。那次实践让我形成了一个判断：触发模式选型，考虑顺序应该是“正确性 > 可维护性 > 性能”。除非你的模型对“事件重复通知次数”极其敏感，并且有足够能力处理后续的复杂性，否则LT都是更稳健的默认选择。
5. 关于LT/ET的高频追问与临场答法
5.1 select/poll/epoll和LT/ET是什么关系
这个问题很多人会搞混。select和poll本身只支持水平触发，因为它们本身是“轮询检查当前状态”的模型，每次调用都会把所有fd过一遍，看哪些满足可读可写条件，只要有数据就会返回。
epoll则同时支持水平触发和边缘触发，通过EPOLLET标志位可以修改事件注册模式。但它也默认采用水平触发，也就是不传EPOLLET时和select/poll的通知语义类似，只不过底层实现从轮询所有fd变成了事件驱动。
Java NIO的Selector内部虽然在Linux上用了epoll，但它把用户可见的行为限制成了水平触发。所以你回答“NIO是水平触发还是边缘触发”时，要说清楚：现在你直接用的JDK NIO，是水平触发；边缘触发需要更底层的epoll API或第三方native实现，而不是标准库里区分粒度上的开关键。
5.2 OP_ACCEPT和OP_WRITE也有触发方式吗
有，同样适用。
OP_ACCEPT是针对监听SocketChannel的读事件，新连接到达时触发。在水平触发语义下，只要accept队列里还有未处理的连接，select()每次都会返回这个key；在边缘触发语义下，新连接到达那一次通知你，你必须循环accept()直到返回null或抛异常，否则队列里剩下的连接可能要等下一波新连接到来才会再被处理。这个细节在同类面试题里也经常被追问。
OP_WRITE更特殊。只要socket发送缓冲区有空间，写事件就是“就绪”的。在水平触发下，如果你向Selector注册了OP_WRITE但一直没写数据，那么select()会一直返回这个key，造成CPU忙循环。经典做法是：需要写数据时才注册OP_WRITE，写完数据立刻取消注册。边缘触发下写事件是“从不可写变成可写”时通知，虽然可以减少重复唤醒，但同样需要你在一次事件里尽量把能写的数据写完，否则剩余数据也得等下一次状态变化。
5.3 ET模式下数据丢了吗？丢的是事件不是数据
这是又一高频追问点。很多面试者会下意识说“ET会丢数据”。严格说，数据没有丢，它们还在内核接收缓冲区里等着你读，只不过操作系统不再主动通知你了。除非你关闭连接或者覆盖缓冲区，否则数据一直存在于内核中。
那为什么业务上表现是“丢消息”？因为你的应用层逻辑是在“收到读事件”之后才去触发读取和解析。如果这个触发源一直没有到来，应用层感知不到积压数据，自然就无法继续处理。所以你回答的时候要说得精密一些：ET模式有可能丢失的是“通知事件”，不是TCP数据本身；但如果应用程序没有额外机制去兜底，事件丢失最终会表现为数据长期不被处理。
5.4 面试遇到这道题，建议怎么答
如果面试时要现场讲清楚这道题，我建议按这个顺序来，既不乱又有深度：
先一句话给定义：LT是条件触发、状态满足就通知；ET是状态变化触发、只通知一次。然后补一句关键：Java标准NIO默认是LT，ET要靠底层epoll或框架扩展。接着讲代码差异：LT只要正常读取就行，ET必须while循环把数据读到返回0，否则下次事件不来。最后拔高一点，举一个实际选型经验：高并发环境下不一定非要ET，LT配合合理线程模型足够稳定，ET更适合极低延迟、事件处理完全可控的底层场景。
这样答，面试官基本能确认你不是只会背概念，而是真能把这层机制串起来。
我个人这些年下来的体会是，水平触发和边缘触发的区别并不难理解，难的永远是“知道底层机制之后，设计自己的读写策略”。如果你用的是Java原生Selector，就先老老实实按LT写；如果你真有一天要压榨到ET，请一定先想清楚一件事情：谁保证你每个事件都能把数据读干净？谁负责处理那个“读不干净”的兜底？把这个想明白，比记住任何定义都重要。
