pipedinputstream与pipedoutputstream必须配对使用且在不同线程中操作，否则会阻塞或抛出异常；写端异常关闭后读端read()返回-1但不自动释放资源；不支持nio异步io；高并发或多消费者场景应改用blockingqueue。
Java PipedInputStream 和 PipedOutputStream 必须配对使用，不能单独初始化
这两个类不是普通流，它们是“成对绑定”的通信通道。你不能只 new 一个 PipedInputStream 就去 read，它会一直阻塞，直到有线程往配对的 PipedOutputStream 写数据；反过来也一样——PipedOutputStream 写之前没 connect 上，会直接抛 IOException: Pipe not connected。
常见错误现象：
– 启动写线程后立刻关闭写流，读线程卡在 read() 不返回
– 忘记调用 connect()，或 connect 顺序反了（比如先 read 后 write）
– 在单线程里先后调用 write 和 read，结果死锁（因为 write 会等 buffer 满或 read 消费，而 read 又在等 write 入数据）
实操建议：
– 一定要在不同线程中分别处理读/写，且写线程需在 connect 后才开始写
– 推荐用构造函数直接 connect：new PipedInputStream(pipedOutputStream)，比手动 connect() 更安全
– buffer 默认大小是 1024 字节，如果写入大量小包（如逐字节写），性能很差，可传参指定更大 buffer（如 new PipedInputStream(pipedOutputStream, 8192)）
写线程异常退出时，PipedInputStream.read() 会立即返回 -1，但不会自动 close 管道
这是最容易被忽略的边界行为：一旦写端线程因异常终止、或主动 close 了 PipedOutputStream，读端的 read() 下次调用就会返回 -1（表示流结束），但 PipedInputStream 自身仍处于 open 状态，不 throw 异常也不释放资源。
立即学习“Java免费学习笔记（深入）”；
使用场景：
– 日志采集器把日志行通过管道传给解析线程
– 数据预处理模块将中间结果推给下游计算模块
实操建议：
– 读循环必须检查 read() 返回值是否为 -1，并主动 break + close 读流
– 不要依赖 try-with-resources 自动关，因为写端崩溃时读端根本收不到通知
– 如果需要区分“正常结束”和“写端异常中断”，可在写端 close 前先写一个特殊标记 byte（如 -2），读端收到就按异常路径处理
Java 8+ 中 PipedStream 不支持 NIO 的 AsynchronousFileChannel 或 Selector
管道流本质是基于线程间 wait/notify 实现的同步阻塞机制，底层没有文件描述符或 socket channel 支持，所以无法注册到 Selector，也不能用于异步 IO 场景。
性能 / 兼容性影响：
– 想用 Netty 或 NIO 处理管道数据？不行，必须包装成 InputStream 后用同步方式读取
– Android 上某些低版本 Runtime 对 PipedStream 的 buffer 锁实现有 bug，偶发死锁（尤其在子线程频繁创建/销毁管道时）
– Java 9+ 加入了 java.io.PipedWriter/PipedReader（字符流版），但同样不支持非阻塞
实操建议：
– 高吞吐、低延迟场景慎用，优先考虑 BlockingQueue 或 Exchanger
– 若必须用管道且要兼容 Android，避免在主线程创建/连接管道流
– 不要用 Files.newInputStream(Paths.get("/dev/stdin")) 这类方式试图“模拟”管道——那根本不是 Java 管道流
替代方案：什么时候该放弃 PipedStream 改用 BlockingQueue<byte></byte>
当你发现要反复 new 管道、或者需要多个消费者读同一份数据、或者想控制背压策略时，PipedStream 就成了累赘。它的设计目标很窄：一对一、短生命周期、线程间字节流接力。
参数差异：
– PipedStream 的 buffer 是固定大小、不可扩容的环形数组
– BlockingQueue 可选 ArrayBlockingQueue（有界）、LinkedBlockingQueue（可配置容量）、甚至无界 ConcurrentLinkedQueue（但不阻塞）
实操建议：
– 单生产者-单消费者：用 ArrayBlockingQueue<byte></byte>，预分配 buffer 数组，避免 GC 压力
– 需要广播或多路复用：改用 CopyOnWriteArrayList + 手动 notify，别硬套管道
– 已有代码用了管道但出现频繁 full/empty 等待：直接替换为带超时的 poll(100, TimeUnit.MILLISECONDS)，更容易调试和监控
