piped流使用需确保连接先行、读写分离、缓冲区管理得当：构造时绑定最安全；单线程读写必致死锁；1kb固定缓冲区易引发永久阻塞；写端关闭后读端将抛“write end dead”。
连接必须在读写前完成
两个流对象必须在任何 I/O 操作开始前建立连接，否则调用 write() 或 read() 会立即抛出 Pipe not connected 异常。构造时绑定是最安全的方式：new PipedOutputStream(pis)，避免手动调用 connect() 引入竞态。若手动连接，需确保它发生在主线程中、且仅执行一次——重复调用会触发 Already connected；更危险的是在读线程已启动后再 connect，容易导致写端阻塞而读端永远等不到数据。
绝对不要在单一线程里同时读和写
这是最典型的死锁根源。PipedInputStream 的 read() 会等待缓冲区有数据，PipedOutputStream 的 write() 会等待缓冲区有空位；当两者运行在同一线程时，read() 卡住 → 无法腾出空间 → write() 卡住 → 无法写入新数据 → read() 继续卡住，形成闭环阻塞。JDK 文档明确警告：“Attempting to use both objects from a single thread is not recommended, as it may deadlock the thread”。生产环境出现此类问题，Thread Dump 中通常可见两个方法在 synchronized 块内相互等待。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
1KB 固定缓冲区带来的隐性阻塞风险
内部缓冲区大小固定为 1024 字节，不可配置。一旦写入数据量超过该阈值且读线程未及时消费，write() 就会无限期阻塞在 awaitSpace() 上，不响应中断、无超时机制。如果读线程因异常退出、逻辑遗漏或尚未启动，写线程将永久挂起。这不是暂时性延迟，而是彻底的线程停滞。相比之下，BlockingQueue 提供 offer(e, timeout, unit) 和 poll(timeout, unit)，能主动控制等待边界，更适合现代并发编程。
流生命周期管理不当引发“Write end dead”
写端关闭（close()）后，读端再调用 read() 会直接抛出 IOException: Write end dead，这不是可重试错误，而是管道终结信号。常见诱因包括：写线程提前终止、未调用 flush() 就 close 导致缓冲区残留数据丢失、读线程未按规范判断返回值（-1 表示正常流结束，异常才需处理）。安全读循环应写成：
int len;
while ((len = pis.read(buffer)) != -1) {
process(buffer, 0, len);
}
而非捕获 IOException 后尝试“重连”或忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
