如何在 Java 中使用 PipedInputStream 在两个线程之间建立直接的字节通讯管道-java教程-PHP中文网

pipedinputstream单独new会抛“pipe not connected”异常，因其必须与pipedoutputstream配对且在read前完成connect；推荐构造时直接传入对方实例（如new pipedinputstream(pos)）或显式connect()，且连接须在任一端i/o操作前完成。

如何在 java 中使用 pipedinputstream 在两个线程之间建立直接的字节通讯管道

为什么 `PipedInputStream` 单独 new 出来会抛 `IOException: Pipe not connected`

因为 PipedInputStream 必须和 PipedOutputStream 配对使用，且连接动作必须在读线程启动前完成。常见错误是：先启动读线程，再调用 connect()，此时读端已尝试 read，管道尚未建立，直接报错。

正确做法是：在构造时就配对，或显式调用 connect()，且确保写端（PipedOutputStream）的 write() 发生在读端 read() 之后（但不必等读端阻塞）。

推荐方式一：构造时传入对方实例 —— new PipedInputStream(pipedOutputStream)
推荐方式二：先创建两端，再调用 pipedInputStream.connect(pipedOutputStream)，且该调用必须在任一端开始 I/O 前完成
避免在不同线程中交叉执行 connect + start —— 容易因时序导致连接失败

如何让读线程不卡死、写线程不丢数据

PipedInputStream 内部有 1KB 的默认缓冲区（可通过构造函数指定），读线程调用 read() 时若无数据会阻塞，直到写端写入或流关闭；写端若缓冲区满（比如读端迟迟不消费），write() 也会阻塞。这是设计使然，不是 bug。

关键点在于：两个线程需协同生命周期，且写端必须在结束时调用 close()，否则读端永远等不到 -1（EOF）。

Java Maven Code Review

审查Java Maven项目（ZIP压缩包或GitLab仓库URL），检查代码规范、命名、模块边界、可维护性问题以及重复代码。

下载

读线程应循环 read() 直到返回 -1，再退出 —— 不要仅靠 try-catch IOException 判定结束
写线程写完后务必调用 pipedOutputStream.close()，这会向读端发送 EOF
不要在写线程中只调用 flush() —— 它不触发 EOF，读线程不会停止
若需中途终止，可对任一端调用 close()，另一端的阻塞 I/O 会立即抛 IOException

实际代码中怎么组织线程与管道对象

最简可控结构是：主线程创建管道对，然后分别启动读/写线程，并把对应流作为参数传入。不要让线程自己 new 管道，避免作用域和生命周期混乱。

PipedOutputStream pos = new PipedOutputStream();
PipedInputStream pis = new PipedInputStream(pos); // 构造即连接

Thread writer = new Thread(() -> {
    try {
        pos.write("hello".getBytes());
        pos.close(); // 关键：发 EOF
    } catch (IOException e) {
        e.printStackTrace();
    }
});

Thread reader = new Thread(() -> {
    try {
        int b;
        while ((b = pis.read()) != -1) {
            System.out.print((char) b);
        }
        System.out.println(" — read done");
    } catch (IOException e) {
        // 可能是 writer 异常关闭，或管道被中断
    }
});

writer.start();
reader.start();

注意：PipedInputStream 和 PipedOutputStream 必须属于同一个管道逻辑对，不能混用其他流
不要把 PipedInputStream 包装成 BufferedInputStream 后再 read —— 缓冲行为可能掩盖 EOF 或改变阻塞时机
如果需要字符通信，建议上层用 InputStreamReader，但底层仍走字节管道

替代方案比 `PipedInputStream` 更合适吗

纯内存字节管道适合「一个写、一个读」的简单线程协作场景。但它不支持多写或多读，也没有超时控制、非阻塞 I/O 或背压反馈机制。

一旦需求变复杂，比如：需要多个消费者、写端要感知读端积压、或要集成进 Netty/Reactor 等异步框架，PipedInputStream 就力不从心了。

多线程安全写？不行 —— PipedOutputStream 非线程安全，多写线程需自行加锁
想设读超时？不行 —— 没有 setReadTimeout()，只能靠中断线程或用 java.nio.channels.Pipe（但那是通道，不是流）
替代选择：BlockingQueue<byte></byte> 更灵活，或 Exchanger<byte></byte> 用于双向一次交换
现代项目中，更倾向用 CompletableFuture + 回调，或消息队列（如 ConcurrentLinkedQueue + 自定义协议）代替原始管道