在Java中的Process.destroy（）之后，stderr/stdout流会发生什么变化？

我想从Java开始的进程超时。暂停后，我想杀死这个过程。到现在为止还挺好。问题是，我想在正常执行和超时之后捕获stderr/stdout。如果我用destroy（）杀死进程会发生什么？我可以检索到目前为止产生的（部分）stderr/stdout吗？或者他们走了？在Java中的Process.destroy（）之后，stderr/stdout流会发生什么变化？

来源

2010-03-30 Lajos Nagy

你如何阅读stdout和stderr？他们怎么会有“部分”输出？ – 2010-03-30 20:49:31

当进程超时并杀死它时，会有部分结果。然而，我仍然想要捕捉它们以供以后调查。 – 2010-03-30 21:22:12

除了调用Process.exec()/waitFor()/destroy()的线程之外，您应该有一个或两个单独的线程，分别为stdout和stderr（如果合并它们，则为一个）。阅读线程将获得生成到EOF的任何数据。如果您致电Process.destroy()，EOF可能会更早发生，就这些。

来源

2010-03-31 00:29:54 EJP

是的，但是如果我只是杀了进程然后*尝试收集stderr/stdout会怎么样？这是我的问题。 – 2010-03-31 15:27:07

你会以错误的顺序做事，那就是这个样子。别。 – EJP 2010-04-01 07:56:56

在多线程，多核心环境中，什么是“订单”？因此我的问题。 – 2010-04-01 15:12:52

进程处理本质上是特定于操作系统的，我特别关注Java如何在这里处理Unix进程。

不幸的是，Process closes its streams when you call .destroy()。我不知道为什么JDK设计者认为这是正确的设计模式，但它确实使处理终止的流程变得更加复杂。

值得一提的是，InputStream小号Process认为是其中居然有一个drainInputStream()方法所做的正是我们会想什么ProcessPipeInputStream情况 - 它在一个字节的缓冲区后盾文件描述符所有其余的字节，并将它们存储读取为了我们。此方法“在进程退出时由进程收集器线程调用”，但不幸的是在进程为'.destroy()编辑时不会调用该方法。

你可以期望的话，最好是陪审团钻机自己drainInputStream()的行为，并呼吁，对于这两种stdout和stderr你打电话之前.destroy()。有些数据仍然可能会在您耗尽它们之后但在.destroy()完成之前写入到这两个数据流中，但这会得到大部分。

来源

2015-07-06 23:29:27 dimo414

在Java中的Process.destroy（）之后，stderr/stdout流会发生什么变化？

回答

相关问题