最近在用ffmpeg做音频文件的转换,开发环境是win,本地使用没有毛病,直接Runtime.getRuntime().exec("ffmpeg.exe ...")就可以了。但是今天到了测试阶段,应用部署到服务器上,直接就炸了。应用刚起来,调接口,正常,再调就不行了,等一会,又正常,然后又不行,再等一会,又可以了。。。反正就是很玄幻。。
听同事说,起一个线程单独去调用ffmpeg是没问题的,但是我转念一想,我这个业务逻辑,就是需要接口是同步的,客户端要等待ffmpeg完成处理才行。。而且就算一次调用阻塞了,另一个请求过来,也是一个新的线程啊,怎么之前的线程会影响现在这个线程?
怀疑是调起一个新进程导致本java线程阻塞,但是每次调用不都是一个新的线程么???
直到看到csdn一篇文章。
![e4ea57820af2f192c2d52d71333f1dcc.png](https://i-blog.csdnimg.cn/blog_migrate/4fee12c8d8d78bd2b50426a8c2ad8aee.jpeg)
文章说:Runtime对象调用exec方法后,JVM会启动一个子进程,该进程会与JVM进程建立三个管道连接,分别是标准输入、标准输出、标准错误。
如果程序不断想标准输出和标准错误两个流写入数据,而JVM却没有读取的话,当缓冲区满了,就无法继续写入,导致外部进程阻塞,进而使我们的程序阻塞在process.waitFor()。
文章作者也做了实验,在程序中,手动读出输出流里的数据,就能是缓冲区不会写满,进而不会导致我们上面说的问题。而且ffmpeg有一个参数-loglevel quiet可以禁止外部程序向JVM写入数据。
所以我就在我执行的ffmpeg命令中加了这个参数,之前的问题就没有了,每次调用接口都能正常返回。。。
可是我还是不清楚,我的程序里调用了process.waitFor(),第一个请求过来了,成功返回了,说明没有阻塞住,为什么第二个请求会不行呢?