qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

开源工具高效分析Java应用

开源工具高效分析Java应用


 不止一次,我们都萌发过想对运行中程序的底层状况一探究竟的念头。产生这种需求的原因可能是运行缓慢的服务、Java虚拟机(JVM)崩溃、挂起、死锁、频繁的JVM暂停、突然或持续的高CPU使用率、甚至于可怕的内存溢出(OOME)。好消息是现在已有许多工具能帮你得到Java虚拟机运行过程中的不同参数,这些信息有助于你了解其内部状况,从而诊断上述的各种情况。

  在这篇文章中,我将介绍一些优秀的开源工具。其中一些是JVM自带的,另一些则是第三方工具。我将从最简单的工具开始介绍,逐渐过渡到一些比较复杂的工具。本文的目的是帮助你找到合适的调试诊断工具,这样当程序出现执行异常、缓慢或根本不能执行时,手头随时有可用的工具。

  好了,让我们出发。

  如果程序出现不正常的高内存负载、频繁无响应或内存溢出,通常最好的分析切入点是查看内存对象。幸好JVM内置了工具“jmap”,让它天生就能完成这种任务。

  Jmap(借助JPM的一点帮助)

  Oracle将jmap描述为一种“输出进程、核心文件、远程调试服务器的共享对象内存映射和堆内存细节”的程序。本文将使用jmap打印一张内存统计图。

  为了运行jmap,你需要知道被调试程序的PID(进程标识符)。得到PID的简单办法是使用JVM提供的jps,它能列出机器上每一个JVM进程及其PID。jps输出结果如下图:

图1:jps命令的终端输出

  为了打印内存统计图,我们需要打开jmap控制台程序,并输入程序的PID和“-histo:live”选项。如果不添加这个选项,jmap将完整导出该程序的堆内存,这不是我们想要的结果。所以,如果想得到上图中“eureka.Proxy”程序的内存统计图,我们应该用如下命令来运行jmap:

  jmap –histo:live 45417

  上述命令输出如下:

图2:命令jmap -histo:live的输出结果显示了堆中现有对象的个数

  结果中每行显示了当前堆中每种类类型的信息,包含被分配的实例个数及其消耗的字节数。

  本例中,我请同事有意给程序增加了一处明显的内存泄露。请特别注意位于第8行的类,CelleData。将它与下图显示的4分钟后截屏进行比较:

图3:jmap的输出表明CelleData类的对象数目增加了

  请注意CelleData类现在已经变为系统中第二多的类,短短4分钟内已经增加了631,701个额外实例。等待约一小时后,我们观察到如下结果:

图4:程序执行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方法执行时间表

  VisualVM剖析器无需对程序周期采样就可以提供类似采样器的反馈信息,它还可以收集程序在整个正常执行过程中的统计数据(通过操纵程序源代码的字节码)。从剖析器得到的这种统计数据比从采样器而来的更精确和实时。

