虚拟机GG修改器游戏不在列表_虚拟机怎么用gg修改器

作者：佚名来源：网友日期:2024-11-18 01:24:02

GG修改器破解版下载地址：https://ghb2023zs.bj.bcebos.com/d/z/p/d/dbzs.apk?GGXGQ

大家好，今天小编为大家分享关于虚拟机GG修改器游戏不在列表_虚拟机怎么用gg修改器的内容，赶快来一起来看看吧。

正文

理论总是作为指导实践的工具,能把这些知识应用到实际工作中才是我们的最终目的。

给一个系统定位问题的时候,知识、经验是关键基础,数据是依据,工具是运用知识处理数据的手段。这里说的数据包括:运行日志、异常堆栈、GC日志、线程快照( threaddump/javacore文件)、堆转储快照(heapdump/hprof文件)等。经常使用适当的虚拟机监控和分析的工具可以加快我们分析数据、定位解决问题的速度,但在学习工具前,也应当意识到工具永远都是知识技能的一层包装,没有什么工具是“秘密武器”,不可能学会了就能包治百病。

JDK的命令行工具

Java开发人员肯定都知道JDK的bin目录中有“java.exe”、“javac.exe”这两个命令行工具, 但并非所有程序员都了解过JDK的bin目录之中其他命令行程序的作用。每逢JDK更新版本之时 ,bin 目录下命令行工具的数量和功能总会不知不觉地增加和增强。bin 目录的内容如图4-1 所示。

这些故障处理工具被Sun公司作为“礼物”附赠给JDK的使用者,并在软件的使用说明中把它们声明为“没有技术支持并且是实验性质的”(unsupported and experimental ) 产品,但事实上 ,这些工具都非常稳定而且功能强大,能在处理应用程序性能问题、定位故障时发挥很大的作用。

说起JDK的工具,,可能会注意到这些工具的程序体积都异常小巧。假如以前没注意到 ,现在不妨再看看图4-1中的最后一列“ 大小”,几乎所有工具的体积基本上都稳定在27KB左右。并非JDK开发团队刻意把它们制作得如此精炼来炫耀编程水平,而是因为这些命令行工具大多数是jdk/lib/tools.jar类库的一层薄包装而已,它们主要的功能代码是在tools类库中实现的。读者把图4-1和图4-2两张图片对比一下就可以看得很清楚。

假如使用的是Linux版本的JDK , 还会发现这些工具中很多甚至就是由Shell脚本直接写成的,可以用vim直接打开它们。

JDK开发团队选择采用Java代码来实现这些监控工具是有特别用意的:当应用程序部署到生产环境后,无论是直接接触物理服务器还是远程Telnet到服务器上都可能会受到限制。借助tools.jar类库里面的接口,我们可以直接在应用程序中实现功能强大的监控分析功能。

jps : 虚拟机进程状况工具

JDK的很多小工具的名字都参考了UNIX命令的命名方式,jps ( JVM Process Status Tool ) 是其中的典型。除了名字像UNIX的ps命令之外,它的功能也和ps命令类似:可以列出正在运行的虚拟机进程,并显示虛拟机执行主类(Mam Class,main ( ) 函数所在的类)名称以及这些进程的本地虛拟机唯一ID ( Local Virtual Machine Identifier,LVMID ) 。虽然功能比较单一 ,但它是使用频率最高的JDK命令行工具,因为其他的JDK工具大多需要输入它查询到的LVMID来确定要监控的是哪一个虚拟机进程。对于本地虚拟机进程来说,LVMID与操作系统的进程ID ( Process Identifier,PID ) 是一致的,使用Windows的任务管理器或者UNIX的ps命令也可以查询到虚拟机进程的LVMID , 但如果同时启动了多个虚拟机进程,无法根据进程名称定位时,那就只能依赖jps命令显示主类的功能才能区分了。

jsp命令格式:

jps[options][hostid]

jps执行样例:

D :DevelopJavajdkl.6.0_21in>jps -l
2338 D :DevelopglassfisEin..modulesadmin-cli.jar
.sun.enterprise.glassfish.bootstrap.ASMain
3788 sun.tools.jps.Jps

jps可以通过RMI协议查询开启了RMI服务的远程虚拟机进程状态,hostid为RMI注册表中注册的主机名。jps的其他常用选项见表4-2。

