PipedStream 默认延迟高，因依赖1024字节缓冲区、同步锁及无超时机制；降低延迟需设小缓冲（如1字节）、批量写入、非阻塞读探测并避免字符流混用。
Java 的 PipedInputStream/PipedOutputStream 和 PipedReader/PipedWriter 能在线程间建立直接字节/字符流通道，但**默认不是低延迟方案**——它依赖内部缓冲区（默认 1024 字节）和同步锁，写入未填满缓冲区时读线程会阻塞等待，实际延迟常在毫秒级甚至更高。真要压低延迟，得绕过默认行为、控制缓冲与线程调度。
为什么 PipedStream 默认延迟高
根本原因在于 JDK 实现：
- PipedInputStream 内部用 protected byte[] buffer 缓存数据，read() 必须等到 buffer 中有数据才返回，否则阻塞；
- write() 每次调用都触发对 buffer 的加锁、拷贝、唤醒读线程三步操作，锁竞争明显；
- 管道连接后，读写线程必须严格配对启动，若写线程先 close，读线程会抛 IOException: Write end dead；
- 没有超时机制，read() 卡住就卡死，无法做背压或快速失败。
降低延迟的实操改造点
不改类库，只靠参数和用法调整就能收效明显：
- 显式设置小缓冲区：
new PipedInputStream(1)或new PipedInputStream(8)，让写入几乎立即触发读线程唤醒（注意：不能为 0，会抛IllegalArgumentException）； - 避免单字节 write：虽然缓冲设小了，但频繁调用
out.write(int b)仍开销大，改用out.write(byte[] b, int off, int len)批量写，哪怕每次只传 1–4 字节； - 读端用非阻塞探测：不用
read()死等，改用available() > 0判断后再read()，配合短时Thread.sleep(1)循环（适用于对 CPU 敏感度可控的场景）； - 务必在写线程结束前调用
out.close()，否则读线程永远卡在read()；读线程检测到read()返回 -1 后也应立刻退出，避免空转。
PipedReader/PipedWriter 的字符编码陷阱
用字符流比字节流更易出错，尤其涉及编码：
-
PipedReader不接受编码参数，它按平台默认编码解码 —— 若写端用out.write("你好".toCharArray())，读端拿到的是正确字符；但若写端用out.write("你好".getBytes(StandardCharsets.UTF_8))，就会乱码，因为PipedWriter期望的是 char，不是 byte； - 字符流内部仍有缓冲，默认也是 1024 char，同样需用
new PipedReader(reader, 1)控制大小； - 不要混用：一个管道不能一边用
PipedWriter写，另一边用PipedInputStream读 —— 类型不匹配直接抛IOException。
真正低延迟场景（如高频行情推送、实时音视频帧中转），PipedStream 只适合原型验证或线程数极少的简单流水线。一旦并发写入者 ≥2，或要求亚毫秒级响应，就得换 BlockingQueue（配 LinkedTransferQueue）或 Phaser + 共享内存环形缓冲区 —— 管道流的同步模型决定了它扛不住争抢。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
