我最近已经“发现”了这个成语,我想知道是否有我失踪的东西。 我从来没有看过它。 几乎所有与“野外”合作的Java代码都倾向于将数据压缩成字符串或缓冲区,而不是像这样的例子(例如使用HttpClient和XML API):
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);该代码使用Unix管道样式技术来防止保存在内存中的XML数据的多个副本。 它使用HTTP Post OutputStream和DOM Load / Save API将XML文档序列化为HTTP请求的内容。 据我所知,只需少量额外的代码(Runnable,PipedInputStream和PipedOutputStream的几行)就可以最大限度地减少内存的使用。
那么这个成语怎么了? 如果这个成语没有错,为什么我没看到它?
编辑:澄清,PipedInputStream和PipedOutputStream替换显示在任何地方的样板缓冲区副本,并且它们还允许您同时处理传入的数据,并写出已处理的数据。 他们不使用OS管道。
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 output stream 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.
最满意答案
从Javadocs :
通常,一个线程从PipedInputStream对象读取数据,并且某些其他线程将数据写入相应的PipedOutputStream。 不建议尝试从单个线程使用这两个对象,因为它可能会使线程死锁。
这可能部分解释为什么它不是更常用。
我会假设另一个原因是许多开发人员不了解其目的/效益。
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.
更多推荐
发布评论