深入理解Java虚拟机----（四）性能监控与故障处理工具

    前面的理论知识是解决问题的基础，经验是催化剂，数据是原料，工具是手段。其中数据包括线程快照、运行日志、GC日志、堆快照、异常堆栈等。下面介绍一下工具。     命令行工具     bin目录中，JDk为我们提供了强大稳定的工具集合，他们都是lib/tool.jar类库的包装。主要有

• jps ： 显示所有虚拟机进程。类似UNIX的ps命令。如果启动了多个虚拟机，通过该命令查询LVMID可以区分。
• jstat ： 收集虚拟机各方面的运行数据。在没有可视化软件的时候，可以提供丰富的信息。
• jinfo ： 显示虚拟机配置。很多参数有默认值，未被显式配置，可以用这个命令查看。
• jmap ： 生成堆转储快照。还可以查看fianlize执行队列、java堆和永久代使用情况、当前用的哪个收集器。
• jhat ： 分析堆快照，建立http服务器，供用户查看。功能比较简陋，有很多强大的代替品。
• jstack ： 生成虚拟机的线程快照，用于定位长时间停顿的原因，死锁、等待其他资源等。

    可视化工具

• JConsole
• VisualVM：官方主推工具。提供监控、性能分析、故障处理。优点是不会对应用产生多大影响。
  • 一个有意思的插件BTrace。利用HotSwap技术，将调试代码动态加入运行中的系统。

    案例

• 一个web文档服务器使用了一个64位虚拟机运行系统，堆大小设置为12G，默认使用吞吐量优先收集器。访问量不算大，但是每10多分钟就会无响应十几秒，这个时间是绝对无法忍受的。查看日志发现是gc导致的停顿。文档会读入到内存，进入老年代，12G的内存回收起来需要很长的时间。这里的程序设计首先就有一定的问题，文档对象都是一些大对象，直接在内存中存储本身就不是一个好的方案。而且32位的虚拟机在性能方面要比64位的好一些。后来改为在一台物理机上运行多个32位虚拟机，前端建立反向代理。并且改用CMS收集器。问题解决了。
• 一个系统运行一会就会经常的报出OOM，设置参数让虚拟机在产生OOM时生成堆转储快照，没反应。只能开着jstat盯着，发现报错时，各区域内存都正常，很平稳。后来发现是机器内存2G，虚拟机堆分配1.6G.而系统大量使用NIO，分配了堆外内存导致的。
• 一个系统监控时，cpu使用率非常高，但是系统本身的进程cpu占用率很低，这很不正常。后来发现程序很次用户请求都要执行一个外部的shell脚本。利用的是Runtime.getRuntime().exec()方法，这个方法会常见一个进程再执行，频繁的这个操作很消耗cpu和内存资源。
• 一个系统接入了一个外部服务，但是有几个接口不可用，导致很多请求长达3分钟才返回连接断开的错误。为了不被拖累，采用了异步方式访问，就导致了越来越多的请求没有被处理完成，OOM。后来修复了不可用接口，同时改为生产者-消费者模式处理。