注：tools.jar中的类库不属于Java的标准API,如果引入这个类库,就意味着用户的程序只能运行于Sun Hotspot ( 或一些从Sun公司购买了JDK的源码License的虚拟机,如IBM J9、 BEA JRockit)上面,或者在部署程序时需要一起部署tools.jar。

jstat :虚拟机统计信息监视工具

jstat( JVM Statistics Monitoring Tool )是用于监视虚拟机各种运行状态信息的命令行工具。它可以显示本地或者远程虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据 ,在没有GUI图形界面,只提供了纯文本控制台环境的服务器上,它将是运行期定位虚拟机性能问题的首选工具。

jstat命令格式为:

jstat[option vmid[interval[s|ms][count]]]

对于命令格式中的VMID与LVMID需要特别说明一下:如果是本地虚拟机进程,VMID与 LVMID是一致的,如果是远程虚拟机进程,那VMID的格式应当是:

[protocol:][//]lvmid[@hostname[:port]/servername]

参数interval和count代表查询间隔和次数,如果省略这两个参数,说明只查询一次。假设需要每250毫秒查询一次进程2764垃圾收集状况,一共查询20次,那命令应当是:

jstat -gc 2764 250 20

选项option代表着用户希望查询的虚拟机信息,主要分为3类 :类装载、垃圾收集、运行期编译状况,具体选项及作用请参考表4-3中的描述。

jstat监视选项众多，这里仅举监视一台刚刚启动的 GlassFish v3服务器的内存状况的例子来演示如何查看监视结果。监视参数与输出结果如代码清单4-1所示。

D:DevelopJavajdkl.6.0_21in> jstat -gcutil 2764
S0 S1 E 0 P YGC YGCT FGC FGCT GCT
0.00 0.00 6.20 41.42 47.20 16 0.105 3 0.472 0.577

查询结果表明:这台服务器的新生代Eden区( E ,表示Eden)使用了6.2%的空间,两个 Survivor区(S0、S1 , 表示Survivor0、 Survivor1) 里面都是空的,老年代( O , 表示Old )和永久代( P , 表示Permanent) 则分别使用了41.42%和47.20%的空间。程序运行以来共发生 Minor GC(YGC,表示Young GC)16次,总耗时0.105秒,发生Full GC(FGC,表示Full GC)3次,Full GC总耗时(FGCT,表示Full GC Time)为0.472秒,所有GC总耗时(GCT , 表示GC Time )为0.577秒。

使用jstat工具在纯文本状态下监视虚拟机状态的变化,确实不如后面将会提到的 VisualVM等可视化的监视工具直接以图表展现那样直观。但许多服务器管理员都习惯了在文本控制台中工作,直接在控制台中使用jstat命令依然是一种常用的监控方式。

jinfo : Java配置信息工具

jinfo ( Configuration Info for Java ) 的作用是实时地查看和调整虚拟机各项参数。使用jps命令的-v参数可以查看虚拟机启动时显式指定的参数列表,但如果想知道未被显式指定的参数的系统默认值,除了去找资料外,就只能使用jinfo的-flag选项进行查询了(如果只限于 JDK 1.6或以上版本的话,使用java-XX : +PrintFlagsFinal查看参数默认值也是一个很好的选择 ),jinfo还可以使用-sysprops选项把虚拟机进程的System.getProperties() 的内容打印出来。这个命令在JDK 1.5时期已经随着Linux版的JDK发布 ,当时只提供了信息查询的功能 ,JDK 1.6之后,jinfo在Windows和Linux平台都有提供,并且加入了运行期修改参数的能力 ,可以使用-flag[+|-jname或者-flag name=value修改一部分运行期可写的虚拟机参数值。 JDK 1.6中,jinfo对手Windows平台功能仍然有较大限制,只提供了最基本的-flag选项。

jinfo命令格式:

jinfo[option]pid

执行样例:查询CMSInitiatingOccupancyFraction参数值。

C:>jinfo -flag CMSInitiatingOccupancyFraction 1444
-XX :CMSInitiatingOccupancyFraction=85

jmap : Java内存映像工具

jmap ( Memory Map for Java ) 命令用于生成堆转储快照(一般称为heapdump或dump文件 )。如果不使用jmap命令,要想获取Java堆转储快照,还有一些比较“暴力”的手段:譬如-XX : +HeapDumpOnOutOfMemoryError参数,可以让虚拟机在OOM异常出现之后自动生成dump文件,通过-XX : +HeapDumpOnCtrlBreak参数则可以使用[Ctrl]+[Break] 键让虚拟机生成dump文件 ,又或者在Linux系统下通过Kill -3命令发送进程退出信号“吓唬”下虚拟机,也能拿到dump文件。

jmap的作用并不仅仅是为了获取dump文件,它还可以查询finalize执行队列、Java堆和永久代的详细信息,如空间使用率、当前用的是哪种收集器等。

和jinfo命令一样,jmap有不少功能在Windows平台下都是受限的,除了生成dump文件的-dump选项和用于查看每个类的实例、空间占用统计的-histo选项在所有操作系统都提供之外 ,其余选项都只能在Linux/Solaris下使用。

jmap命令格式:

jmap[option]vmid

option 选项的合法值与具体含义见表4-4。

代码清单4-2是使用jmap生成一个正在运行的Eclipse的dump快照文件的例子,例子中的3500是通过jps命令查询到的LVMID。

代码清单4-2 使用jmap生成dump文件

C:UsersIcyFenix>jmap-dump:format=b,file=eclipse.bin 3500
Dumping heap to C :UsersIcyFenixeclipse.bin.
Heap dump file created

jhat :虚拟机堆转储快照分析工具

Sun JDK提供jhat(JVM Heap Analysis Tool)命令与jmap搭配使用,来分析jmap生成的堆转储快照。jhat内置了一个微型的HTTP/HTML服务器 ,生成dump文件的分析结果后,可以在浏览器中查看。不过实事求是地说,在实际工作中,除非笔者手上真的没有别的工具可用, 否则一般都不会去直接使用jhat命令来分析dump文件 ,主要原因有二:一是一般不会在部署应用程序的服务器上直接分析dump文件 ,即使可以这样做,也会尽量将dump文件复制到其他机器上进行分析,因为分析工作是一个耗时而且消耗硬件资源的过程,既然都要在其他机器进行,就没有必要受到命令行工具的限制了;另一个原因是jhat的分析功能相对来说比较简陋,后文将会介绍到的VisualVM , 以及专业用于分析dump文件的Eclipse Memory Analyzer、 IBM HeapAnalyzer等工具,都能实现比jhat更强大更专业的分析功能。代码清单4-3演示了使用jhat分析4.2.4节中采用jmap生成的Eclipse IDE的内存快照文件。

代码清单4-3 使用jhat分析dump文件

C:UsersIcyFenix>jhat eclipse.bin
Reading from eclipse.bin.
Dump file created Fri Nov 19 22 :07 :21 CST 2010 Snapshot read,resolving.
Resolving 1225951 objects.
Chasing references,expect 245 dots…… Eliminating duplicate references
Snapshot resolved.
Started HTTP server on port 7000
Server is ready.

屏幕显不“Server is ready.”的提示后,用户在浏览器中键入http://localhost:7000/就可以看到分析结果,如图4-3所示。

分析结果默认是以包为单位进行分组显示,分析内存泄漏问题主要会使用到其中的“Heap Histogram” (与jmap-histo功能一样)与OQL页签的功能,前者可以找到内存中总容量最大的对象,后者是标准的对象查询语言,使用类似SQL的语法对内存中的对象进行查询统计。

jstack : Java堆栈跟踪工具

jstack(Stack Trace for Java)命令用于生成虚拟机当前时刻的线程快照(一般称为 threaddump或者javacore文件 )。线程快照就是当前虚拟机内每一条线程正在执行的方法堆栈的集合 ,生成线程快照的主要目的是定位线程出现长时间停顿的原因,如线程间死锁、死循环、请求外部资源导致的长时间等待等都是导致线程长时间停顿的常见原因。线程出现停顿的时候通过jstack来查看各个线程的调用堆栈,就可以知道没有响应的线程到底在后台做些什么事情,或者等待着什么资源。

jstack命令格式:

jstack [option] vmid

option选项的合法值与具体含义见表4-5。

代码清单4-4是使用jstack查看Eclipse线程堆栈的例子,例子中的3500是通过jps命令查询到的LVMID。

代码清单4 – 4 使用jstack查看线程堆栈(部分结果)

在JDK 1.5中 ,java.lang.Thread类新增了一个getAllStackTraces()用于获取虚拟机中所有线程的StackTraceElement对象。使用这个方法可以通过简单的几行代码就完成jstack的大部分功能,在实际项目中不妨调用这个方法做个管理员页面,可以随时使用浏览器来查看线程堆栈,如代码清单4-5所示,这是笔者的一个小经验。

代码清单4 – 5 查看线程状况的JSP页面

<%@ page import=”java.util.Map”%>
<html>
<head>
<title>服务器线程信息</title>
</head>
<body>
<pre>
<%
for (Map.Entry<Thread, StackTraceElement[]> stackTrace : Thread.getAllStackTraces().entrySet()) {
Thread thread = (Thread) stackTrace.getKey();
StackTraceElement[] stack = (StackTraceElement[]) stackTrace.getValue();
if (thread.equals(Thread.currentThread())) {
continue;
}
out.print(”
线程：” + thread.getName() + ”
“);
for (StackTraceElement element : stack) {
out.print(” “+element+”
“);
}
}
%>
</pre>
</body>
</html>

HSDIS : JIT生成代码反汇编

在Java虚拟机规范中,详细描述了虚拟机指令集中每条指令的执行过程、执行前后对操作数栈、局部变量表的影响等细节。这些细节描述与Sun的早期虚拟机( Sun Classic VM)高度吻合 ,但随着技术的发展,高性能虚拟机真正的细节实现方式已经渐渐与虚拟机规范所描述的内容产生了越来越大的差距,虚拟机规范中的描述逐渐成了虚拟机实现的“概念模型”— 即实现只能保证规范描述等效。基于这个原因,我们分析程序的执行语义问题(虚拟机做了什么)时 ,在字节码层面上分析完全可行,但分析程序的执行行为问题(虚拟机是怎样做的、性能如何)时 ,在字节码层面上分析就没有什么意义了,需要通过其他方式解决。

分析程序如何执行,通过软件调试工具(GDB、Windbg等 )来断点调试是最常见的手段 ,但是这样的调试方式在Java虚拟机中会遇到很大困难,因为大量执行代码是通过JIT编译器动态生成到CodeBuffer中的 ,没有很简单的手段来处理这种混合模式的调试(不过相信虚拟机开发团队内部肯定是有内部工具的)。因此,不得不通过一些特别的手段来解决问题, 基于这种背景,本节的主角——HSDIS插件就正式登场了。

HSDIS是一个Sun官方推荐的HotSpot虚拟机JIT编译代码的反汇编插件,它包含在HotSpot虚拟机的源码之中,但没有提供编译后的程序。在Project Kerni的网站也可以下载到单独的源码。它的作用是让HotSpot的-XX : +PrintAssembly指令调用它来把动态生成的本地代码还原为汇编代码输出,同时还生成了大量非常有价值的注释,这样我们就可以通过输出的代码来分析问题。读者可以根据自己的操作系统和CPU类型从Project Kenai的网站上下载编译好的插件,直接放到JDK_HOME/jre/bin/client和JDK_HOME/jre/bin/server目录中即可。如果没有找到所需操作系统(譬如Windows的就没有 )的成品 ,那就得自己使用源码编译一下。

还需要注意的是,如果读者使用的是Debug或者FastDebug版的HotSpot ,那可以直接通过-XX : +PrintAssembly指令使用插件;如果使用的是Product版的HotSpot , 那还要额外加入一个-XX : +UnlockDiagnosticVMOptions参数。笔者以代码清单4-6中的简单测试代码为例演示一下这个插件的使用。

代码清单4 – 6 测试代码

public class Bar {
int a = 1;
static int b = 2;
public int sum(int c) {
return a + b + c;
}
public static void main(String[] args) {
new Bar().sum(3);
}
}

编译这段代码,并使用以下命令执行。

java -XX:+PrintAssembly -Xcomp -XX:CompileCommand=dontinline,*Bar.sum -XX:pileonly,*Bar.sum test.Bar

其中 ,参数-Xcomp是让虚拟机以编译模式执行代码,这样代码可以“偷懒”,不需要执行足够次数来预热就能触发JIT编译。两个-XX : CompileCommand意思是让编译器不要内联sum()并且只编译sum() , -XX : +PrintAssembly就是输出反汇编内容。如果一也顺利的话 ,那么屏幕上会出现类似下面代码清单4-7所示的内容。

代码清单4 – 7 测试代码

JDK的可视化工具

JDK中除了提供大量的命令行工具外 ,还有两个功能强大的可视化工具:JConsole和VisualVM ,这两个工具是JDK的正式成员,没有被贴上“unsupported and experimental”的标签。

其中JConsole是在JDK 1.5时期就已经提供的虚拟机监控工具,而VisualVM在JDK 1.6 Update7中才首次发布,现在已经成为Sun ( Oracle ) 主力推动的多合一故障处理工具,并且已经从JDK中分离出来成为可以独立发展的开源项目。

JConsole : Java监视与管理控制台

JConsole ( Java Monitoring and Management Console ) 是—种基于JMX的可视化监视管理工具。它管理部分的功能是针对JMX MBean进行管理,由于MBean可以使用代码、中间件服务器的管理控制台或者所有符合JMX规范的软件进行访问,所以本节将会着重介绍JConsole监视部分的功能。

1.启动JConsole

如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java高级交流：787707172，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。

通过JDK/bin目录下的“jconsole.exe”启动JConsole后 ,将自动搜索出本机运行的所有虚拟机进程,不需要用户自己再使用jps来查询了,如图4-4所示。双击选择其中一个进程即可开始监控,也可以使用下面的“远程进程”功能来连接远程服务器,对远程虚拟机进行监控。

从图4-4可以看出,笔者的机器现在运行了Eclipse、 JConsole和MonitoringTest三个本地虚拟机进程,其中MonitoringTest就是笔者准备的“反齒教材”代码之一。双击它进入JConsole主界面 ,可以看到主界面里共包括“概述”、“内存”、“线程”、“类”、“VM摘要”、“MBean”,6个页签 ,如图4-5所示。

“概述”页签显示的是整个虚拟机主要运行数据的概览,其中包括“堆内存使用情况”、“线程”、“类”、“CPU使用情况”4种信息的曲线图,这些曲线图是后面“内存” 、“线程”、 ‘类”页签的信息汇总,具体内容将在后面介绍。

2.内存监控

“内存”页签相当于可视化的jstat命令,用于监视受收集器管理的虚拟机内存(Java堆和永久代)的变化趋势。我们通过运行代码清单4-8中的代码来体验一下它的监视功能。运行时设置的虚拟机参数为:-Xms100m-Xmx100m-XX : +UseSerialGC ,这段代码的作用是以 64KB/50毫秒的速度往Java堆中填充数据,一共填充1000次 ,使用JConsole的“内存”页签进行监视 ,观察曲线和柱状指示图的变化。

代码清单4-8 JConsole监视代码

/**
* 内存占位符对象，一个OOMObject大约占64K
*/
static class OOMObject {
public byte[] placeholder = new byte[64 * 1024];
}
public static void fillHeap(int num) throws InterruptedException {
List<OOMObject> list = new ArrayList<OOMObject>();
for (int i = 0; i < num; i++) {
// 稍作延时，令监视曲线的变化更加明显
Thread.sleep(50);
list.add(new OOMObject());
}
System.gc();
}
public static void main(String[] args) throws Exception {
fillHeap(1000);
}

程序运行后,在“内存”页签中可以看到内存池Eden区的运行趋势呈现折线状,如图4-6所示。而监视范围扩大至整个堆后,会发现曲线是一条向上增长的平滑曲线。并且从柱状图可以看出,在1000次循环执行结束,运行了 System.gc()后 ,虽然整个新生代Eden和Survivor区都基本被清空了,但是代表老年代的柱状图仍然保持峰值状态,说明被填充进堆中的数据在System.gc()方法执行之后仍然存活。笔者的分析到此为止,现提两个小问题供读者思考一下,答案稍后给出。

1)虚拟机启动参数只限制了Java堆为100MB, 没有指定-Xmn参数,能否从监控图中估计出新生代有多大?
2)为何执行了System.gc()之后,图4-6中代表老年代的柱状图仍然显示峰值状态,代码需要如何调整才能让System.gc()回收掉填充到堆中的对象?

