pipedreader与pipedwriter实现线程间格式化文本传输需显式绑定、约定数据边界、协同关闭流并合理设置缓冲区。推荐用构造器直接关联，写端close()触发读端eof，用bufferedreader.readlines()按行解析，避免仅flush()。
用 PipedReader 和 PipedWriter 实现两个工作线程间传输格式化文本，关键在于建立可靠连接、控制字符流边界、避免阻塞死锁，并适配业务所需的文本结构（如 JSON 片段、日志行、键值对等）。它不是通用消息队列，而是轻量、同步、内存级的线程直连通道。
连接必须显式且顺序合理
不能靠“运气”让读写线程同时启动。PipedReader 和 PipedWriter 必须在任一线程开始 I/O 前完成绑定，推荐使用构造器直接关联：
-
优先用
new PipedWriter(pr)或new PipedReader(pw)，避免后续调用connect()带来的竞态风险 - 创建顺序建议：先 new PipedReader，再用它构造 PipedWriter；或反过来——但必须确保 reader 实例已存在，再传给 writer 构造器
- 若用无参构造器，务必在
start()前调用connect()，否则首次write()或read()会抛IOException: Pipe not connected
格式化文本需自行定义分隔或长度约定
PipedReader 不识别换行、JSON 对象边界或字段名。它只按字符数组或单字符读取。所以“格式化文本”的结构必须由你约定并实现：
- 写线程每次
write()推送一个完整逻辑单元，例如：pw.write("{\"id\":123,\"msg\":\"ok\"}\n")，用\n作行分隔 - 读线程用
BufferedReader(pr)包装，调用readLine()自动按行切分，比手动read()单字符高效且不易错位 - 若需严格长度控制（如固定 256 字符报文），写端用
write(char[] cbuf, int off, int len)精确写出，读端也按块读取，避免缓冲区残留干扰下一条
线程生命周期与流关闭要协同
字符管道是双向状态敏感的：一端关闭会影响另一端行为。不恰当的 close() 可能导致读线程提前退出或阻塞在 read() 上：
- 写线程完成全部输出后，应调用
pw.close()—— 这会触发读端read()返回 -1（EOF），BufferedReader.readLine()返回null - 读线程检测到
null或 -1 后，应主动退出循环，再关闭自身资源（如br.close()） - 不要在写线程中仅
flush()就结束；flush()只清空本地缓冲，不通知读端“数据发完了” - 异常时（如对方线程已终止），
read()可能抛IOException，需捕获并退出，防止无限重试
缓冲区大小与性能可按需调整
默认 1024 字符缓冲区适合多数日志或配置同步场景。但如果文本平均长度远超此值，频繁阻塞写入会拖慢协作节奏：
- 构造 PipedReader 时指定更大容量：
new PipedReader(pw, 4096) - 注意：增大缓冲区不解决逻辑错误，只缓解因吞吐不匹配导致的写阻塞
- 若文本极短（如单个状态码 “READY”、“ERROR”），默认大小完全足够，无需调整
