借助开源工具高分效析Java应用的运行.docxVIP

借助开源工具 高效分析Java应用的运行　不止一次，我们都萌发过想对运行中程序的底层状况一探究竟的念头。产生这种需求的原因可能是运行缓慢的服务、Java虚拟机(JVM)崩溃、挂起、死锁、频繁的JVM暂停、突然或持续的高CPU使用率、甚至于可怕的内存溢出(OOME)。好消息是现在已有许多工具能帮你得到Java虚拟机运行过程中的不同参数，这些信息有助于你了解其内部状况，从而诊断上述的各种情况。　在这篇文章中，我将介绍一些优秀的开源工具。其中一些是JVM自带的，另一些则是第三方工具。我将从最简单的工具开始介绍，逐渐过渡到一些比较复杂的工具。本文的目的是帮助你找到合适的调试诊断工具，这样当程序出现执行异常、缓慢或根本不能执行时，手头随时有可用的工具。　好了，让我们出发。　如果程序出现不正常的高内存负载、频繁无响应或内存溢出，通常最好的分析切入点是查看内存对象。幸好JVM内置了工具“jmap”，让它天生就能完成这种任务。　Jmap(借助JPM的一点帮助)　Oracle将jmap描述为一种“输出进程、核心文件、远程调试服务器的共享对象内存映射和堆内存细节”的程序。本文将使用jmap打印一张内存统计图。　为了运行jmap，你需要知道被调试程序的PID(进程标识符)。得到PID的简单办法是使用JVM提供的jps，它能列出机器上每一个JVM进程及其PID。jps输出结果如下图：　▲jps命令的终端输出　为了打印内存统计图，我们需要打开jmap控制台程序，并输入程序的PID和“-histo:live”选项。如果不添加这个选项，jmap将完整导出该程序的堆内存,这不是我们想要的结果。所以，如果想得到上图中“eureka.Proxy”程序的内存统计图，我们应该用如下命令来运行jmap：以下是代码片段：　jmap –histo:live 45417　上述命令输出如下：　▲命令jmap -histo:live的输出结果显示了堆中现有对象的个数　结果中每行显示了当前堆中每种类类型的信息，包含被分配的实例个数及其消耗的字节数。　本例中，我请同事有意给程序增加了一处明显的内存泄露。请特别注意位于第8行的类，CelleData。将它与下图显示的4分钟后截屏进行比较：　▲jmap的输出表明CelleData类的对象数目增加了　请注意CelleData类现在已经变为系统中第二多的类，短短4分钟内已经增加了631,701个额外实例。等待约一小时后，我们观察到如下结果：　▲程序执行1小时后jmap的输出结果，显示超过2千5百万个CelleData类实例　现在有超过2千5百万个CelleData类实例，占用了超过1GB内存!我们可以确认这是一个内存泄露。　这类数据信息的好处是，不仅非常有用而且对于很大的JVM堆也能快速反馈结果。我曾经试过检测一个运行频繁并且占用17GB堆内存的程序，使用jmap能够在1分钟内生成程序的性能统计图。　需要注意的是，jmap不是运行分析工具，在生成统计图时JVM可能会暂停，因此当生成统计图时需要确认这种暂停对程序是可接受的。以我的经验，通常在调试一个严重bug时需要生成这种统计图，这种情况下，这些1分钟的暂停对程序来说是可接受的。这里，我们引出了下一个话题 - 半自动的运行分析工具VisualVM。　VisualVM　另一个包含于JVM中的工具是VisualVM，它的开发者将它描述为“一种集成了多个JDK命令行工具的可视化工具，它能为您提供轻量级的运行分析能力”。这样看来，VisualVM是另一种你最有可能用到的事后分析工具，一般是错误已出现或性能问题已经用传统方法(客户抱怨大多属于此类)发现。　继续之前的示例程序和它严重的内存泄露问题，在程序执行30分钟后，VisualVM帮我们绘制了如下图表：　▲图5：程序初始运行的VisualVM 内存图　从这个图表，我们可以清晰地看到截止到7:00pm，运行仅仅10分钟后，程序已经消耗掉超过1GB的堆空间。又过了23分钟，JVM已经到了它启动参数–Xmx3g最大值，导致程序响应缓慢，系统响应缓慢(持续的垃圾回收)和数量惊人的内存溢出错误。　借助jmap，我们定位了这种内存消耗攀升的原因。修复后，我们让程序重新运行于VisualVM的严格监测之下，观察到下面的情况：　▲图6：修复内存泄露问题后的VisualVM内存图　如你所见，程序的内存曲线(启动参数仍然为–Xmx3g)有了明显改善。　除了内存图像工具，VisualVM还提供了一个采样器和一个轻量级的剖析器(Profiler)。　VisualVM采样器能周期采样程序CPU和内存的使用情况。得到的统计数据类似jmap的反馈，此外，你还可以通过采样得到方法调用对CPU的占用情况。它让你能快速了解周期采样过程中的方法执行次数：　▲图7：VisualVM方法执