问题1答案:图4-6显示Eden空间为27328KB,因为没有设置-XX : SurvivorRadio参数, 所以Eden与Survivor空间比例为默认值8:1 ,整个新生代空间大约为27 328KBx125%=34160KB.

问题2答案:执行完System.gc()之后,空间未能回收是因为List<OOMObject> list对象仍然存活,fillHeap()方法仍然没有退出,因此list对象在System.gc()执行时仍然处于作用域之内。如果把System.gc()移动到fillHeap()方法外调用就可以回收掉全部内存。

3.线程监控

如果上面的“ 内存”页签相当于可视化的jstat命令的话,“线程”页签的功能相当于可视化的jstack命令 ,遇到线程停顿时可以使用这个页签进行监控分析。前面讲解jstack命令的时候提到过线程长时间停顿的主要原因主要有:等待外部资源(数据库连接、网络资源、设备资源等)、死循环、锁等待(活锁和死锁)。通过代码清单4-9分别演示一下这几种情况。

代码清单4-9 线程等待演示代码

/**
* 线程死循环演示
*/
public static void createBusyThread() {
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
while (true) // 第41行
;
}
}, “testBusyThread”);
thread.start();
}
/**
* 线程锁等待演示
*/
public static void createLockThread(final Object lock) {
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
synchronized (lock) {
try {
lock.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}, “testLockThread”);
thread.start();
}
public static void main(String[] args) throws Exception {
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
br.readLine();
createBusyThread();
br.readLine();
Object obj = new Object();
createLockThread(obj);
}

