Runtime.exec使用错误导致延迟
2015-06-02 21:17
323 查看
这篇文章是纪录了一个bug解决的过程,但是我还是没有能够真正地找出bug的缘由。希望大牛能够详细解释。
为了方便,我直接就用java调用python脚本。用python脚本处理做核心的机器学习算法的东西。而java调用python脚本,我直接就采用了Runtime.getRuntime().exec(),这个方式类似于直接使用了shell来执行。一开始使用的挺好,也没有注意一些细节的问题,慢慢地用着用着,发现有一台机器处理相同地人脸头像比另外一台慢。从经验上考虑过很多的可能情况,但是都不是问题的真正原因。但每一个误判,我感觉都非常值得反思。
之后通过对代码片段打印时间,每一段执行完都打印时间点。最后查看日志发现,就是在调用process.waitfor的时候,python程序已经返回了,但是java程序仍然没有任何响应,还是在wait。这样才发现了这个问题。然后通过在网上搜索Runtime.getRuntime()执行程序应该注意的事项,找到问题的关键。我使用waitfor,之后再去读取python程序的输出,但是因为输出一直没有被读取,缓冲区满了,程序就被阻塞。
我一开始的程序是像下面这样的:
这样的结果就是一台机器在waitFor那里被卡住很长一段时间。然后参考了网上给的原因,将程序改成下面这样:
这样程序就不会长时间卡在那里。甚至于去掉p。waitFor程序也是OK的。因为程序结束后,Stream就被close掉了。网上很多人是遇到了因为exec执行的程序出现了错误,结果Error信息占满了缓冲区,导致程序被挂起。
另外也有一个可能是python程序执行完后,很长时间都没有完全返回。这也是一个猜测的原因。虽然我按照网上的方式暂时解决了问题,但这些原因其实我觉得都不够充分,希望有人能够给出正确的解释。基础真的要牢靠。
问题的发现
当接触的系统越来越大的时候,对于系统的性能越来越高的时候,找到表面问题的真正原因就慢慢地成为了一个比较麻烦的问题。说实话,一开始我一直不知道是因为Runtime.getRuntime().exec()导致服务处理时间缓慢。发现这个原因倒是花了不少时间。为了方便,我直接就用java调用python脚本。用python脚本处理做核心的机器学习算法的东西。而java调用python脚本,我直接就采用了Runtime.getRuntime().exec(),这个方式类似于直接使用了shell来执行。一开始使用的挺好,也没有注意一些细节的问题,慢慢地用着用着,发现有一台机器处理相同地人脸头像比另外一台慢。从经验上考虑过很多的可能情况,但是都不是问题的真正原因。但每一个误判,我感觉都非常值得反思。
网络问题
由于我使用了内网穿透工具,本身对工具性能也不熟悉,刚开始的时候立刻就想到了是不是因为使用了内网穿透工具,导致网速太慢了。由于这个问题我几乎就无法解决,所以我一想到这个原因,就没有再去想办法解决了。后面直接发现直接从访问的结果仍然是一样的慢。其实这个地方我应该去验证一下,直接从内网访问,看一下速度。这样就能够避免误判带来的问题了。机器配置问题
由于两台机器配置的时候还是存在一点点不同,我后面又想是不是一台机器配置出现问题?检查了半天还是不能确认是不是机器配置不同,安装的内容不同导致出现了问题。由于没什么时间,干脆我又扔一边去了。某些随机因素
因为一台机器执行快速,另外一台执行缓慢,而出现这种诡异的问题,很容易就让人想到是不是代码库因为某些原因,导致了这种情况。而往往这种问题就基本是没有办法搞定了。其实我还是一个新手的时候,我总是怀疑某些问题是因为一些系统错误,随机因素导致的。但是结果往往是自己的错误。因为有了之前的经验,我潜意识就感觉可能是自己哪段代码出现了错误。之后通过对代码片段打印时间,每一段执行完都打印时间点。最后查看日志发现,就是在调用process.waitfor的时候,python程序已经返回了,但是java程序仍然没有任何响应,还是在wait。这样才发现了这个问题。然后通过在网上搜索Runtime.getRuntime()执行程序应该注意的事项,找到问题的关键。我使用waitfor,之后再去读取python程序的输出,但是因为输出一直没有被读取,缓冲区满了,程序就被阻塞。
getRuntime().exec
getRuntime().exec会返回一个Process,在jdk文档中有说明,Process的缓冲区是有限的,如果输出的内容太多,程序就会被阻塞掉。我一开始的程序是像下面这样的:
try { final Process p = Runtime.getRuntime().exec("python test.py"); p.waitFor(); BufferedReader br = new BufferedReader(new InputStreamReader(p.getInputStream())); try { while (br.readLine() != null) ; br.close(); } catch (IOException e) { e.printStackTrace(); } } catch (Exception e) { e.printStackTrace(); }
这样的结果就是一台机器在waitFor那里被卡住很长一段时间。然后参考了网上给的原因,将程序改成下面这样:
try { final Process p = Runtime.getRuntime().exec("python test.py"); BufferedReader br = new BufferedReader(new InputStreamReader(p.getInputStream())); try { while (br.readLine() != null) ; br.close(); } catch (IOException e) { e.printStackTrace(); } p.waitFor(); } catch (Exception e) { e.printStackTrace(); }
这样程序就不会长时间卡在那里。甚至于去掉p。waitFor程序也是OK的。因为程序结束后,Stream就被close掉了。网上很多人是遇到了因为exec执行的程序出现了错误,结果Error信息占满了缓冲区,导致程序被挂起。
原因探究
从网上看的那些信息只能让我猜测可能是因为打印信息太多,没有及时读出,导致程序卡住。但是我心里还是有疑问,为什么一台机器ok,另外一台机器会卡住,过很长时间才返回呢?这里面具体的细节方面的原因我觉得我还是没有找对。其实我python程序打印的东西也不多的。另外也有一个可能是python程序执行完后,很长时间都没有完全返回。这也是一个猜测的原因。虽然我按照网上的方式暂时解决了问题,但这些原因其实我觉得都不够充分,希望有人能够给出正确的解释。基础真的要牢靠。
相关文章推荐
- SourceProvider.getJniDirectories
- [原创]java局域网聊天系统
- Trac 中文语言安装
- 选定虚拟主机 性能凸显优势
- Firefox2中输入框丢失光标bug的解决方法
- 修改一行代码提升 Postgres 性能 100 倍
- Windows 系统组策略应用全攻略(下)第1/3页
- 推荐Sql server一些常见性能问题的解决方法
- 如何进行系统配置
- for命令的一些bug分析
- C#列出当前系统所有正在运行程序的方法
- SQL Server误区30日谈 第9天 数据库文件收缩不会影响性能
- 和表值函数连接引发的性能问题分析
- SQLServer 2000 升级到 SQLServer 2008 性能之需要注意的地方之一
- SqlServer系统数据库的作用深入了解
- Powershell获取系统中所有可停止的服务
- 数据库性能优化三:程序操作优化提升性能
- VBS中的字符串连接的性能问题
- 修正IE下使用CSS属性overflow的bug
- 解决IE6 3像素Bug的css写法