Runtime.getRuntime().exec 路径包含空格的解决

Runtime.getRuntime().exec 路径包含空格

1. 现象

java代码通过Runtime.getRuntime().exec删除linux上的目录，如果路径信息不包含空格没有问题，但是有了空格，虽没有报错，但执行没有效果，文件夹删不掉。

2. 原因

Runtime.getRuntime().exec语法不支持空白符和管道符"|"

不支持空白符和管道符"|"的例子：

//包含空格
String cmd = "rm -fr test 1";
// 包含管道符
String cmd2 = "netstat -antup | grep ftp";
Process ps = Runtime.getRuntime().exec(cmd);
ps.waitFor();

解决办法

如果直接在命令行执行的话，可以通过给完整的字符带上单引号或双引号，java代码用法不适用。

[root@EMS3 ~]# rm -rf "/root/test 1"

使用重载函数即可：

public Process exec(String cmdarray[])

String cmd = "rm -fr test 1";
// 或
String cmd2 = "netstat -antup | grep ftp";
Process ps = Runtime.getRuntime().exec(new String[]{"/bin/sh", "-c", cmd});
ps.waitFor();
...

其中-c表示cmd是一条命令

/bin/sh -c注意事项

由于增加了-c 参数，并指定shell类型，因此需要确认shell的类型。因此根据实际环境的shell类型。

/bin/sh是什么？

shell编程是以"#“为注释，但对”#!/bin/sh"却不是。"#!/bin/sh"是对shell的声明，说明你所用的是那种类型的shell及其路径所在（#! /bin/sh 是指此脚本使用/bin/sh来解释执行，#!是特殊的表示符，其后面跟的是解释此脚本的shell的路径）。如果没有声明，则脚本将在默认的shell中执行，默认shell是由用户所在的系统定义为执行shell脚本的shell。

如果脚本被编写为在Kornshell ksh中运行，而默认运行shell脚本的为C shell csh,则脚本在执行过程中很可能失败。所以建议大家就把"#!/bin/sh"当成C 语言的main函数一样，写shell必须有，以使shell程序更严密。

Runtime.getRuntime().exec()产生阻塞的2个陷阱

背景

相信做java服务端开发的童鞋，经常会遇到Java应用调用外部命令启动一些新进程来执行一些操作的场景，这时候就会使用到Runtime.getRuntime().exec()，然而这个方法如果不谨慎很容易掉进陷阱。

我们的一个PDF转码服务就踩到了这个坑掉进陷阱，这个转码服务主要是对pdf进行加密和转码成swf。这个服务上线后大部分时间都是稳定运行的，但是隔一段时间就会死掉，然后人肉手动重启一下服务就复活了。看了日志，有时候有一堆关于pdf转码过程的错误日志，有时候死掉的时候什么日志也没输出。这时候猜测可能是pdf转码异常导致应用挂掉的｛因为这个转码服务一直是单线程在工作｝。更深的原因大家也空没去找。反正运营反馈上传的pdf一直处在转码中很久了，一两天了还在转码中，于是开发就手动重启下服务。是的你没看过，就是一两天才发现，我们的业务监控没作上去，因为相对迭代任务，这都算不紧急的事情了。

后来运营反馈pdf问题次数增多了，于是写了个脚本，定时去检查日志最后的更新时间，发现日志超过一个小时没更新就重启应用，重启脚本没问题，问题是应用重启后，日志中出现了一堆的找不到要执行的命令。目前也不知道为什么通过脚本去重启动应用后，应用找不到要执行的命令。有知道的可以告知下。

终于某一天，应用又死掉了，看了下数据库堆积了将近2000个待转的文件。看了下应用日志打了exe()后就再也没内容了，于是下狠心花了半天时间来研究下Runtime.getRuntime().exe()找了下原因，最终解决了这个问题。

关于Runtime.getRuntime().exe()

根据jdk官方文档描述，每个Java应用都存在一个而Runtime的单例实例。这个类Runtime类封装了应用运行时的环境，通过这个类我们的java应用可以与其运行环境相连接。

1、java应用无法创建自己的Runtime实例，只能通过Runtime.getRuntime()来取得当前JVM的运行时环境，这也是在Java中唯一一个得到运行时环境的方法。一旦得到了一个当前的Runtime对象的引用，就可以调用Runtime对象的方法来控制Java虚拟机的状态和行为。

2、Runtime中的exit方法是退出当前JVM的方法，System类中的exit实际上也是通过调用Runtime.exit()来退出JVM的，这里说明一下Java对Runtime返回值的一般规则（后边也提到了），0代表正常退出，非0代表异常中止。

3、Runtime具有的详细方法请参考官方api，http://docs.oracle.com/javase/8/docs/api/

