Monitor JVM with Different Tools

最新推荐文章于 2023-07-20 01:16:17 发布

Ant

最新推荐文章于 2023-07-20 01:16:17 发布

阅读量1.7k

点赞数

分类专栏： Web 文章标签： jvm tools aix sun ibm weblogic

本文链接：https://blog.csdn.net/ant_ren/article/details/5490485

版权

Web 专栏收录该内容

57 篇文章 1 订阅

订阅专栏

Monitor JVM with Different Tools

貌似用Java开发到一定程度，就会产生某些疑惑，先知道得更深入一点，于是就研究了一些JVM的结构，读官方的JVM Specification记得是相当吃力的，尝试着翻译或者给别人讲解，然后再否定自己的不足。最近比较了一下各种JVM的调试工具，随便写点笔记吧。

首先要明确的是行业中用到的虚拟机主要有四种(其实也是四种JDK)：

l Sun JVM

l HPUX JVM

l IBM AIX JVM

l BEA Jrockit JVM

由于Oracle收购了Sun和BEA，所以估计常驻于Weblogic里的Jrockit以后不会再存在多久了，逐渐会被新生代的Sun JVM缩代替的。（反正除了Weblogic，也很少有个体团队会用它）

由于不同种类的JVM都有自己特别的地方，所以调试它们的工具也就彼此不能互相兼容，要有针对性的选择。JVM的不同之处稍微提一下好了，最大的区别主要是来自IBM AIX的JVM，内部的结构划分与Sun 和HPUX的有很大区别：

自5.0之后Sun与HPUX的JVM都会把整个堆内存划分成年轻代和年老代，基本的回收策略是年轻代优先存放对象，塞满了之后会触发局部GC，这个时候尽量保持没有关联的工作线程仍然能够响应请求工作，经历了局部GC还没挂掉的对象就会被扔到年老代去，当年老代也被塞满的时候，就会触发Full GC，这个时候所有的线程都必须挂起，程序无法响应用户请求。这种策略的缺点是如果程序总是创建一些小而生命周期短的对象，这些对象在完成工作之后在局部GC就被回收，那么很可能空间较大的年老代区域总是保持空闲未被使用过。（默认年轻代和年老代的空间大小比例是1:3）

所以IBM AIX的JVM就开始走另外一个策略，不去划分对象区域，而是在同一个皮带轮上分配内存，直到皮带轮塞满了才进行回收，所以往往发生的每次GC都是Full GC，所有线程必须挂起，但是充分利用的全部堆内存空间，这样发生GC的频率也会小一些。这样有个缺点：由于分配对象的尺寸大小不一，大家紧贴在一起，中间某些给回收了，那块区域就成了碎片，类似硬盘碎片一样。这样就需要从全局进行压缩碎片重新排列堆内存空间的对象，否则会出现碎片空闲空间很多，但找不到一块连续的足够大的内存空间导致分配失败，而一旦分配失败就会导致Full GC出现。Anyway，压缩碎片虽然比不上Full GC那么笨重，但也是很影响性能的。听说新的IBM JVM也开始尝试结合Sun JVM的优点，合理的去划分区域，不过本质上不存在完美的策略。

罗嗦得有点多了，该介绍Monitor JVM的工具了，对于HPUX和IBM AIX，因为通常不会有图形界面，主机和OS基本都是绑定在一起卖的，所以Monitor工具都是由官方推出的简单实用版本：

HPUX上用的是HPJMeter，下载地址如下：

https://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPJMETER

IBM AIX上用的主要是HeapAnalyzer，下载地址如下：

http://www.alphaworks.ibm.com/tech/heapanalyzer/download

它们的特点是都已JAR方式运行，界面基本是Java AWT开发的，当HPUX或者AIX上的JVM崩溃了，或者人为的去生成javacore和HeapDump文件的时候，这个文件就可以被import到这两个工具中，然后经过分析format之后，在GUI中就可以看到大量的JVM内部运行信息，相当于是取自某一时刻的快照，包括当时堆内存状态、对象列表、线程列表、Class Load记录、GC的记录等等。

接下来是Sun JVM，由于在Windows和Linux中用得比较多，而Sun也作为Java的发源地，所以Sun官方也一直在不断加强对JVM的调试监控工具，它们都被集成到了JDK安装目录的bin目录下，从早期的jconsole到如今的jVisualVM，可以说是越做越好。Jconsole.exe运行出来也是Java AWT的风格，集成了基本的线程、对象、内存分配之类的分析，而VisualVM.exe则是笔者强烈推荐的简单强大的最好的JVM分析监控工具，启动之后会自动搜索正在运行的JVM，也可以通过JMX规范建立Remote Connection，它应该是用SWT开发的界面，会根据用户的界面风格有不同的展现。然后像Eclipse一样，拥有一个开源社区不断的提供新的插件随时下载安装来扩充功能。不管是Class/Instance的跟踪监控，还是Thread/Heap的Dump信息生成和分析，都非常详细、易用、可配置、可扩展。