java调用shell脚本想要error，info等信息的注意点

情景1：

源头java调1.sh脚本，1.sh脚本中会启动java程序

A. java调用1.sh的脚本不管带不带“nohup”或者"nohup ... > 2>&1 "，java的error和info管道都是由1.sh中启动java的命令行的写法决定的

B. 基于A，1.sh中启动java的命令由下列注意点：

1. 想要通过process的errorStream和inputStream获取对应的调用信息，那么在目标sh命令中就不要带"nohup ... > 2>&1",也不要"nohup ... > nohup.out"，因为这些都会把信息输出到指定位置（可以理解前者是特殊的一个位置而已）。

然而，"nohup ..."是可以的。

2. 但是基于1，1.sh脚本中的jar启动命令不写nohup了，jar启动后的所有logger输出却也会待会给源头java的info通道中，导致源头java处获取并输出（如果让输出了的话）一大片日志。

3. 为了2，就把“nohup... > /dev/null 2>&1”加上了，之后没有了2的大片日志。如果1.sh中的脚本层面有问题，error通道还是可以收到错误信息的。

4. 类似与1，如果在1.sh中启动jar的命令结尾追加了“&”(除了这个尾巴处由个'&',其它地方完全的java -jar a.jar的标准写法)，info和error都是收不到信息的

乱序记录（仅仅个人看的）：

1. java1启动1.sh后设置了两个futuretask

用于监听info和error通道并接受数据 -> 1.sh启动java2程 -> java2每隔2s输出一次info日志。于是java1程序每间隔2s输出一次收到的信息（说明info通道一直在输出），但是一直没有报错，所以error一直在阻塞；info在收到信息中匹配到关键字的话，会调用proces的destroyForcibly()方法取消process的wait，wait醒后下面的代码是调用info和erro通道的futureTask的interrupt函数用来停止这两个监听线程。首先，info和error中的while是进入下一次循环先执行还是wait下面的interrupt限制性的顺序是没有办法保证的（理由见2，当然除非使用sleep等手段），但是现象是：info监听的task可以停止，而error的没有停止。

原因：首先两个监听进程能不停的监听是因为有个while循环，循环条件是readLine和thread.isInterrupted，如下：

while ( !Thread.currentThread().isInterrupted() && (line = bufferedReader.readLine())!=null) {
...

 }

interrupted写在前边是为了能在每次进入while时先进行interrupted的判断，感知是否被futuTask调用过inteerrupted函数，避免了readLine在前出现的永久会阻塞等待没有机会判断interrupted而导致的不能退出while循环的问题。

bufferreader的readline函数阻塞，而info监听者的while循环中的一个条件：reader.readline()!=null这一行每隔2s就能往下运行，因此最迟2s就能进入下一次while循环，而此时while的另一个条件：Thread.currentThread().isInterrupted()函数就会使得线程结束。

而error由于一直阻塞在readLine上，因此一直没有机会去执行Thread.currentThread().isInterrupted()的判断，所以会一直占用线程，导致最后main线程和info线程退出了，可它却还在，所以java1程序一直在占用系统进程。

2. java调用脚本后返回的proces对象，可以执行destroyForcibly()方法取消waitFor()。我的一个实验是：process在wait，同时新开了两个线程分别监听info和error通道，其中info通道收到关键字后，会想要打断process的wait，因此我给那两个线程中出传入了process引用，从而可以打断。不过，这里需要注意的就是，process被打断wait后，当前cpu不一定会立马执行waitFor下面的代码，还有可能执行info或者error通道线程中的代码的，因为这是三个线程嘛，一定要注意。