阻塞陷阱之Runtime.getRuntime().exe()的返回值Process

应用在调用Runtime.getRuntime().exec()这个方法会创建一个本机进程并返回Process子类的一个实例。该实例可用来控制该进程并获得其相关信息。Process类提供了执行从进程输入、执行输出到进程、等待进程完成、检查进程的退出状态以及销毁（杀掉）进程的方法。

官方文档解释了创建进程的方法可能无法针对某些本机平台上的特定进程很好地工作，比如，本机窗口进程，守护进程，Microsoft Windows 上的 Win16/DOS 进程，或者 shell脚本。创建的子进程没有自己的终端或控制台。它的所有标准 io（即 stdin、stdout 和 stderr）操作都将通过三个管道重定向到父进程（也就是调用者java应用）。三个管道用于处理标准输入流，标准输出流，标准错误流。子进程在执行过程中，会不断的向JVM写入标准输出和标准错误输出。java应用可以通过Process 提供的getOutputStream()、getInputStream() 和 getErrorStream()来获得子进程输入输出信息。因为有些本机平台仅针对标准输入和输出流提供有限的缓冲区大小，当标准输出或者标准错误输出写满缓存池时，程序无法继续写入，子进程无法正常退出。读写子进程的输出流或输入流迅速出现失败，则可能导致子进程阻塞，甚至产生死锁。

当调用Runtime.getRuntime().exe()后返回的Process对象除了可以多的三种输入输出流外，还有两个常用的方法:

1、非阻塞方法exitValue()获得子进程退出的状态值（0，正常退出，非0异常退出），需要注意的是调用这个方法程序会立即得到结果，如果子进程没有执行完，调用这个方法会抛出IllegalThreadStateException，表示此 Process 对象表示的子进程尚未终止。

2、阻塞方法 waitFor()导致当前线程等待，直到子进程结束并返回退出状态。如果已终止该子进程，此方法立即返回，如果没有终止该子进程，调用的线程将被阻塞，直到退出子进程。

先看看我们转码服务这里的历史代码：

这段代码，用同步的方法去读取标准错误输出流即相当于清空了错误输出流缓冲区，然而正常的标准输出流并没有清空，按照上面的原理解释，阻塞的原因可能就产生在这里。当阻塞产生的时候jstack了一下线程栈信息如下图所示。确实线程锁在了读取缓冲流上面了。

这种情况网上通用的解决方法就是异步开两个线程去读取正常的输出和错误输出流信息，清空缓冲区，参考了大家的解决方法，下图是修改后的方案，ProcessClearStream是一个异步线程，主要做的是将标准inputSream读取完毕。

阻塞陷阱之子进程阻塞

通过上面的代码优化后还是发现有转码阻塞的现象出现，而且发现每次阻塞都出现在固定的几个pdf上，测试发现重启应用后主要转到那几个特定的pdf时候，转码服务必挂无疑（通常一个pdf转码只需要几十秒，而这个阻塞持续几个小时，不人为干预它就可能无限阻塞下去）。所以重启应用也不管用了，只能跳过这几个pdf应用才行，于是在测试环境测试这几个pdf，每次阻塞的时候再jstack发现应用阻塞在proc.waitFor()，再也没其他错误信息了。查看了官方api，Process的waitFor方法本身会阻塞直到子进程正常或异常退出，到这里，应该可以推断是子进程无限阻塞下去了，导致waitFor一直阻塞中。为了验证这个推断，直接在终端kill掉这个子进程，然后再查看日志，发现转码服务又继续工作了。

有了上面的结论，一个简单的思路也就有了，我需要检测子进程状态，如果发现子进程有阻塞状态就kill掉（因为这个转码脚本比较老，要拿他的堆栈信息比较麻烦，所以kill掉是最简单直接暴力效率高的方法）。将这个想法和同事聊了下，万能的Java肯定可以干这事，大概思路就启动个线程去监控process的waitFor的阻塞时间，超过设置时间，就干掉了子进程，这不是Java线程池ExecutorService类配合Future接口来干的事情么。同事按照这个思路网上找了下现成的代码，于是照着这个这个方法抄袭了一下，下面贴下关键的代码：

当waitFor超时线程中断的的时候再调用process的destroy()销毁子进程。这个方案上线后，截至目前一周多时间转码服务稳定运行，没在出现以前的服务死掉的情况。

我们业务中当检测到超时退出后就重置任务状态为失败（算是降级吧），导致这种pdf转码子进程阻塞的一般是pdf本身不太标准，而这个转码工具不能很好的兼容处理这些pdf，后面把这些有问题的pdf重新转成标准pdf上传测试即可以正常转码。

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