为什么没有更多的Java代码使用PipedInputStream / PipedOutputStream？ [英] Why doesn't more Java code use PipedInputStream / PipedOutputStream?

问题描述

最近我已经发现了这个成语，我想知道是否有一些我错过的东西。我从来没有看过它。几乎所有与野外合作的Java代码都倾向于将数据压缩成字符串或缓冲区，而不是像这样的例子（例如使用HttpClient和XML API）：

  final LSOutput输出; // XML东西初始化
 final LSSerializer serializer; 
最终文件doc; 
 // ... 
 PostMethod post; // HttpClient post request 
 final PipedOutputStream source = new PipedOutputStream（）; 
 PipedInputStream sink = new PipedInputStream（source）; 
 // ... 
 executor.execute（new Runnable（）{
 public void run（）{
 output.setByteStream（source）; 
 serializer.write （doc，output）; 
 try {
 source.close（）; 
} catch（IOException e）{
 throw new RuntimeException（e）; 
} 
}}）; 
 
 post.setRequestEntity（new InputStreamRequestEntity（sink））; 
 int status = httpClient.executeMethod（post）; 
  

该代码使用Unix管道样式技术来防止XML数据的多个副本保存在内存中。它使用HTTP Post OutputStream和DOM Load / Save API将XML文档序列化为HTTP请求的内容。据我所知，只需少量额外的代码（只有Runnable，PipedInputStream和PipedOutputStream的几行）才能最大限度地减少内存的使用。

所以，怎么了用这个成语？如果这个成语没有什么问题，为什么还没有看到它？

编辑：澄清，PipedInputStream和PipedOutputStream替换了显示的逐个缓冲区副本并且它们还允许您同时处理传入的数据，并写出已处理的数据。他们不使用OS管道。

解决方案

从 Javadocs ：

通常，一个线程从PipedInputStream对象读取数据，并且某些其他线程将数据写入相应的PipedOutputStream。不建议尝试从单个线程使用这两个对象，因为它可能会阻塞线程。

这可能部分解释为什么它是不太常用。

我认为另外一个原因是很多开发人员不了解其目的/好处。

I've "discovered" this idiom recently, and I am wondering if there is something I am missing. I've never seen it used. Nearly all Java code I've worked with "in the wild" favors slurping data into a string or buffer, rather than something like this example (using HttpClient and XML APIs for example):

    final LSOutput output; // XML stuff initialized elsewhere
    final LSSerializer serializer;
    final Document doc;
    // ...
    PostMethod post; // HttpClient post request
    final PipedOutputStream source = new PipedOutputStream();
    PipedInputStream sink = new PipedInputStream(source);
    // ...
    executor.execute(new Runnable() {
            public void run() {
                output.setByteStream(source);
                serializer.write(doc, output);
                try {
                    source.close();
                } catch (IOException e) {
                    throw new RuntimeException(e);
                }
            }});

    post.setRequestEntity(new InputStreamRequestEntity(sink));
    int status = httpClient.executeMethod(post);

That code uses a Unix-piping style technique to prevent multiple copies of the XML data being kept in memory. It uses the HTTP Post OutputStream and the DOM Load/Save API to serialize an XML Document as the content of the HTTP request. As far as I can tell it minimizes the use of memory with very little extra code (just the few lines for Runnable, PipedInputStream, and PipedOutputStream).

So, what's wrong with this idiom? If there's nothing wrong with this idiom, why haven't I seen it?

EDIT: to clarify, PipedInputStream and PipedOutputStream replace the boilerplate buffer-by-buffer copy that shows up everywhere, and they also allow you to process incoming data concurrently with writing out the processed data. They don't use OS pipes.

解决方案

From the Javadocs:

Typically, data is read from a PipedInputStream object by one thread and data is written to the corresponding PipedOutputStream by some other thread. Attempting to use both objects from a single thread is not recommended, as it may deadlock the thread.

This may partially explain why it is not more commonly used.

I'd assume another reason is that many developers do not understand its purpose / benefit.

这篇关于为什么没有更多的Java代码使用PipedInputStream / PipedOutputStream？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！