Pipe并非默认高性能方案，因其8 KiB不可配环形缓冲区导致阻塞写入/读取、无背压机制、小包写入系统调用开销大；须设为非阻塞并手动处理返回值、ByteBuffer状态及消息边界。
Pipe 是 JVM 内线程间单向通信的轻量级选择，但不是万能的“高性能”方案——它适合低延迟、中等吞吐、生产者-消费者解耦场景；高吞吐或需背压控制时，BlockingQueue 或 TransferQueue 往往更稳。
为什么 Pipe 默认不“高性能”？缓冲区大小和阻塞行为是关键
Pipe 的内部环形缓冲区大小由 JVM 实现决定（OpenJDK 中默认约 8 KiB），不可配置；Pipe.open() 没有重载方法接受 buffer size 参数（部分资料误传）。这意味着：
- 写入方调用
sink.write()时，若缓冲区已满，会**完全阻塞当前线程**（除非设为非阻塞） - 读取方调用
source.read()时，若缓冲区为空，也**完全阻塞** - 没有内置背压信号，生产者过快会导致写线程卡住，可能拖垮整个线程池
- 缓冲区小 + 频繁小包写入 → 大量系统调用开销，反而比
ArrayBlockingQueue更慢
必须 configureBlocking(false) 才能避免线程卡死
默认阻塞模式下，一个慢消费者会让生产者线程永久挂起。真实场景中应主动设为非阻塞，并配合轮询或 Selector 使用：
-
pipe.sink().configureBlocking(false)：write() 立即返回，返回值为实际写入字节数（可能为 0） -
pipe.source().configureBlocking(false)：read() 立即返回，返回值为实际读取字节数（可能为 0 或 -1） - 不能直接 while(true) { sink.write(...) }，必须检查返回值并做重试/让出（如
Thread.yield()）或交由Selector统一调度 - 注意：Pipe 的
SourceChannel和SinkChannel**不支持注册到 Selector**（会抛UnsupportedOperationException），所以“用 Selector 管理 Pipe”是常见误解
ByteBuffer 使用必须 flip/clear，否则数据永远读不到
这是最常踩的坑：写入前没 flip()，读取后没 clear() 或 compact()，导致 read() 总是返回 0 或乱码：
- 写入流程：
buffer.put(...)→buffer.flip()→sink.write(buffer)→buffer.clear()（或compact()若有残留） - 读取流程：
source.read(buffer)→buffer.flip()→ 解码/处理 →buffer.clear() - 别用
allocateDirect()盲目优化：小数据下堆内 buffer（allocate()）更快；direct buffer 仅在大块数据且反复复用时有意义 - 避免每次 new ByteBuffer：复用
ThreadLocal<bytebuffer></bytebuffer>或对象池，减少 GC 压力
真正实用的写法：带状态检查的非阻塞循环 + 显式 yield
下面这段是生产环境可用的最小可靠模式（无异常处理简化）：
// 生产者线程
ByteBuffer buf = ByteBuffer.allocate(1024);
while (running) {
String data = produce();
buf.clear();
buf.put(data.getBytes(StandardCharsets.UTF_8));
buf.flip();
int written = sink.write(buf);
if (written == 0) {
Thread.yield(); // 缓冲区满，让出 CPU，避免忙等
continue;
}
}
// 消费者线程
ByteBuffer buf = ByteBuffer.allocate(1024);
while (running) {
buf.clear();
int read = source.read(buf);
if (read > 0) {
buf.flip();
String s = StandardCharsets.UTF_8.decode(buf).toString();
consume(s);
} else if (read == 0) {
Thread.yield(); // 无数据，让出
}
}
注意：这里没用 Selector，因为 Pipe 不支持；也没用锁或 volatile 控制 running，那是业务层该管的事。Pipe 本身线程安全，但业务逻辑的启停协调不在它的职责内。
真正容易被忽略的是：Pipe 不提供消息边界。你 write("a") write("bb")，read() 可能一次拿到 "abb"，也可能分两次。如果需要消息帧（如 JSON 对象、协议头），必须自己加分隔符或长度前缀——Pipe 只管字节流，不管语义。
