socketchannel 没有 shutdowninput() 方法，因其属于非阻塞 i/o 抽象，不支持半关闭读端；仅 shutdownoutput() 可用，用于发送 fin 包实现写端半关闭，读端需通过取消 op_read 注册及检测 read() 返回 -1 来处理。
SocketChannel 的 shutdownInput() 方法不能直接调用，它在 Java NIO 中**不可用**——该方法仅存在于阻塞式 Socket（即 java.net.Socket）中，而 SocketChannel 是非阻塞 I/O 抽象，不提供等效的 shutdown 方法。
为什么 SocketChannel 没有 shutdownInput()
Java NIO 的设计原则是将底层系统调用（如 shutdown(SHUT_RD)）与通道抽象解耦。SocketChannel 封装的是面向字节的双向数据流，其生命周期由 close() 统一管理；半关闭语义（如只关闭读端或写端）需通过操作系统级 socket 操作实现，而 NIO 未暴露对应接口。
常见误区：误以为 socketChannel.socket().shutdownInput() 可行——实际上，SocketChannel.socket() 返回的是一个 Socket 实例，但它在 NIO 模式下是“代理”对象，调用其 shutdownInput() 会抛出 SocketException: Socket is closed 或被忽略，且**不会影响底层 channel 的读就绪状态**。
替代方案：用 close() + OP_READ 控制读行为
要在 NIO 中模拟“半关闭读端”，核心思路是：主动停止读取、通知对端、并避免后续 read 操作。这不是靠系统 shutdown，而是靠应用层协作和事件控制：
-
主动取消读操作：调用
socketChannel.close()后，channel 不再有效；更推荐保留 channel，但不再注册OP_READ到 Selector -
发送 FIN 包（关闭写端）：调用
socketChannel.shutdownOutput()—— 注意：这是唯一受支持的 shutdown 方法，它会触发 TCP FIN，告诉对端“我不会再发数据了” -
继续接收剩余数据：即使已 shutdownOutput，只要对端还没关闭连接，仍可调用
read(ByteBuffer)接收残留数据；当对端也 shutdownOutput 后，read 会返回 -1，此时可安全关闭 channel
典型半关闭交互流程（客户端视角）
假设客户端完成发送，希望通知服务端“数据发完了”，但仍要读取服务端响应：
- 客户端调用
socketChannel.shutdownOutput()→ 发送 FIN，进入 FIN_WAIT_1 状态 - 服务端收到 FIN 后，
read()返回 0 或 -1（取决于是否还有缓存数据），得知客户端已关闭写端 - 客户端继续监听 OP_READ，直到收到服务端的 FIN（
read()返回 -1），再调用socketChannel.close() - 服务端若也要半关闭，同样调用自己的
shutdownOutput()，形成双向 FIN 交换
注意事项
不要混用阻塞/非阻塞模式：一旦 channel 设置为非阻塞（configureBlocking(false)），就不能再对其底层 Socket 调用 shutdown 方法来影响 channel 行为。
shutdownOutput() 是唯一可用的 shutdown 方法：它映射到系统 shutdown(SHUT_WR)，能正常触发 TCP 半关闭流程；而 shutdownInput() 在 SocketChannel 上无意义，也不应尝试。
Selector 不会因 shutdownInput() 触发 OP_READ 就绪：即使底层 socket 被 shutdownRead，NIO Selector 依然可能报告 OP_READ 可读（例如内核缓冲区还有未读数据），真正结束读必须依赖 read() 返回 -1。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