程序运行后 ,首先在“ 线程”页签中选择main线程,如图4-7所示。堆栈追踪显示BufferedReader在readBytes方法中等待System.in的键盘输入 ,这时线程为Runnable状态 ,Runnable状态的线程会被分配运行时间,但readBytes方法检查到流没有更新时会立刻归还执行令牌,这种等待只消耗很小的CPU资源。

接着监控testBusyThread线程,如图4-8所示,testBusyThread线程一直在执行空循环,从堆栈追踪中看到一直在MonitoringTest.java代码的41行停留, 41行为:while(true)。这时候线程为Runnable状态,而且没有归还线程执行令牌的动作,会在空循环上用尽全部执行时间直到线程切换,这种等待会消耗较多的CPU资源。

图4-9显示testLockThread线程在等待着lock对象的notify或notifyAll方法的出现,线程这时候处于WAITING状态 ,在被唤醒前不会被分配执行时间。

testLockThread线程正在处于正常的活锁等待,只要lock对象的notify()或notifyAll()方法被调用,这个线程便能激活以继续执行。代码清单4-10演示了一个无法再被激活的死锁等待。

代码清单4-10死锁代码样例

/**
* 线程死锁等待演示
*/
static class SynAddRunalbe implements Runnable {
int a, b;
public SynAddRunalbe(int a, int b) {
this.a = a;
this.b = b;
}
@Override
public void run() {
synchronized (Integer.valueOf(a)) {
synchronized (Integer.valueOf(b)) {
System.out.println(a + b);
}
}
}
}
public static void main(String[] args) {
for (int i = 0; i < 100; i++) {
new Thread(new SynAddRunalbe(1, 2)).start();
new Thread(new SynAddRunalbe(2, 1)).start();
}
}

