调用Process.waitfor导致的进程挂起问题及解决

 更新时间:2021年12月14日 09:04:38   作者:我是安静的美男子  
这篇文章主要介绍了调用Process.waitfor导致的进程挂起问题及解决,具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教

问题背景

如果要在Java中调用shell脚本时,可以使用Runtime.exec或ProcessBuilder.start。它们都会返回一个Process对象,通过这个Process可以对获取脚本执行的输出,然后在Java中进行相应处理。

例如,下面的代码:

		try 
		{
			Process process = Runtime.getRuntime().exec(cmd);			
			process.waitFor();                        
                        //do something ...
		} 
		catch (Exception e) 
		{			
			e.printStackTrace();
		}

通常,安全编码规范中都会指出:使用Process.waitfor的时候,可能导致进程阻塞,甚至死锁。 那么这句应该怎么理解呢?用个实际的例子说明下。

问题描述

使用Java代码调用shell脚本,执行后会发现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会创建一个子进程,用于执行shell脚本。子进程创建后会和主进程分别独立运行。
  • 因为主进程需要等待脚本执行完成,然后对脚本返回值或输出进行处理,所以这里主进程调用Process.waitfor等待子进程完成。
  • 通过shell脚本可以看出:子进程执行过程就是不断的打印信息。主进程中可以通过Process.getInputStream和Process.getErrorStream获取并处理。
  • 这时候子进程不断向主进程发生数据,而主进程调用Process.waitfor后已挂起。当前子进程和主进程之间的缓冲区塞满后,子进程不能继续写数据,然后也会挂起。
  • 这样子进程等待主进程读取数据,主进程等待子进程结束,两个进程相互等待,最终导致死锁。

解决方法

基于上述分析,只要主进程在waitfor之前,能不断处理缓冲区中的数据就可以。因为,我们可以再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的说明中可以看出两点:

  • 如果系统中标准输入输出流使用的bufffer大小有限,所有读写时可能会出现阻塞或死锁。------这点上面已分析
  • 子进程的标准I/O已经被重定向到了父进程。父进程可以通过对应的接口获取到子进程的I/O。------I/O是如何重定向的?

背后的故事

要回答上面的问题可以从系统的层面尝试分析。

首先通过ps命令可以看到,在linux上多出了两个进程:一个Java进程、一个shell进程,且shell是java的子进程。

然后,可以看到shell进程的状态显示为pipe_w。我刚开始以为pipe_w表示pipe_write。进一步查看/proc/pid/wchan发现pipe_w其实表示为pipe_wait。通常/proc/pid/wchan表示一个内存地址或进程正在执行的方法名称。因此,这似乎表明该进程在操作pipe时发生了等待,从而被挂起。我们知道pipe是IPC的一种,通常用于父子进程之间通信。这样我们可以猜测:可能是父子进程之间通过pipe通信的时候出现了阻塞。

另外,观察父子进程的fd信息,即/proc/pid/fd。可以看到子进程的0/1/2(即:stdin/stdout/stderr)分别被重定向到了三个pipe文件;父亲进程中对应的也有对着三个pipe文件的引用。

综上所述,这个过程应该是这样的:子进程不断向pipe中写数据,而父进程一直不读取pipe中的数据,导致pipe被塞满,子进程无法继续写入,所以出现pipe_wait的状态。那么pipe到底有多大呢?

测试pipe的大小

因为我已经在doecho.sh的脚步中记录了打印了字符数,查看count.log就可以知道子进程最终发送了多少数据。在子进程挂起了,count.log的数据一致保持在6543不变。故,当前子进程向pipe中写入6543*10=65430bytes时,出现进程挂起。65536-65430=106byte即距离64K差了106bytes。

换另外的测试方式,每次写入1k,记录总共可以写入多少。进程代码如test_pipe_size.sh所示。测试结果为64K。两次结果相差了106byte,那个这个pipe到底多大?

Linux上pipe分析

最直接的方式就是看源码。Pipe的实现代码主要在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被组织成环状结构,即一个循环链表。链表中的元素为struct pipe_buffer的结构,每个pipe_buffer对于一个page。链表中共有16个元素,即pipe buffer的总大小为16*page。如果page大小为4K,那么pipe buffer的总大小应该为16*4K=64K。

以上为个人经验,希望能给大家一个参考,也希望大家多多支持脚本之家。

相关文章

  • java和matlab画多边形闭合折线图示例讲解

    java和matlab画多边形闭合折线图示例讲解

    由于要将“哈密顿回路问题(TSP)”的求解中间结果表示出来,查了一下使用程序画多边形图形。现在在总结一下,这个图是“由给定节点首尾相连的”闭合多边形
    2014-02-02
  • SpringBoot MyBatis简单快速入门例子

    SpringBoot MyBatis简单快速入门例子

    MyBatis 是一款优秀的持久层框架,它支持自定义 SQL、存储过程以及高级映射。这篇文章主要介绍了SpringBoot MyBatis快速入门-简单例子,需要的朋友可以参考下
    2021-07-07
  • SpringBoot实现OneDrive文件上传的详细步骤

    SpringBoot实现OneDrive文件上传的详细步骤

    这篇文章主要介绍了SpringBoot实现OneDrive文件上传的详细步骤,文中通过代码示例和图文讲解的非常详细,对大家实现OneDrive文件上传有一定的帮助,需要的朋友可以参考下
    2024-02-02
  • 详解Spring Boot 使用Spring security 集成CAS

    详解Spring Boot 使用Spring security 集成CAS

    本篇文章主要介绍了详解Spring Boot 使用Spring security 集成CAS,具有一定的参考价值,感兴趣的小伙伴们可以参考一下
    2017-05-05
  • SpringBoot属性注入的两种方法

    SpringBoot属性注入的两种方法

    这篇文章主要介绍了SpringBoot属性注入的两种方法,帮助大家更好的理解和使用springboot框架,感兴趣的朋友可以了解下
    2020-11-11
  • logback过滤部分日志输出的操作

    logback过滤部分日志输出的操作

    这篇文章主要介绍了logback过滤部分日志输出的操作,具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教
    2021-08-08
  • ReentrantReadWriteLock不能锁升级的原因总结

    ReentrantReadWriteLock不能锁升级的原因总结

    今天给大家带来的是关于Java并发的相关知识,文章围绕着为什么ReentrantReadWriteLock不能锁升级展开,文中有非常详细的介绍及代码示例,需要的朋友可以参考下
    2021-06-06
  • SpringBoot @Profile的使用

    SpringBoot @Profile的使用

    本文主要介绍了SpringBoot @Profile的使用,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
    2023-06-06
  • Java实现发红包功能

    Java实现发红包功能

    这篇文章主要为大家详细介绍了Java实现发红包功能,文中示例代码介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们可以参考一下
    2020-11-11
  • Java实现输入流转化为String

    Java实现输入流转化为String

    这篇文章主要介绍了Java实现输入流转化为String的相关资料,需要的朋友可以参考下
    2016-12-12

最新评论