Java 多线程调用runtime.exe 进程挂起_JAVA_编程开发_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 编程开发 > JAVA > Java 多线程调用runtime.exe 进程挂起

Java 多线程调用runtime.exe 进程挂起

 2014/11/25 15:59:43  feifangongzi  程序员俱乐部  我要评论(0)
  • 摘要:最近用ffmpeg监听文件夹批量转化视频文件,在调用runtime.exec()多个ffmpeg.exe进程启动但是挂起,java程序关闭后这些进程开始工作。网上找了文章解释如下:JavaRuntimeexeccanhangThenextversionofSavantisgoingtofocusheavilyonthestand-aloneruntimeandsupportfordialectsandplugins
  • 标签:多线程 Java 线程
最近用ffmpeg 监听文件夹批量转化视频文件,在调用 runtime.exec()多个ffmpeg.exe进程启动但是挂起,java程序关闭后这些进程开始工作。网上找了文章解释如下:


Java Runtime exec can hang

The next version of Savant is going to focus heavily on the stand-alone runtime and support for dialects and plugins. Supporting all that is largely handled by using a simple executor framework I wrote around Java 1.4 and lower’s Runtime.exec method. A few things to keep in mind when using this:

Always read from the streams prior to calling waitFor. Otherwise you could end up waiting forever on Windows and other OS platforms whose I/O buffers can’t store enough from standard out and standard error to ensure the program has finished. These platforms will pause the execution of whatever is running until something reads the buffered content from standard out and standard error. I would imagine all platforms suffer from this, but some platforms have larger buffers than others. Needless to say, always read from the streams first.
Always read from standard error first. I ran across a bug where some OS platforms will always open standard out, but never close it. What this means is that if you read from standard out first and the process only writes to standard error, you’ll hang forever waiting to read. If you read from standard error first, you’ll always be okay on these platforms because the OS seems to shutdown standard error. I think however, that the best way to handle all cases is to check both standard error and standard out for readiness and only read from them if they have something to offer. The downside I could see here is that error isn’t ready, but eventually will be.
可以看出:
永远要在调用waitFor()方法之前读取数据流
永远要先从标准错误流中读取,然后再读取标准输出流

于是将waitFor()方法放在读取数据流后调用,目前没有发现什么问题。


我们的程序一开始就是exec完了接着waitFor(),但bat文件执行不完整:

class="java">Process proc = Runtime.getRuntime().exec(cmd);
proc.waitFor();


后面的build中在waitFor()之前读取了数据流,bat文件就可以完整执行了:

Process proc = Runtime.getRuntime().exec(cmd);
     StreamGobbler errorGobbler = new StreamGobbler(proc.getErrorStream(), "Error");            
                 StreamGobbler outputGobbler = new StreamGobbler(proc.getInputStream(), "Output");
                 errorGobbler.start();
                 outputGobbler.start();

     proc.waitFor();

class StreamGobbler extends Thread {
 InputStream is;

 String type;

 StreamGobbler(InputStream is, String type) {
  this.is = is;
  this.type = type;
 }

 public void run() {
  try {
   InputStreamReader isr = new InputStreamReader(is);
   BufferedReader br = new BufferedReader(isr);
   String line = null;
   while ((line = br.readLine()) != null) {
    if (type.equals("Error"))
     LogManager.logError(line);
    else
     LogManager.logDebug(line);
   }
  } catch (IOException ioe) {
   ioe.printStackTrace();
  }
 }
}

TestPrint.bat:

echo P1=%1  >D:"2.1.2env"2.1.2home"CompuSet"output"TestPrint.log
echo P2=%2 >>D:"2.1.2env"2.1.2home"CompuSet"output"TestPrint.log
echo P3=%3 >>D:"2.1.2env"2.1.2home"CompuSet"output"TestPrint.log
echo P4=%4 >>D:"2.1.2env"2.1.2home"CompuSet"output"TestPrint.log
echo P5=%5 >>D:"2.1.2env"2.1.2home"CompuSet"output"TestPrint.log
echo P6=%6 >>D:"2.1.2env"2.1.2home"CompuSet"output"TestPrint.log

Bad_TestPrint.log:

P1=C:"xPression"CompuSet"output"MartyTestOut1.afp 
P2=Literal1
P3="Rick Skinner"
P4=Parameter3

Good_TestPrint.log

P1=C:"xPression"CompuSet"output"MartyTestOut1.afp 
P2=Literal1
P3="Rick Skinner"
P4=Parameter3
P5=Parameter4
P6=Parameter5
发表评论
用户名: 匿名