PipedOutputStream不能单独工作，因其必须与PipedInputStream成对绑定，否则写入时抛出“Pipe not connected”异常；它不持缓冲区，数据直推输入流，且连接须在写操作前完成。
为什么 PipedOutputStream 不能单独工作
PipedOutputStream 必须与 PipedInputStream 成对绑定，否则写入时会立即阻塞或抛出 IOException: Pipe not connected。它本身不持有缓冲区，数据直接推给配对的输入流——这意味着你不能“先写再连”，必须在写线程启动前完成连接。
常见错误是分别 new 两个管道流后直接 start 线程，却忘了调用 connect() 或依赖构造函数自动连接。推荐始终显式调用 connect()，避免 JDK 版本差异导致的隐式行为不一致：
PipedInputStream pis = new PipedInputStream();
PipedOutputStream pos = new PipedOutputStream();
try {
pos.connect(pis); // 必须调用，不要依赖 PipedOutputStream(PIpedInputStream) 构造器
} catch (IOException e) {
throw new RuntimeException(e);
}
写入线程卡住？检查读取端是否及时消费
PipedOutputStream 的 write 操作是同步且阻塞的：当配对的 PipedInputStream 内部缓冲区（默认 1024 字节）满时，write() 会一直等待，直到读线程调用 read() 腾出空间。这不是 bug，而是设计使然——它天然实现背压（backpressure）。
容易踩的坑：
立即学习“Java免费学习笔记（深入）”；
- 读线程未启动，或启动晚于写线程，导致写入方永久阻塞
- 读线程只调用一次
read()就退出，缓冲区无法释放 - 读取时使用了带超时的
read(byte[], int, int)但未处理返回值为 -1（流关闭）或 0（无数据），误判为异常
安全做法是让读线程循环调用 read()，并在捕获 IOException（如管道关闭）或返回 -1 时退出：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
new Thread(() -> {
byte[] buf = new byte[1024];
try {
int n;
while ((n = pis.read(buf)) != -1) {
// 处理 buf[0..n)
}
} catch (IOException e) {
// 管道已断开或出错，正常结束
}
}).start();
关闭顺序很重要：先关输出端，再关输入端
调用 pos.close() 会向管道发送 EOF 信号，触发 pis.read() 返回 -1；若反过来先关 pis，再写入 pos，会立即抛出 IOException: Write end dead。
正确关闭逻辑：
- 写线程完成数据写入后，调用
pos.close() - 读线程在
read()返回 -1 后自然退出，随后可安全调用pis.close()（虽然通常非必需） - 不要在读线程中主动调用
pis.close()来“中断”写线程——这会导致写入方异常，且无法保证数据完整性
注意：PipedInputStream 的 available() 返回的是当前缓冲区字节数，不是“是否还有数据”，不能用来轮询判断 EOF。
替代方案比 PipedOutputStream 更可靠吗
纯内存管道在高吞吐或大数据量场景下容易成为瓶颈：缓冲区小、无超时控制、异常传播不直观。实际项目中更推荐以下替代：
- 小数据 + 控制流：
BlockingQueue<byte></byte>或ArrayBlockingQueue，支持容量限制和 offer/poll 超时 - 需要流式处理大文件：
ByteArrayInputStream/ByteArrayOutputStream配合ExecutorService提交任务，避免线程耦合 - 跨 JVM 或需持久化：
Files.newByteChannel()+ 临时文件，或内存映射文件MappedByteBuffer
PipedOutputStream 的价值仅限于极简 demo、教学演示或遗留代码兼容。真实异步传输务必考虑中断、超时、重试和资源泄漏——这些它都不提供。
最常被忽略的一点：JDK 文档明确指出，管道流不是为多写一读或多读一写设计的。哪怕只是两个写线程同时往同一个 PipedOutputStream 写，也会因竞争导致数据交错或 IOException，这点几乎没人测试就上线。
