调用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、python、JavaScript以及jquery循环语句的区别

    java、python、JavaScript以及jquery循环语句的区别

    本篇文章主要介绍java、python、JavaScript以及jquery的循环语句的区别,这里整理了它们循环语句语法跟示例,以便大家阅读,更好的区分它们的不同
    2016-07-07
  • Java中Function的使用及说明

    Java中Function的使用及说明

    这篇文章主要介绍了Java中Function的使用及说明,具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教
    2023-05-05
  • Mybatis generator mapper文件覆盖原文件的示例代码

    Mybatis generator mapper文件覆盖原文件的示例代码

    这篇文章主要介绍了Mybatis generator mapper文件覆盖原文件,本文通过实例代码给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友可以参考下
    2020-11-11
  • SpringBoot使用mybatis步骤总结

    SpringBoot使用mybatis步骤总结

    今天给大家带来的是关于Java的相关知识,文章围绕着SpringBoot使用mybatis步骤展开,文中有非常详细的介绍及代码示例,需要的朋友可以参考下
    2021-06-06
  • HttpClient的DnsResolver自定义DNS解析另一种选择深入研究

    HttpClient的DnsResolver自定义DNS解析另一种选择深入研究

    这篇文章主要为大家介绍了HttpClient的DnsResolver自定义DNS解析另一种选择深入研究,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
    2023-10-10
  • 为zookeeper配置相应的acl权限

    为zookeeper配置相应的acl权限

    这篇文章主要介绍了为zookeeper配置相应的acl权限的相关实例,具有一定参考价值,需要的朋友可以了解下。
    2017-09-09
  • Springboot项目启动优化方式

    Springboot项目启动优化方式

    文章详细介绍了Spring Boot项目的启动优化策略,包括懒加载、异步初始化、精简依赖、JVM优化和使用Actuator监控等方法,旨在提高项目的启动速度和运行性能
    2025-03-03
  • Java中toString()、String.valueOf、(String)强转区别

    Java中toString()、String.valueOf、(String)强转区别

    相信大家在日常开发中这三种方法用到的应该很多,本文主要介绍了Java中toString()、String.valueOf、(String)强转区别,感兴趣的可以了解一下
    2021-09-09
  • Java中的cglib代理详解

    Java中的cglib代理详解

    这篇文章主要介绍了Java中的cglib代理详解, 代理模式是一种设计模式,它可以为其他对象提供一种代理,以控制对该对象的访问,可以在运行时动态地创建代理对象,而不需要手动编写代理类的代码,需要的朋友可以参考下
    2023-09-09
  • 浅谈Spring Data如何简化数据操作的方法

    浅谈Spring Data如何简化数据操作的方法

    这篇文章主要介绍了看Spring Data如何简化数据操作的方法,小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧
    2019-04-04

最新评论