pipedinputstream/pipedoutputstream能实现零拷贝、无锁的线程间字节通信，但仅在严格满足“单生产者-单消费者+先启读线程+合理缓冲区”时才稳定低延迟；一旦写端提前关闭、缓冲区过小或并发写入，延迟会飙升甚至死锁。
直接说结论：PipedInputStream/PipedOutputStream 能实现零拷贝、无锁的线程间字节通信，但仅在严格满足“单生产者-单消费者+先启读线程+合理缓冲区”时才稳定低延迟；一旦写端提前关闭、缓冲区过小或并发写入，延迟会飙升甚至死锁。
为什么 PipedStream 在特定场景下延迟更低
它不走堆内存复制路径，数据在环形缓冲区（buffer）里直接流转，写线程调用 write() 时，字节拷贝进缓冲区就返回（除非满），读线程调用 read() 时直接从缓冲区取——中间没有序列化、队列封装、CAS重试等开销。
但这个优势有硬前提：
- 必须是单向、一对一的线程配对；多生产者会触发
IOException: Write end dead - 默认缓冲区只有
1024字节，频繁写入小包（如逐字节write(65)）会导致大量阻塞唤醒，实测比LinkedBlockingQueue慢 3 倍以上 - 底层用
wait()/notifyAll()同步，JVM 线程调度抖动会直接反映为读写延迟毛刺
connect() 必须在任何 I/O 之前完成，且不能靠 try-catch 补救
常见错误是先 new 两个流，再在不同线程里分别调用 connect() —— 这存在竞态：若写线程先执行 write()，而读线程还没来得及 connect()，就会立即抛 IOException: Pipe not connected。
正确做法只有一种：
- 用构造函数绑定：
new PipedInputStream(pos)或new PipedOutputStream(pis)，而不是分开 new 再connect() - 读线程必须在写线程启动前完成初始化并进入
read()阻塞态（哪怕只是调一次read()），否则写端首次write()可能因缓冲区空而卡住 - 绝对不要在单线程里先后调
write()和read()，这会死锁：写等读消费，读等写入，谁都动不了
读端如何区分正常结束和写端崩溃
PipedInputStream.read() 在写端关闭后会立刻返回 -1，但它不会自动抛异常，也不会释放内部资源。这意味着：
- 你不能依赖
try-with-resources—— 写端异常退出时，读端根本收不到通知，close()不会被触发 - 必须手动检查返回值：
if (b == -1) break;，然后显式in.close() - 若需区分“写端主动 close”和“写端 crash”，可在 close 前写一个特殊结束标记（如
pos.write(-2)），读端收到就按异常路径处理 - 缓冲区满时写端阻塞，但读端没数据时也阻塞 —— 两者无超时机制，无法用
Thread.interrupt()中断阻塞中的read()或write()
实际部署时最容易被忽略的三点
一是缓冲区大小必须匹配数据特征：日志行平均长度 200 字节？设 new PipedInputStream(pos, 4096)；传感器每毫秒上报 16 字节？至少 8192，否则写线程频繁停顿。
二是 JVM GC 压力会影响 wait/notify 的响应时间 —— 尤其 CMS 或 ZGC 的并发阶段，read() 可能被挂起几十毫秒，这在实时采集场景不可接受。
三是它完全不支持 NIO —— 无法注册到 Selector，不能和 Netty、Vert.x 等异步框架混用；想做背压控制？只能自己加 AtomicBoolean + 循环检查，不如直接换 BlockingQueue。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