这段代码开了200个线程去分别计算1+2以及2+1的值 ,其实for循环是可省略的,两个线程也可能会导致死锁,不过那样概率太小,需要尝试运行很多次才能看到效果。一般的话, 带for循环的版本最多运行2〜3次就会遇到线程死锁,程序无法结束。造成死锁的原因是 Integer.valueOf() 方法基于减少对象创建次数和节省内存的考虑, [-128 , 127]之间的数字会被缓存’当valueOf()方法传入参数在这个范围之内,将直接返回缓存中的对象。也就是说,代码中调用了200次Interger.valueOf()方法一共就只返回了两个不同的对象。假如在某个线程的两个synchronized块之间发生了一次线程切换,那就会出现线程A等着被线程B持有的Integer.valueOf(1) , 线程B又等着被线程A持有的Integer.valueOf(2) ,结果出现大家都跑不下去的情景。

出现线程死锁之后,点击JConsole线程面板的“检测到死锁”按钮 ,将出现一个新的“死锁”页签,如图4-10所示。

图4-10中很清晰地显示了线程Thread-43在等待一个被线程Thread-12持有Integer对象 ,而点击线程Thread-12则显示它也在等待一个Integer对象,被线程Thread-43持有,这样两个线程就互相卡住,都不存在等到锁释放的希望了。

