JDK 5.0, 代号老虎，在以往的Java传统上加入了许多新的设计，给Java语言带来了一些较大的变化，比如泛型，元数据，可变个数参数，静态导入类，新线程架构，自动装箱/拆箱等等新的以往没有的新特性。同时，在调试程序和解决性能各种问题方面，JDK5.0同样加入了多个分析工具来让开发者更加方便地调试他们自己的程序，它们包括了命令行调试工具，图形界面调试工具等等.
JDK5.0包括的调试工具：
我们在这里对JDK5.0的调试工具做大致的概念性的介绍，然后希望通过介绍我自己在实际工作中使用这些工具解决问题的实例来让大家对这些工具有更深入的了解。
JDK5.0里面加入了jstack, jconsole, jinfo, jmap, jdb, jstat, jps, 下面对这些工具做简单介绍：
- jstack -- 如果java程序崩溃生成core文件，jstack工具可以用来获得core文件的java stack和native stack的信息，从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。另外，jstack工具还可以附属到正在运行的java程序中，看到当时运行的java程序的java stack和native stack的信息, 如果现在运行的java程序呈现hung的状态，jstack是非常有用的。目前只有在Solaris和Linux的JDK版本里面才有。
- jconsole – jconsole是基于Java Management Extensions (JMX)的实时图形化监测工具，这个工具利用了内建到JVM里面的JMX指令来提供实时的性能和资源的监控，包括了Java程序的内存使用，Heap size, 线程的状态，类的分配状态和空间使用等等。
- jinfo – jinfo可以从core文件里面知道崩溃的Java应用程序的配置信息，目前只有在Solaris和Linux的JDK版本里面才有。
- jmap – jmap 可以从core文件或进程中获得内存的具体匹配情况，包括Heap size, Perm size等等，目前只有在Solaris和Linux的JDK版本里面才有。< /li>
- jdb – jdb 用来对core文件和正在运行的Java进程进行实时地调试，里面包含了丰富的命令帮助您进行调试，它的功能和Sun studio里面所带的dbx非常相似，但 jdb是专门用来针对Java应用程序的。
- jstat – jstat利用了JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控，包括了对Heap size和垃圾回收状况的监控等等。
- jps – jps是用来查看JVM里面所有进程的具体状态, 包括进程ID，进程启动的路径等等。
另外，还有些其他附带的工具在这里没有列出，比如Heap Analysis Tool, kill -3 方法等等，这些在JDK5.0之前就有，同样也是非常有用的性能调优工具，大家可以参照相应的文档资料来学习，在文章后面也会推荐一些相应的文档给大家作为参考。
好，说了这么多，让我们来看看JDK5.0自带的这些工具在现实工作能给我们带来什么帮助，下面是我和ISV一起共同工作的实际例子，在这里把它们简单阐述出来，希望对大家有所帮助。
jconsole和jstack使用实例：
在做过的项目中，曾经有几个是使用jstack和jconsole来解决问题的。在下面的例子中，由于部分代码涉及到公司名字，我使用了xxx来代替。
1. 其中的一个是Web2.0的客户，由于目前Sun Microsystem公司推出的Niagara服务器系列非常适合网络方面的多线程应用，并且已经在业界非常出名，所以他们决定使用T2000服务器来测试一下如果应用到他们自己的应用是否能够获得出众的性能。
整个应用的架构如下：
Apache 2.0.59 + Resin EE 2.1.17 + Jdk 1.5.0.07 + Oracle 9
运行的操作系统:
Solaris 10 Update 3 (11/06), EIS patches包.
测试工具：
Apache benchmark tool.
在客户的测试环境中，我们分别做了Apache, Resin, Solaris的相应调整，其中包括了Apache使用Prefork模式，并且调整了httpd.conf文件里面相应的ServerLimit, ListenBacklog,Maxclient等等值，Resin服务器调整Jvm heap size, 并行回收new generation和old generation, 最大线程数，oracle连接数等等参数，Solaris操作系统做了网络和系统的相应调整，最终把整套系统搬进了生产环境，一切顺利进行，但当进入其中的一个论坛系统时却发现系统响应时间非常缓慢，用Apache Benchmark Tool加少量压力得到结果如下，由于是在生产环境下所以不敢使用大的压力：
Benchmarking free.xxx.com (be patient).....done
Server Software: Resin/2.1.17
Server Hostname: free.xxx.com
Server Port: 8080
Document Path: /forum/bbsMessageList.act?bbsThreadId=1580107
Document Length: 27012 bytes
Concurrency Level: 10
Time taken for tests: 92.148883 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Keep-Alive requests: 0
Total transferred: 2722500 bytes
HTML transferred: 2701200 bytes
Requests per second: 1.09 [#/sec] (mean)
Time per request: 9214.888 [ms] (mean)
Time per request: 921.489 [ms] (mean, across all concurrent requests)
Transfer rate: 28.84 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 9089 9187 139.4 9140 9789
Waiting: 3067 3163 138.3 3117 3766
Total: 9089 9187 139.4 9140 9789
Percentage of the requests served within a certain time (ms)
50% 9140
66% 9178
75% 9189
80% 9201
90% 9281
95% 9560
98% 9739
99% 9789
100% 9789 (longest request)
每一个请求的响应时间大概去到8-9秒时间，这个是客户所不能接受的。
这时我们决定采用JDK5.0自带的jstack来进行trouble-shoot,首先重新做加压测试，并行请求为10个，总共100个请求，这时对Resin服务器所起的Java进程间隔10秒用jstack做一次采集工作。为什么要间隔10秒？主要是想看看在这三十秒内Java进程是否都阻塞在同一个地方。结果如下：
大部分的线程都阻塞在同一个java stack上面:
Thread
t@38: (state = BLOCKED)
- java.lang.Object.wait(long) @bci=0 (Interpreted frame)
- java.lang.Object.wait(long) @bci=0 (Interpreted frame)
- com._xxx.vportal.common.rpc.session.RemoteServiceGroupFactory.getMaxBalanceFactoryEntry() @bci=165,
line=180 (Interpreted frame)
- com._xxx.vportal.common.rpc.session.RemoteServiceGroupFactory.getService() @bci=80, line=195 (Interpreted
frame)
- com._xxx.vportal.common.rpc.session.RemoteServiceFactory.getSynSender() @bci=1, line=331 (Interpreted
frame)
- com._xxx.vportal.common.rpc.session.RemoteServiceSupport.synRequestHardTask(java.lang.String,
java.lang.Object) @bci=6, line=35 (Interpreted frame)
- com._xxx.vportal.amus.user.client.UserClientRpcImpl.getIconSigner(int, int) @bci=36, line=90 (Interpreted frame)
- net._xxx.forum.model.user.UserInfo.getLogoPath() @bci=109, line=546 (Interpreted frame)
- sun.reflect.GeneratedMethodAccessor13.invoke(java.lang.Object, java.lang.Object[]) @bci=36 (Interpreted frame)
- sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, java.lang.Object[]) @bci=6, line=25
(Compiled frame)
- org.apache.velocity.runtime.parser.node.ASTReference.execute(java.lang.Object,
org.apache.velocity.context.InternalContextAdapter) @bci=40, line=207 (Compiled frame)
- org.apache.velocity.runtime.parser.node.ASTBlock.render(org.apache.velocity.context.InternalContextAdapter,
java.io.Writer) @bci=18, line=94 (Compiled frame)
- org.apache.velocity.runtime.parser.node.SimpleNode.render(org.apache.velocity.context.InternalContextAdapter,
java.io.Writer) @bci=18, line=271 (Interpreted frame)
-
org.apache.velocity.runtime.parser.node.ASTIfStatement.render(org.apache.velocity.context.InternalContextAdapter,
java.io.Writer) @bci=63, line=128 (Interpreted frame)
- org.apache.velocity.runtime.parser.node.ASTBlock.render(org.apache.velocity.context.InternalContextAdapter,
java.io.Writer) @bci=18, line=94 (Compiled frame)
- org.apache.velocity.runtime.directive.Foreach.render(org.apache.velocity.context.InternalContextAdapter,
java.io.Writer, org.apache.velocity.runtime.parser.node.Node) @bci=95, line=344 (Interpreted frame)
- org.apache.velocity.runtime.parser.node.ASTDirective.render(org.apache.velocity.context.InternalContextAdapter,
java.io.Writer) @bci=14, line=153 (Interpreted frame)
- org.apache.velocity.runtime.parser.node.SimpleNode.render(org.apache.velocity.context.InternalContextAdapter,
java.io.Writer) @bci=18, line=271 (Interpreted frame)
- org.apache.velocity.app.Velocity.evaluate(org.apache.velocity.context.Context, java.io.Writer, java.lang.String,
java.io.Reader) @bci=102, line=359 (Interpreted frame)
- org.apache.velocity.app.Velocity.evaluate(org.apache.velocity.context.Context, java.io.Writer,
java.lang.String, java.lang.String) @bci=18, line=253 (Interpreted frame)
- net._xxx.forum.util.velocity.VelocityUtil.getVelocityEvaluate(java.util.Map, java.io.Writer,
java.lang.String) @bci=14, line=35 (Interpreted frame)
- net._xxx.forum.action.forum.BbsMessageListAction.go() @bci=1284, line=268 (Interpreted
frame)
–
net._xxx.forum.action.AbstractAction.execute() @bci=1, line=39 (
–
..............
和应用的开发人员交流后，发现这些有问题的程序，都是和论坛系统中Socket调用有关，当用户打开一个页面是，页面中的用户信息需要同过Socket的方式调用相册那边的数据，这个操作存在bug，经过用户的重新同步更新程序，问题解决。
解决后的实测的数据如下, 效果非常理想：
Benchmarking free.xxx.com (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Finished 50000 requests
Server Software: Apache/2.0.59
Server Hostname: free.xxx.com
Server Port: 80
Document Path: /forum/bbsMessageList.act?bbsThreadId=1581280
Document Length: 27508 bytes
Concurrency Level: 30
Time taken for tests: 252.583749 seconds
Complete requests: 50000
Failed requests: 0
Write errors: 0
Total transferred: 1384158363 bytes
HTML transferred: 1375408188 bytes
Requests per second: 197.95 [#/sec] (mean)
Time per request: 151.550 [ms] (mean)
Time per request: 5.052 [ms] (mean, across all concurrent requests)
Transfer rate: 5351.56 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.4 0 11
Processing: 45 150 154.1 117 4349
Waiting: 41 145 153.7 112 4346
Total: 45 150 154.1 117 4349
Percentage of the requests served within a certain time (ms)
50% 117
66% 142
75% 163
80% 180
90% 241
95% 321
98% 478
99% 764
100% 4349 (longest re
2. 另外的一个是最近做的，我们有个教育行业方面的ISV上来实验室做T2000的Benchmark实验，我们花了一天的时间部署整个架构，包括安装Solaris操作系统，应用服务器，数据库。& amp; amp; lt; /div>
整个应用的架构如下：
Tomcat + Jdk 1.5 + Oracle 10g
运行的操作系统:
Solaris 10 Update 3 (11/06), EIS patches包.
测试工具：
LoadRunner 8.1
在实验的初段，Tomcat, Oracle 10g服务器都是架设在T2000上，我们在对T2000服务器的OS，网络，应用服务器做了必要的调整后，发现其表现还是不尽如人意。& #160;
我们使用Loadrunner做测试，用户上到了100个同时并发10个迭代时已经出现问题,有许多的请求都被阻塞住，不能正常地进行。
这时我们决定使用jconsole和jstack来看看系统出现了什么问题。
A. 首先我们需要在Tomcat的启动脚本catalina.sh里面加入JVM选项：
Dcom.sun.management.jmxremote
把tomcat服务器java进程置于JDK5.0的性能监控范围之内。
B. 然后我们用jconsole连接到tomcat服务器的java进程，发现基本上Heap size, 垃圾回收都比较正常，但发现tomcat服务器的大部分线程有问题，都处于被Block的状态。
观察每条线程的stack trace, 发现它们基本上都被堵塞在uk.org.primrose.pool.core.Pool.put和uk.org.primrose.pool.core.Pool.get()的SyncHack同步机制上，我们尝试了改大数据连接池的大小，发现结果是一样的。
C.这个结论在jstack的结果中同样得到了验证，使用jstack连接到tomcat服务器java进程，并观察结果。
D. 最后我们决定用tomcat服务器的连接池配置来代替Primrose数据库连接池，更改以后，发现结果比较理想。
E. 后来，我们把Oracle数据库建立在另外的一台服务器X4200上，而Tomcat应用服务器依然放在T2000上，使用千兆网络交换机，同样地，使用Tomcat服务器自己的连接池配置表现较为理想。
以上两个是我对JDK5.0工具的一些实际操作的例子，在这里和大家分享一下，希望对大家有所帮助。而Sun Microsystem公司也在不断地完善JDK，在新的JDK版本里面加入越来越多的实用的方便开发者开发和调试的新特性，比如在最新的JDK6.0里面就内嵌了Dtrace里面许多关于Java程序中内存，方法，线程等等新的探针，通过这些探针和Dtrace,我们可以更加方便地调试Java程序。
文档资料：