OutputStreamWriter与PipedInputStream配合易因读写线程未协调而死锁，主因是PipedInputStream默认1024字节缓冲区满后写阻塞，而读端若等待换行符或未启动则无法消费，形成双向等待；需确保读线程先启、写后flush、正确换行，并避免跨管道持锁。
OutputStreamWriter 与 PipedInputStream 配合使用时，若未正确协调读写线程，极易发生死锁。核心问题在于：PipedInputStream 的内部缓冲区有限（默认1024字节），一旦写端持续写入而读端未及时消费，写操作会阻塞；而如果读端又在等待写端写入更多数据才继续读，就形成双向等待——典型死锁。
理解管道流的阻塞机制
PipedInputStream 和 PipedOutputStream 是配对使用的同步通信通道。OutputStreamWriter 包装 PipedOutputStream 后，调用 write() 或 flush() 时，实际是向 PipedOutputStream 写入字节。当其内部缓冲区满（或遇到 flush），写线程会挂起，直到读端从 PipedInputStream 中取走数据腾出空间。若读端此时正等待某条件（如完整消息头、换行符）才开始 read()，而写端又卡在 flush 上，双方都无法推进。
常见触发场景与排查线索
- 未启动读线程就调用 flush()：写端完成 write() 后立即 flush()，但读端尚未 start() 或还没进入 read() 循环，写线程永久阻塞
- 读端使用 BufferedReader.readLine() 但写端未输出换行符：readLine() 会一直等 '\n' 或 '\r\n'，而写端可能只 write("data") 未加换行，也未 flush，导致双方僵持
- 写端在 synchronized 块中持有其他锁的同时写管道：若读端也在同一把锁内尝试 read()，就构成锁顺序死锁 + 管道阻塞双重问题
- JStack 线程状态显示为 BLOCKED 或 WAITING 且堆栈含 java.io.PipedInputStream.receive / PipedOutputStream.write：这是最直接的死锁证据
安全使用的关键实践
- 确保读写线程并发启动：先 new Thread(readerRunnable).start()，再执行 writer 逻辑，避免写端抢先阻塞
- 写端主动控制换行与刷新：使用 OutputStreamWriter.write(String) 后，显式调用 flush()；若依赖行读取，务必 write("\n") 或 write(System.lineSeparator())
- 设置超时或使用非阻塞替代方案：PipedInputStream 不支持 setSoTimeout，可改用 java.nio.channels.Pipe（需适配 ByteBuffer）或内存队列（如 BlockingQueue<byte[]>）解耦
- 避免跨管道持有外部锁：读写操作尽量在独立同步块内完成，不与业务锁嵌套
快速验证是否死锁
运行程序后，用 jstack <pid> 抓取线程快照，重点查找：
- 线程 B 堆栈含 "at java.io.PipedOutputStream.write" 且同样卡住
- 两个线程互相不持有对方所需资源，但均无法继续
此时基本可确认是管道缓冲区满导致的活锁/死锁。修复方向始终围绕“让读端及时消费”和“写端不过度积压”展开。
立即学习“Java免费学习笔记（深入）”；