VisualVM :多合一故障处理工具

VisualVM(All-in-One Java Troubleshooting Tool)是到目前为止随JDK发布的功能最强大的运行监视和故障处理程序,并且可以预见在未来一段时间内都是官方主力发展的虚拟机故障处理工具。官方在VisualVM的软件说明中写上了“All-in-One” 的描述字样,预示着它除了运行监视、故障处理外,还提供了很多其他方面的功能。如性能分析(Profiling),VisualVM的性能分析功能甚至比起JProfiler、YourKit等专业且收费的Profiling工具都不会逊色多少,而且VisualVM的还有一个很大的优点:不需要被监视的程序基于特殊

Agent运行,因此它对应用程序的实际性能的影响很小,使得它可以直接应用在生产环境中。这个优点是JProfiler、YourKit等工具无法与之媲美的。

1.VisualVM兼容范围与插件安装

VisualVM基于NetBeans平台开发,因此它一开始就具备了插件扩展功能的特性,通过插件扩展支持,VisualVM可以做到:

显示虚拟机进程以及进程的配置、环境信息(jps、 jinfo)。
监视应用程序的CPU、GC、堆、方法区以及线程的信息(jstat、jstack)。
dump以及分析堆转储快照(jmap、jhat)。
方法级的程序运行性能分析,找出被调用最多、运行时间最长的方法。
离线程序快照:收集程序的运行时配置、线程dump、内存dump等信息建立个快照, 可以将快照发送开发者处进行Bug反馈。
其他plugins的无限的可能性……

