深入理解JVM二(拓展篇)： 虚拟机性能监控与调优

一、JDK的命令行工具

• jps(jvm Process Status) : 虚拟机进程状况工具，列出正在运行的虚拟机进程，并显示执行主类名及唯一ID(LVMID)

jps [options] [hostid
-q 只输出ID，省略主类的名称
-m 输出虚拟机进程启动时传递给主类main()函数的参数
-l 输出主类的全名，如果是jar包，输出Jar路径
-v 输出JVM启动时JVM参数

• jstat(JVM Statistics Monitoring Tool) : 虚拟机统计信息监视工具,用于监视虚拟机各种运行状态信息的命令行工具。可以显示本地或者远程虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据，在没有GUI图形界面的服务器上，将是运行期定位虚拟机性能问题的首选工具。
  jstat [ option vmid [interval [s | ms] [count] ] ]
• jinfo(Configureation Info for Java): Java配置信息工具，实时查看和调整虚拟机各项参数
  jinfor [option] pid
• jmap(Memory Map for Java)Java内存映像工具，用于生成堆转储快照。
  jmap [option] vmid
• jhat(JVM Heap Analysis Tool)虚拟机堆转储快照分析工具，与jmap搭配使用，来分析jmap生成的堆转储快照。jhat内置了一个微型的HTTP服务器，生成dump文件的分析结果可以在浏览器中查看。
• jstatck(Stack Trace for Java)Java堆栈跟踪工具，用于生成虚拟机当前时刻的线程快照。就是当前虚拟机内每一条线程正在执行的方法堆栈的集合，目的是定位线程出现长时间停顿的原因，如死锁、死循环等。
• HSDIS : JTI生成代码反汇编，就是将java源码生成汇编码

二、JDK的可视化工具

JConsole, VisualVM这两个工具是JDK的正式成员，没有贴上"unsupported and experimental"标签

2.1 JConsole ：Java监视与管理控制台

• 启动JConsole： jconsole.exe
• 内存监控
• 线程监控

2.2 VisualVm:多合一故障处理工具

官方助主力发展

• 启动： jvisualvm
• 通过插件支持
• 显示虚拟机进程以及进程的配置（jps、jinfo）
• 监视应用程序的CPU,GC、堆、方法区以及线程的信息(jstat、jstack)
• dump以及分析堆转储快照(jmap、jhat)
• 方法级的程序运行性能分析，找出被调用最多、运行时间最长的方法。

三、调优案例与实战

3.1 高性能硬件上的程序部署策略

一个15万pv/天左右的在线文档类型网站最近更换了硬件系统，新的硬件为4个CPU、16GB物理内存，操作系统为64为CentOS 5.4。整个服务器暂时没有部署别的应用，所有硬件资源都可以提供给这个网站。管理员为了尽量利用硬件资源选用了64位的JDK1.5，并通过-Xmx和-Xms参数将Java堆规定在12GB，使用一段时间口发现使用效果并不理想，网站经常不定期出现长时间失去响应的情况。
监控服务器运行状况后发现网站失去响应是由GC停顿导致的，虚拟机运行在Server模式，默认使用吞吐量优先收集器，回收12GB的堆，一次Full GC的停顿时间高达14秒。由于程序设计的关系，访问文档要把文档从磁盘提取到内存中，导致内存中出现很多由文档序列化产生的大对象，这些大对象进入了老年代，没有在Minor GC中清理掉。
高性能硬件部署程序，两种方式：

通过64位JDK来使用大内存

需要将Full GC频率控制得极低，比如深夜一次
64位JDK产生的问题：

• 内存回收导致长时间停顿
• 现阶段，64位JDK的性能测试结果普遍低于32位JDK
• 需要保证程序足够稳定，因为这种应用要是产生溢出几乎无法产生堆转储快照(因为要产生十几GB乃至更大的Dump文件)
• 相同程序在64位JDK消耗的内存比一般32位JDK大，这是由于指针膨胀，以及数据类型对齐补白等因素导致的。

使用若干个32位虚拟机简历逻辑集群来利用硬件资源

具体做法是在一台物理机上启动多个应用服务进程，每个服务进程分配不同的端口，然后再全端搭建一个负载均衡器，以反向代理的方式来分配访问请求。当然，很少有没有缺点的方案

• 尽量避免节点竞争全局资源，最典型的就是磁盘竞争，各个节点如果同时访问某个磁盘文件，容易导致IO异常
• 很难高效率地利用某些资源池，比如连接池，一般都是在各个节点建立自己独立的链接池
• 各个节点仍然受到32位内存限制，在32位Windows平台每个进程只能使用2GB内存，堆一般只能开到1.5GB。在UNITX系统（Solaris）中，可以提升到3GB乃至4GB的内存(2^32).

回到案例中，最后的部署方案调整为建立5个32位JDK的逻辑集群，每个进程按2GB内存计算，占用了10GB内存。另外建立一个Apache服务作为前段均衡代理访问门户。考虑到用户对响应速度一脚关心，主要压力集中在磁盘和内存访问，CPU资源敏感度比较低，因此改为CMS收集器进行垃圾回收。