java nio pipe本质是线程间单向数据通道，仅提供严格绑定的sinkchannel（只写）和sourcechannel（只读），数据流向固定为sink→source，不支持双向、多端或动态路由；其设计强调零拷贝、无锁与低延迟，适用于生产者-消费者模型。
Java NIO 中的 Pipe 本质是线程间单向数据通道，它**不支持两个 SinkChannel 或两个 SourceChannel 之间通信**——Pipe 只提供一对严格绑定、职责分明的通道：一个 SinkChannel（只写） 和一个 SourceChannel（只读）。所谓“两个 SinkChannel 之间的数据传输”在 Pipe 机制中并不存在，也不符合其设计契约。
Pipe 的结构与角色不可互换
Pipe.open() 创建的是原子性的一对通道，二者共享底层内核管道资源：
- SinkChannel 是唯一的数据入口：仅接受 write() 调用，数据写入后立即对 SourceChannel 可见；它不能读，也不能被另一个 SinkChannel “对接”
- SourceChannel 是唯一的数据出口：仅响应 read() 调用，不能写入，也无法从另一个 SourceChannel 接收数据
- 两端通道不具备对等性，没有“变量流”概念——数据流向固定为 Sink → Source，不可反向或分叉
实际使用中常见的“单向传输变量流”理解误区
用户有时误将“多个写线程共用一个 SinkChannel”或“多个读线程轮询一个 SourceChannel”理解为“多 Sink/多 Source”，但需明确：
- SinkChannel 本身是线程安全的，多个写线程可并发调用 write()，但数据仍按写入顺序进入同一管道，最终由唯一 SourceChannel 串行读出
- SourceChannel 不支持多路复用读取；若需分发数据给多个消费者，必须由应用层在 read() 后自行复制或广播 ByteBuffer 内容，Pipe 本身不提供该能力
- 所谓“变量流”若指动态切换数据源或目标，Pipe 无法做到——它的连接关系在创建时即固化，生命周期由两端 close() 共同约束
替代方案：当需要更灵活的数据流向
若业务场景要求多生产者、多消费者、双向通信或动态路由，Pipe 就不再适用，应转向更高级的抽象：
- 使用 ConcurrentLinkedQueue + volatile 标志位 实现无锁队列通信（轻量、可控）
- 借助 Netty 的 ChannelHandler + EventLoop 构建可编排的消息流
- 采用 Disruptor 等高性能 RingBuffer 框架支持多生产者-多消费者模型
- 跨进程或复杂拓扑下，选用 消息队列（如 Kafka、RabbitMQ） 替代本地管道
正确使用 Pipe 的关键实践
确保单向性被真正尊重，才能发挥其零拷贝、无锁、低延迟的优势：
- 写线程只操作 SinkChannel，且始终检查 write() 返回值；返回 0 时需等待或让出 CPU，不可忙等
- 读线程应通过 Selector 监听 SourceChannel 的 OP_READ，避免空轮询；read() 返回 -1 表示管道已关闭
- 两端关闭需协调：通常由写端完成所有写入后 close(SinkChannel)，读端检测到 read() = -1 即 clean shutdown
- ByteBuffer 必须在 write 前 flip()，在 read 后 flip()→处理→clear()，否则数据错位或丢失