VisualVM在JDK 1.6 update 7中才首次出现,但并不意味着它只能监控运行于JDK 1.6上的程序,它具备很强的向下兼容能力,甚至能向下兼容至近10年前发布的JDK 1.4.2平台,这对无数已经处于实施、维护的项目很有意义。当然,并非所有功能都能完美地向下兼容, 主要特性的兼容性见表4-6。

不过手工安装并不常用 ,使用VisualVM的自动安装功能已每可以找到大多数所需的插件,在有网络连接的环境下,点击“工具插件菜单”,弹出如图4-11所示的插件页签,在页签的“可用插件”中列举了当前版本VisualVM可以使用的插件 ,选中插件后在右边窗口将显示这个插件的基本信息,如开发者、版本、功能描述等。

大家可以根据自己的工作需要和兴趣选择合适的插件,然后点击安装按钮,弹出如图4-12所示的下载进度窗口,跟着提示操作即可完成安装。

安装完插件,选择一个需要监视的程序就进入程序的主界面了,如图4-13所示。根据读者选择安装插件数量的不同,看到的页签可能和图4-13中的有所不同。

VisualVM中“概述”、“监视”、“线程”、“ MBeans”的功能与前面介绍的JConsole差别不大 ,读者根据上文内容类比使用即可,下面挑选几个特色功能、插件进行介绍。

2.生成、浏览堆转储快照

在VisualVM中生成dump文件有两种方式,可以执行下列任一操作:

在“应用程序”窗口中右键单击应用程序节点,然后选择“堆Dump”。
在“应用程序”窗口中双击应用程序节点以打开应用程序标签,然后在“监视”标签中单击“堆Dump”。

生成了dump文件之后,应用程序页签将在该堆的应用程序下增加一个以[heapdump]开头的子节点,并且在主页签中打开了该转储快照,如图4-14所示。如果需要把dump文件保存或发送出去,要在heapdump节点上右键选择“另存为”菜单 ,否则当VisualVM关闭时，生成的dump文件会被当做临时文件删除掉。要打开一个已经存在的dump文件 ,通过文件菜单中的“装入”功能 ,选择硬盘上的dump文件即可。

