后來吃個(gè)飯都放棄了,居然又找到答案,要沒看到它,那真以為里面有鬼了。
大概原因是,調(diào)用Runtime.getRuntime().exec后,如果不及時(shí)捕捉進(jìn)程的輸出,會導(dǎo)致JAVA掛住,看似被調(diào)用進(jìn)程沒退出。所以,解決辦法是,啟動進(jìn)程后,再啟動兩個(gè)JAVA線程及時(shí)的把被調(diào)用進(jìn)程的輸出截獲。
一下子,整個(gè)世界清爽多了。。。多謝這么仁兄,下面轉(zhuǎn)一下:
轉(zhuǎn)自:http://pudding.sharera.com/blog/BlogTopic/31232.htm
碰到一個(gè)項(xiàng)目需要從Java中運(yùn)行Perl程序,這個(gè)Perl程序調(diào)用客戶的Web service,每次發(fā)送一個(gè)請求,接受一個(gè)響應(yīng)。Java程序中包含多個(gè)請求,需要多次調(diào)用Perl程序,并且接受和解析響應(yīng)(這個(gè)爛設(shè)計(jì)可不是我干 的,我實(shí)在不明白強(qiáng)大的Java Web Service為什么要弄成這樣,不過客戶是老大)。使用Java Runtime的exec()方法,發(fā)現(xiàn)運(yùn)行一段時(shí)間后,進(jìn)程就被掛起了(之前的響應(yīng)完全正確)。于是分析原因,發(fā)現(xiàn)我在運(yùn)行exec()方法后,立刻執(zhí) 行了Process的waitFor()方法,這里出了問題。在網(wǎng)上找到一篇文章講述這個(gè)問題:
地址:http://brian.pontarelli.com/2005/11/11/java-runtime-exec-can-hang/
Java Runtime exec can hang
November 11, 2005 on 4:40 pm | In Java |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.
- 永遠(yuǎn)要在調(diào)用waitFor()方法之前讀取數(shù)據(jù)流
- 永遠(yuǎn)要先從標(biāo)準(zhǔn)錯(cuò)誤流中讀取,然后再讀取標(biāo)準(zhǔn)輸出流
正好解決了我心中的疑問,非常感謝!
我們的程序一開始就是exec完了接著waitFor(),但bat文件執(zhí)行不完整:
Process proc = Runtime.getRuntime().exec(cmd);
proc.waitFor();
后面的build中在waitFor()之前讀取了數(shù)據(jù)流,bat文件就可以完整執(zhí)行了:
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