selectionkey 的 op_connect、op_read、op_write 须依通道状态与协议语义安全处理：op_connect 后需 finishconnect() 判连通性；op_read 防假就绪与粘包；op_write 避免忙等，写完即取消。
在 Java NIO 中，SelectionKey 的 OP_READ、OP_WRITE 和 OP_CONNECT 是三种核心就绪事件，分别对应读就绪、写就绪和连接完成。它们的处理逻辑差异较大，不能一概而论 —— 关键在于：**事件触发不等于可以无条件执行 I/O 操作，必须结合通道状态、缓冲区可用性与协议语义来安全处理。**
OP_CONNECT：只在客户端 SocketChannel 连接建立后触发
该事件仅对非阻塞的 SocketChannel 有效（服务端用 ServerSocketChannel 不关心它）。调用 connect() 后立即返回，若未完成则注册 OP_CONNECT；当连接成功（或失败）时，Selector 通知就绪。
- 必须先调用
channel.finishConnect()判断是否真正连上 —— 返回true表示成功，false表示还在进行中（罕见），抛异常表示失败（如拒绝连接） - 连接成功后，通常要取消
OP_CONNECT，再根据需要注册OP_READ（如要接收响应）或OP_WRITE（如要发请求） - 不要在
OP_CONNECT就绪时直接读/写数据 —— 此时通道尚未准备好收发应用层数据
OP_READ：表示通道有数据可读，但需防“假就绪”和粘包
OP_READ 就绪意味着内核接收缓冲区有数据（或对端关闭连接），但不保证一次能读完全部消息，也不保证单次读取不会阻塞（在非阻塞模式下，read() 最多返回当前可用字节数，可能为 0）。
- 始终检查
ByteBuffer是否有足够空间 —— 建议预先分配合适容量（如 4KB~64KB），并用flip()+get()或get(byte[])安全提取数据 - 若
read()返回 -1，说明对端已正常关闭（EOF），应关闭本端通道并取消 key - 若返回 0，可能是暂时无数据（正常），也可能是内核缓冲区刚清空但新数据未到 —— 不必惊慌，等待下次就绪即可
- 业务上需自行处理粘包/半包：按协议解析（如固定长度、分隔符、长度前缀等），未收满一条消息时，保留剩余字节到下次读取
OP_WRITE：谨慎使用，避免忙等和无限注册
OP_WRITE 的行为最易被误解：它几乎总是就绪（除非发送缓冲区满），盲目注册会导致 Selector 频繁唤醒，严重浪费 CPU。
- 通常只在写操作因
BufferOverflowException或返回值小于待写字节数（即未写完）时，才临时注册OP_WRITE - 一旦注册，后续必须在
OP_WRITE就绪时尝试继续写，并在写完后**立刻取消OP_WRITE**，否则会持续就绪 - 写之前确保
ByteBuffer处于flip()状态（limit 设为实际数据长度，position=0）；写完后调用compact()（若还有剩余未写数据）或clear()（全部写完） - 服务端一般不主动注册
OP_WRITE—— 大多数场景是收到请求后立即响应，直接写即可；只有异步大文件推送或流式响应才需精细控制写就绪
不复杂但容易忽略：每个事件的处理都依赖通道当前状态（如 isConnected()、isConnectionPending()）、缓冲区管理策略和业务协议边界。把事件当作“系统提示你可以尝试操作”，而不是“你必须立刻完成操作”的指令。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