从堆页签中的“摘要”面板可以看到应用程序dump时的运行时参数、

System.getProperties()的内容、线程堆栈等信息,“类”面板则是以类为统计口径统计类的实例数量、容量信息,“实例”面板不能直接使用,因为不能确定用户想查看哪个类的实例,所以需要通过“类”面板进入,在“类”中选择一个关心的类后双击鼠标,即可在“实例”里面看见此类中500个实例的具体属性信息。“OQL控制台”面板中就是运行OQL查询语句的,同jhat中介绍的OQL功能一样。

3.分析程序性能

在Profiler页签中 ,VisualVM提供了程序运行期间方法级的CPU执行时间分析以及内存分析 ,做Profiling分析肯定会对程序运行性能有比较大的影响,所以一般不在生产环境中使用这项功能。

要开始分析,先选择“CPU’和“ 内存”按钮中的一个,然后切换到应用程序中对程序进行操作 ,VisualVM会记录到这段时间中应用程序执行过的方法。如果是CPU分析 ,将会统计每个方法的执行次数、执行耗时;如果是内存分析,则会统计每个方法关联的对象数以及这些对象所占的空间。分析结束后,点击“停止”按钮结束监控过程,如图4-15所示。

注意在JDK 1.5之后,在Client模式下的虚拟机加入并且自动开启了类共享——这是一个在多虚拟机进程中共享rt.jar中类数据以提高加载速度和节省内存的优化,而根据相关Bug报告的反映,VisualVM的Profiler功能可能会因为类共享而导致被监视的应用程序崩溃,所以读者进行Profiling前 ,最好在被监视程序中使用-Xshare : off参数来关闭类共享优化。

图4-15中是对Eclipse IDE—段操作的录制和分析结果,读者分析自己的应用程序时,可以根据实际业务的复杂程度与方法的时间、调用次数做比较,找到最有优化价值的方法。

4.BTrace动态日志跟踪

BTrace是一个很“有趣”的VisualVM插件 ,本身也是可以独立运行的程序。它的作用是在不停止目标程序运行的前提下,通过HotSpot虚拟机的HotSwap技术动态加入原本并不存在的调试代码。这项功能对实际生产中的程序很有意义:经常遇到程序出现问题,但排查错误的一些必要信息,譬如方法参数、返回值等,在开发时并没有打印到日志之中,以至于不得不停掉服务,通过调试增量来加入日志代码以解决问题。当遇到生产环境服务无法随便停止时 ,缺一两句日志导致排错进行不下去是一件非常郁闷的事情。

在VisualVM中安装了BTrace插件后 ,在应用程序面板中右键点击要调试的程序,会出现“Trace Application……”菜单,点击将进入BTrace面板。这个面板里面看起来就像一个简单的Java程序开发环境,里面还有一小段Java代码 ,如图4-16所示。

准备了一段很简单的Java代码来演示BTrace的功能:产生两个1000以内的随机整数 ,输出这两个数字相加的结果,如代码清单4-11所示。

public class BTraceTest {
public int add(int a, int b) {
return a + b;
}
public static void main(String[] args) throws IOException {
BTraceTest test = new BTraceTest();
BufferedReader reader = new BufferedReader(new InputStreamReader(System.in));
for (int i = 0; i < 10; i++) {
reader.readLine();
int a = (int) Math.round(Math.random() * 1000);
int b = (int) Math.round(Math.random() * 1000);
System.out.println(test.add(a, b));
}
}
}

程序运行后,在VisualVM中打开该程序的监视,在BTrace页签填充TracingScript的内容 ,输入的调试代码如代码清单4-12所示。

代码清单4-12 BTrace调试代码

/* BTrace Script Template */
.sun.btrace.annotations.*;
import .sun.btrace.BTraceUtils.*;
@BTrace
public class TracingScript {
@OnMethod(
clazz=”org.fenixsoft.monitoring.BTraceTest”,
method=”add”,
location=@Location(Kind.RETURN)
)
public static void func(@Self org.fenixsoft.monitoring.BTraceTest instance,int a,int b,@Return int result) {
println(“调用堆栈:”);
jstack();
println(strcat(“方法参数A:”,str(a)));
println(strcat(“方法参数B:”,str(b)));
println(strcat(“方法结果:”,str(result)));
}
}