图8:VisualVM剖析器的输出

  但是,你必须考虑的另一方面是该剖析器属于一种“暴力”分析工具。它的检测方法本质上是重新定义程序执行中的大多数类和方法,结果必然会明显减缓程序执行速度。例如,上述程序运行部分的常规分析,大约要35秒。开启VisualVM的内存剖析器后,导致程序完成相同分析要31分钟。

  我们需要清楚的是VisualVM并非功能齐全的剖析器。它无法在你的产品JVM上持续运行,不会保存分析数据,无法指定阈值,也不会在超过阈值时发出警报。要想更多的了解功能齐全的剖析器的目标。下面,让我们看看BTrace,这个功能齐全的开源java代理程序。

  BTrace

  想象一下,如果能收集JVM当前的任何信息,那么你感兴趣的信息有哪些?我猜想问题列表会将因人而异,因情形而异。就个人来说,我通常感兴趣的是以下的问题:

  程序对堆、非堆、永久保存区(Permanent Generation),以及JVM包含的不同内存池(新生对象区、长期对象区、存活空间等)的内存使用情况

  当前程序的线程数量,以及哪种类型线程正在被使用(单独计数)


  JVM的CUP负载

  系统平均负载/系统CPU使用总和

  对程序中的某些类和方法,我需要了解它们被调用次数,各自平均执行时间和整体平均时间

  对SQL调用的调用计数及执行次数

  对硬盘和网络操作的调用计数及执行次数

  利用BTrace可以采集到所有以上信息,你可以使用BTrace脚本定义需要采集的数据。方便的是,BTrace脚本就是普通Java类,包含一些特殊注解来定义BTrace在什么地方及如何跟踪你的程序。BTrace脚本会被BTrace编译器-btracec编译成标准的.class文件。

  BTrace脚本包含许多部分,正如下图所示。如果需要了解下图脚本的详细内容,请点击该链接或访问BTrace项目网站。

  由于BTrace仅仅是一个代理,记录结果后,它的任务就算完成了。除了文本输出,BTrace并不具备动态展现被收集信息的功能。缺省情况下,BTrace脚本输出结果将在btrace.class文件所在位置生成一个名为BTrace脚本名.class.btrace的text文件。

  我们可以通过给BTrace设置一个额外参数,让它按某时间间隔循环记录日志。切记,它最多能在100个日志文件间循环,当达到*.class.btrace.99,它将覆盖*.class.btrace.00文件。若让循环间隔在一个合理数字(如,每7.5秒)内,你就有充足时间来处理这些输出。只要在java代理的输入参数中加上fileRollMilliseconds=7500,就可以实现日志循环。

  BTrace一大缺点是它比较原始,难以定义它的输出格式。你也许非常希望有一种更好的方式来处理BTrace的输出和数据,比如可以用一种一致的图形用户界面来展示。你可能还需要比较不同时间点的数据和超出阈值能发送警告。一个新的开源工具EurekaJ,就此应运而生。

图9:激活方法分析时必需的BTrace脚本

  JVM的CUP负载

  系统平均负载/系统CPU使用总和

  对程序中的某些类和方法,我需要了解它们被调用次数,各自平均执行时间和整体平均时间

  对SQL调用的调用计数及执行次数

  对硬盘和网络操作的调用计数及执行次数

  利用BTrace可以采集到所有以上信息,你可以使用BTrace脚本定义需要采集的数据。方便的是,BTrace脚本就是普通Java类,包含一些特殊注解来定义BTrace在什么地方及如何跟踪你的程序。BTrace脚本会被BTrace编译器-btracec编译成标准的.class文件。

  BTrace脚本包含许多部分,正如下图所示。如果需要了解下图脚本的详细内容,请点击该链接或访问BTrace项目网站。

  由于BTrace仅仅是一个代理,记录结果后,它的任务就算完成了。除了文本输出,BTrace并不具备动态展现被收集信息的功能。缺省情况下,BTrace脚本输出结果将在btrace.class文件所在位置生成一个名为BTrace脚本名.class.btrace的text文件。

  我们可以通过给BTrace设置一个额外参数,让它按某时间间隔循环记录日志。切记,它最多能在100个日志文件间循环,当达到*.class.btrace.99,它将覆盖*.class.btrace.00文件。若让循环间隔在一个合理数字(如,每7.5秒)内,你就有充足时间来处理这些输出。只要在java代理的输入参数中加上fileRollMilliseconds=7500,就可以实现日志循环。

  BTrace一大缺点是它比较原始,难以定义它的输出格式。你也许非常希望有一种更好的方式来处理BTrace的输出和数据,比如可以用一种一致的图形用户界面来展示。你可能还需要比较不同时间点的数据和超出阈值能发送警告。一个新的开源工具EurekaJ,就此应运而生。

图9:激活方法分析时必需的BTrace脚本

 

posted on 2011-11-24 11:08 顺其自然EVO 阅读(423) 评论(0)  编辑  收藏


只有注册用户登录后才能发表评论。


网站导航:
 
<2011年11月>
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

导航

统计

常用链接

留言簿(54)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