处理op_write事件的关键是避免无限触发，需按需注册、用完即撤，写完立即取消关注位，配合附件管理分片写入，并设置超时断连兜底。
处理 OP_WRITE 事件的关键不是“避免触发”，而是“避免无限触发”——因为写事件一旦注册，只要内核写缓冲区有空闲，就会持续就绪。不加控制地让它一直活跃，会导致 Selector 空转、CPU 占用飙升，甚至掩盖真实业务逻辑。
写事件必须按需注册，用完即撤
OP_WRITE 不是常驻事件，它只在“需要主动发起写操作但当前不可写”时才应注册。比如：
- 应用层有数据待发送，但调用 channel.write() 返回 0（缓冲区满），此时注册 OP_WRITE 等待可写
- 连接刚建立（OP_CONNECT 完成后），或读到请求需立即响应，但首次 write 可能失败，也适合先注册写事件再择机发送
- 切忌在 accept 或 read 后无条件注册 OP_WRITE —— 这会让所有连接一进来就“永远可写”，引发忙等
写操作完成后必须取消 OP_WRITE 注册
每次进入 key.isWritable() 分支，完成实际写入后，要立刻清理写关注位，否则下一轮 select() 仍会返回该 key，形成死循环：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 使用 key.interestOps(key.interestOps() & ~SelectionKey.OP_WRITE) 清除写事件
- 若还有剩余数据未写完（buffer.hasRemaining() 为 true），可保持 OP_WRITE 注册；否则必须取消
- 不要依赖“下次没数据就不进来了”——只要注册着，内核就认为你关心可写状态，就会反复通知
配合状态机与附件管理写过程
单次 write() 很少能发完全部数据（尤其大 Buffer 或网络慢时），需把待发内容绑定到 SelectionKey 上，靠状态驱动分片写入：
- 调用 key.attach(buffer) 把 ByteBuffer 存起来，避免局部变量丢失
- 在 isWritable 分支中取出 buffer，调用 channel.write(buffer)
- 检查 buffer.hasRemaining()：仍有数据 → 下次继续写；已清空 → 取消 OP_WRITE 并清理 attachment
- 若 write() 返回 0，说明缓冲区又满了，无需额外操作，OP_WRITE 仍有效，下次自然再触发
防止假性“一直可写”的兜底措施
即使逻辑正确，极端网络抖动或对端接收极慢，也可能导致写事件长期就绪却进展缓慢。这时需引入超时和主动断连机制：
- 在 key.attach() 时同时记录写开始时间戳，每次 isWritable 处理前校验是否超时（如 >5 秒）
- 超时则调用 key.cancel() + channel.close() 主动释放资源
- 避免让一个卡住的连接拖垮整个 Selector 线程
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
