調用Process.waitfor導致的進程掛起問題及解決
問題背景
如果要在Java中調用shell腳本時，可以使用Runtime.exec或ProcessBuilder.start。它們都會返回一個Process對象，通過這個Process可以對獲取腳本執(zhí)行的輸出，然后在Java中進行相應處理。
例如，下面的代碼：
try
{
Process process = Runtime.getRuntime().exec(cmd);
process.waitFor();
//do something ...
}
catch (Exception e)
{
e.printStackTrace();
}
通常，安全編碼規(guī)范中都會指出：使用Process.waitfor的時候，可能導致進程阻塞，甚至死鎖。 那么這句應該怎么理解呢？用個實際的例子說明下。
問題描述
使用Java代碼調用shell腳本，執(zhí)行后會發(fā)現(xiàn)Java進程和Shell進程都會掛起，無法結束。
Java代碼 processtest.java
try
{
Process process = Runtime.getRuntime().exec(cmd);
System.out.println("start run cmd=" + cmd);
process.waitFor();
System.out.println("finish run cmd=" + cmd);
}
catch (Exception e)
{
e.printStackTrace();
}
被調用的Shell腳本doecho.sh
#!/bin/bash
for((i=0; ;i++))
do
echo -n "0123456789"
echo $i >> count.log
done
掛起原因
- 主進程中調用Runtime.exec會創(chuàng)建一個子進程，用于執(zhí)行shell腳本。子進程創(chuàng)建后會和主進程分別獨立運行。
- 因為主進程需要等待腳本執(zhí)行完成，然后對腳本返回值或輸出進行處理，所以這里主進程調用Process.waitfor等待子進程完成。
- 通過shell腳本可以看出：子進程執(zhí)行過程就是不斷的打印信息。主進程中可以通過Process.getInputStream和Process.getErrorStream獲取并處理。
- 這時候子進程不斷向主進程發(fā)生數(shù)據(jù)，而主進程調用Process.waitfor后已掛起。當前子進程和主進程之間的緩沖區(qū)塞滿后，子進程不能繼續(xù)寫數(shù)據(jù)，然后也會掛起。
- 這樣子進程等待主進程讀取數(shù)據(jù)，主進程等待子進程結束，兩個進程相互等待，最終導致死鎖。
解決方法
基于上述分析，只要主進程在waitfor之前，能不斷處理緩沖區(qū)中的數(shù)據(jù)就可以。因為，我們可以再waitfor之前，單獨啟兩個額外的線程，分別用于處理InputStream和ErrorStream就可以。實例代碼如下：
try
{
final Process process = Runtime.getRuntime().exec(cmd);
System.out.println("start run cmd=" + cmd);
//處理InputStream的線程
new Thread()
{
@Override
public void run()
{
BufferedReader in = new BufferedReader(new InputStreamReader(process.getInputStream()));
String line = null;
try
{
while((line = in.readLine()) != null)
{
System.out.println("output: " + line);
}
}
catch (IOException e)
{
e.printStackTrace();
}
finally
{
try
{
in.close();
}
catch (IOException e)
{
e.printStackTrace();
}
}
}
}.start();
new Thread()
{
@Override
public void run()
{
BufferedReader err = new BufferedReader(new InputStreamReader(process.getErrorStream()));
String line = null;
try
{
while((line = err.readLine()) != null)
{
System.out.println("err: " + line);
}
}
catch (IOException e)
{
e.printStackTrace();
}
finally
{
try
{
err.close();
}
catch (IOException e)
{
e.printStackTrace();
}
}
}
}.start();
process.waitFor();
System.out.println("finish run cmd=" + cmd);
}
catch (Exception e)
{
e.printStackTrace();
}
JDK上的說明
By default, the created subprocess does not have its own terminal or console.
All its standard I/O (i.e. stdin, stdout, stderr) operations will be redirected to the parent process, where they can be accessed via the streams obtained using the methods getOutputStream(), getInputStream(), and getErrorStream().
The parent process uses these streams to feed input to and get output from the subprocess.
Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the subprocess may cause the subprocess to block, or even deadlock.
從JDK的說明中可以看出兩點：
- 如果系統(tǒng)中標準輸入輸出流使用的bufffer大小有限，所有讀寫時可能會出現(xiàn)阻塞或死鎖。------這點上面已分析
- 子進程的標準I/O已經被重定向到了父進程。父進程可以通過對應的接口獲取到子進程的I/O。------I/O是如何重定向的？
背后的故事
要回答上面的問題可以從系統(tǒng)的層面嘗試分析。
首先通過ps命令可以看到，在linux上多出了兩個進程：一個Java進程、一個shell進程，且shell是java的子進程。
然后，可以看到shell進程的狀態(tài)顯示為pipe_w。我剛開始以為pipe_w表示pipe_write。進一步查看/proc/pid/wchan發(fā)現(xiàn)pipe_w其實表示為pipe_wait。通常/proc/pid/wchan表示一個內存地址或進程正在執(zhí)行的方法名稱。因此，這似乎表明該進程在操作pipe時發(fā)生了等待，從而被掛起。我們知道pipe是IPC的一種，通常用于父子進程之間通信。這樣我們可以猜測：可能是父子進程之間通過pipe通信的時候出現(xiàn)了阻塞。
另外，觀察父子進程的fd信息，即/proc/pid/fd。可以看到子進程的0/1/2（即：stdin/stdout/stderr）分別被重定向到了三個pipe文件；父親進程中對應的也有對著三個pipe文件的引用。
綜上所述，這個過程應該是這樣的：子進程不斷向pipe中寫數(shù)據(jù)，而父進程一直不讀取pipe中的數(shù)據(jù)，導致pipe被塞滿，子進程無法繼續(xù)寫入，所以出現(xiàn)pipe_wait的狀態(tài)。那么pipe到底有多大呢？
測試pipe的大小
因為我已經在doecho.sh的腳步中記錄了打印了字符數(shù)，查看count.log就可以知道子進程最終發(fā)送了多少數(shù)據(jù)。在子進程掛起了，count.log的數(shù)據(jù)一致保持在6543不變。故，當前子進程向pipe中寫入6543*10=65430bytes時，出現(xiàn)進程掛起。65536-65430=106byte即距離64K差了106bytes。
換另外的測試方式，每次寫入1k，記錄總共可以寫入多少。進程代碼如test_pipe_size.sh所示。測試結果為64K。兩次結果相差了106byte，那個這個pipe到底多大？
Linux上pipe分析
最直接的方式就是看源碼。Pipe的實現(xiàn)代碼主要在linux/fs/pipe.c中，我們主要看pipe_wait方法。
pipe_read(struct kiocb *iocb, struct iov_iter *to)
{
size_t total_len = iov_iter_count(to);
struct file *filp = iocb->ki_filp;
struct pipe_inode_info *pipe = filp->private_data;
int do_wakeup;
ssize_t ret;
/* Null read succeeds. */
if (unlikely(total_len == 0))
return 0;
do_wakeup = 0;
ret = 0;
__pipe_lock(pipe);
for (;;) {
int bufs = pipe->nrbufs;
if (bufs) {
int curbuf = pipe->curbuf;
struct pipe_buffer *buf = pipe->bufs + curbuf;
const struct pipe_buf_operations *ops = buf->ops;
size_t chars = buf->len;
size_t written;
int error;
if (chars > total_len)
chars = total_len;
error = ops->confirm(pipe, buf);
if (error) {
if (!ret)
ret = error;
break;
}
written = copy_page_to_iter(buf->page, buf->offset, chars, to);
if (unlikely(written < chars)) {
if (!ret)
ret = -EFAULT;
break;
}
ret += chars;
buf->offset += chars;
buf->len -= chars;
/* Was it a packet buffer? Clean up and exit */
if (buf->flags & PIPE_BUF_FLAG_PACKET) {
total_len = chars;
buf->len = 0;
}
if (!buf->len) {
buf->ops = NULL;
ops->release(pipe, buf);
curbuf = (curbuf + 1) & (pipe->buffers - 1);
pipe->curbuf = curbuf;
pipe->nrbufs = --bufs;
do_wakeup = 1;
}
total_len -= chars;
if (!total_len)
break; /* common path: read succeeded */
}
if (bufs) /* More to do? */
continue;
if (!pipe->writers)
break;
if (!pipe->waiting_writers) {
/* syscall merging: Usually we must not sleep
* if O_NONBLOCK is set, or if we got some data.
* But if a writer sleeps in kernel space, then
* we can wait for that data without violating POSIX.
*/
if (ret)
break;
if (filp->f_flags & O_NONBLOCK) {
ret = -EAGAIN;
break;
}
}
if (signal_pending(current)) {
if (!ret)
ret = -ERESTARTSYS;
break;
}
if (do_wakeup) {
wake_up_interruptible_sync_poll(&pipe->wait, POLLOUT | POLLWRNORM);
kill_fasync(&pipe->fasync_writers, SIGIO, POLL_OUT);
}
pipe_wait(pipe);
}
__pipe_unlock(pipe);
/* Signal writers asynchronously that there is more room. */
if (do_wakeup) {
wake_up_interruptible_sync_poll(&pipe->wait, POLLOUT | POLLWRNORM);
kill_fasync(&pipe->fasync_writers, SIGIO, POLL_OUT);
}
if (ret > 0)
file_accessed(filp);
return ret;
}
可以看到Pipe被組織成環(huán)狀結構，即一個循環(huán)鏈表。鏈表中的元素為struct pipe_buffer的結構，每個pipe_buffer對于一個page。鏈表中共有16個元素，即pipe buffer的總大小為16*page。如果page大小為4K，那么pipe buffer的總大小應該為16*4K=64K。
以上為個人經驗，希望能給大家一個參考，也希望大家多多支持腳本之家。
相關文章
由于要將“哈密頓回路問題(TSP)”的求解中間結果表示出來，查了一下使用程序畫多邊形圖形?，F(xiàn)在在總結一下，這個圖是“由給定節(jié)點首尾相連的”閉合多邊形2014-02-02
MyBatis 是一款優(yōu)秀的持久層框架，它支持自定義 SQL、存儲過程以及高級映射。這篇文章主要介紹了SpringBoot MyBatis快速入門-簡單例子,需要的朋友可以參考下2021-07-07
SpringBoot實現(xiàn)OneDrive文件上傳的詳細步驟
這篇文章主要介紹了SpringBoot實現(xiàn)OneDrive文件上傳的詳細步驟,文中通過代碼示例和圖文講解的非常詳細,對大家實現(xiàn)OneDrive文件上傳有一定的幫助,需要的朋友可以參考下2024-02-02
詳解Spring Boot 使用Spring security 集成CAS
本篇文章主要介紹了詳解Spring Boot 使用Spring security 集成CAS，具有一定的參考價值，感興趣的小伙伴們可以參考一下2017-05-05
這篇文章主要介紹了SpringBoot屬性注入的兩種方法，幫助大家更好的理解和使用springboot框架，感興趣的朋友可以了解下2020-11-11
這篇文章主要介紹了logback過濾部分日志輸出的操作，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2021-08-08
ReentrantReadWriteLock不能鎖升級的原因總結
今天給大家?guī)淼氖顷P于Java并發(fā)的相關知識,文章圍繞著為什么ReentrantReadWriteLock不能鎖升級展開,文中有非常詳細的介紹及代碼示例,需要的朋友可以參考下2021-06-06
本文主要介紹了SpringBoot?@Profile的使用，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2023-06-06
這篇文章主要為大家詳細介紹了Java實現(xiàn)發(fā)紅包功能，文中示例代碼介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們可以參考一下2020-11-11
這篇文章主要介紹了Java實現(xiàn)輸入流轉化為String的相關資料,需要的朋友可以參考下2016-12-12