一步步优化JVM五：优化延迟或者响应时间（1） -
- ITeye技术网站
博客分类：
本节的目标是做一些优化以满足对应用对延迟的需求。这次需要几个步骤，包括完善Java堆大小的配置，评估垃圾回收占用的时间和频率，也许还要尝试切换到不同的垃圾回收器，以及由于使用了不同的垃圾回收器，需要重新优化Java堆空间大小。
这一步有如下可能的结果：
1、应用的延迟需求被满足了。如果这一步的优化操作满足了应用的延迟需求，你可以继续下一步优化（优化吞吐量）。
2、应用的延迟需求未被满足。如果这一步的优化操作未能满足延迟需求，你可能需要重新看看延迟需求是否合理或者修改应用程序。一些可能的问题可以帮助改善应用的延迟问题：
a、优化Java堆以及修改应用以减少对象的分配和对象的长时间存活。
b、修改JVM的部署结构，让每一个JVM做更少的工作。
上面的两个步骤都可以减少JVM的对象分配，因此减少垃圾回收的频率。
这一步从查看垃圾回收对应用的延迟的影响开始，基于前面一节“决定内存消耗”计算出来的Java堆大小。
下面列出了评估垃圾回收对延迟的影响需要进行的几个事情：
1、测量MinorGC的时间。
2、测量MinorGC的频率。
3、测量FullGC的时间。
4、测量FullGC的频率。
测量垃圾回收的时间的和频率对于改善Java堆大小配置来说是非常重要的。MinorGC的时间和频率的测量结果可以用来改善young代的空间大小。测量最坏情况下FullGC的时间和频率可以用来决定old代的大小，以及是否需要切换成吞吐量垃圾回收器（通过使用-XX:+UseParalleOldGC或者-XX:+UseParallelGC）或者并发垃圾回收器（CMS，通过使用-XX:+UseConcMarkSweepGC）。在使用吞吐量垃圾回收器的时候，如果垃圾回收的延迟和频率太高以导致应用的延迟需求无法满足的时候才切换到CMS，如果选择了切换，需要对CMS垃圾回收器进行优化，后面会详细介绍这个问题。
接下来详细介绍前面提到的各种情况。
下面列举了几个这一步优化操作需求，它们来源于应用的系统需求：
1、可以接收的平均暂停时间。平均暂停时间需求用于和MinorGC消耗的时间比较。
2、可以接收的MinorGC的频率。其实频道对于应用负责人来说，没有平均延迟时间重要。
3、应用负责人能够接受的最大延迟时间。这个时间受到FullGC的影响。
4、应用负责人能够接收的最大延迟的频率，即FullGC的频率。其实，大多数时间应用管理员还是更加关心应用的的最大延迟时间超过了最大延迟的频率。
一旦确定了需求，这些垃圾回收器的时间消耗和频率都可以通过垃圾回收日志收集到。先把垃圾回收器设置为吞吐量垃圾回收器（设置-XX:+UseParallelOldeGC或者-XX:+UseParallelGC）。通过反复测试，可以让young代和old代满足上面的要求。下面2节介绍如何优化young代和old代空间大小来观察MinorGC和最坏情况的FullGC的消耗时间和频率。
改善young代的大小
确定young代的大小是通过评估垃圾回收的统计信息以及观察MinorGC的消耗时间和频率，下面举例说明如何通过垃圾回收的统计信息来确定young代的大小。
尽管MinorGC消耗的时间和young代里面的存活的对象数量有直接关系，但是一般情况下，更小young代空间，更短的MinorGC时间。如果不考虑MinorGC的时间消耗，减少young代的大小会导致MinorGC变得更加频繁，由于更小的空间，用玩空间会用更少的时间。同理，提高young代的大小会降低MinorGC的频率。
当测试垃圾回收数据的时候，发现MinorGC的时间太长了，正确的做法就是减少young代的空间大小。如果MinorGC太频繁了就增加young代的空间大小。
上图是一个展示了MinorGC的例子，这个例子是运行在如下的HotSpot VM命令参数下的。
-Xms6144m -Xmx6144m -Xmn2048m -XX:PermSize=96m -XX:MaxPermSize=96m -XX:+UserParallelOldGC
上图显示了MinorGC平均的消耗时间是0.05秒，平均的频率是2.147秒1次。当计算MinorGC的消耗时间和频率的时候，越多的数据参与计算，准确性会越高。并且应用要处于稳定运行状态下来收集MinorGC信息也是非常重要的。
下一步是比较MinorGC的平均时间和系统对延迟的要求，如果MinorGC的平均时间大于了系统的要求，减少young代的空间大小，然后继续测试，再收集数据以及重新评估。
如果MinorGC的频率大于了系统的要求，就增加young代的空间大小，然后继续测试，再收集以及重新评估。
也许需要数次重复才能够让系统达到延迟要求。当你改变young代的空间大小的时候，尽量保持old代的空间大小不要改变。
从上图的垃圾回收信息来看，如果应用的延迟要求是40毫秒的话，观察到的MinorGC的延迟是58毫秒，比系统的要求高出了不少。上面例子使用的命令选项是
-Xms6144m -Xmx6144m -Xmn2048m -XX:PermSize=96m -XX:MaxPermSize=96m -XX:+UserParallelOldGC
意味着old代的空间大小是4096M，减小young代的空间大小的10%而且要保持old代的空间大小不变，可以使用如下选项。
-Xms5940m -Xmx5940m -Xmn1844m -XX:PermSize=96 -XX:MaxPermSize=96 -XX:+UserParallelOldGC
注意的是young代的空间大小从2048M减少到1844M，整个Java堆的大小从6144M减少到5940M，两者都是减少了204m。
无论是young的空间调大还是调小，都需要重新收集垃圾回收信息和重新计算MinorGC的平均时间和频率，以达到应用的延迟要求，可能需要几个轮回来达到这个要求。
为了说明了增加young代的大小以降低MinorGC的频率，我们下面举一个例子。如果系统要求的频率是5秒一次，这个上面的例子中是2.147秒一次，也就是说它用了2.147秒，填充满了2048M空间，如果需要5秒一次的频率，那么就需要5/2.147倍的空间，即.147等于4700M。因此young代的空间需要调整到4700M。下面是一个示例来说明配置这个：
-Xms8796m -Xmx8796m -Xmn4700m -XX:PermSize=96m -XX:MaxPermSize=96m -XX:+UsePrallelOldGC
注意是-Xms和-Xmx也同步调整了。
另外一些调整young代的空间需要注意的事项：
1、old代的空间一定不能小于活动对象的大小的1.5倍。
2、young代的空间至少要有Java堆大小的10%，太小的Java空间会导致过于频繁的MinorGC。
3、当提高Java堆大小的时候，不要超过JVM可以使用的物理内存大小。如果使用过多的物理内存，会导致使用交换区，这个会严重影响性能。
如果在仅仅是MinorGC导致了延迟的情况下，你无法通过调整young代的空间来满足系统的需求，那么你需要重 新修改应用程序、修改JVM部署模型把应用部署到多个JVM上面（通常得要多机器了）或者重新评估系统的需求。
如果通过调整MinorGC能够满足应用的延迟需求，接下来就可以调整old代了，以达到最坏情况下的延迟和延迟频率的需求。下一节详细说明这个问题。
完善old代的大小
这一节的目标是评估由于FullGC引起的最差暂停时间和频率。
同前面一个节“完善young代大小”一样，垃圾回收的统计信息是必须的，在稳定状态下，FullGC的时间表明了应用最差的延迟，如果发生了多个FullGC，计算多个FullGC的平均消耗时间，更多数据能够更好的评估。
计算两次不同的FullGC之间的时间差，可以提供出FullGC的频率，下图用一个列子来说明两个FullGC：
如果没有FullGC，可以人为的去干预，前面说过，可以使用VisualVM来触发FullGC。另外，评估FullGC的频率需要知道对象的转移率，这个转移率说明对象从young代转移到old代。接下来的介绍如何评估转移率。
接下有个几个MinorGC的例子，他们被用来评估FullGC的频率。
T14:40:29.564-0800: [GC
[PSYoungGen: 2045989K-&97152K)]
3634533K-&91456K), 0.0543798 secs]
[Times: user=0.38 sys=0.01, real=0.05 secs]
T14:40:31.949-0800: [GC
[PSYoungGen: 2047896K-&97152K)]
3655319K-&91456K), 0.0539614 secs]
[Times: user=0.35 sys=0.01, real=0.05 secs]
T14:40:34.346-0800 [GC
[PSYoungGen: 2045889K-&97152K)]
3677202K-&91456K), 0.0532377 secs]
[Times: user=0.39 sys=0.01, real=0.05 secs]
T14:40:36.815-0800 [GC
[PSYoungGen: 2047094K-&97152K)]
3696985K-&91456K), 0.0543332 secs]
[Times: user=0.37 sys=0.01, real=0.05 secs]
从上面的例子可以看出：
1、Java堆的大小是6291456K或6144M
2、young代的大小是2097152K或2048M
3、old代的大小是M = 4096M
在这个例子中，活动对象的大小差不多是1370M。那么old代还有2726M剩余空间（M=2726M）。
填充完成2736M空间需要多长时间是由young代向old代的转移率决定的。这个转移率的计算通过查看每次MinorGC后old代的占用空间的增长情况以及MinorGC发生的时间。old代的空间占用是MinorGC之后Java堆中对象大小减去young代的大小，通过这个公式计算，可以看出在这个例子中每次MinorGC之后，old代的空间占用情况是：
1588635K，第一个MinorGC
1611428K，第二次MinorGC
1632106K，第三次MinorGC
1653117K，第四次MinorGC
每次的增量分别是
22793K，第一次和第二次的增量
20678K，第二次和第三次的增量
21011K，第三次和第四次的增量
平均每次MinorGC转移大概201494K或者叫21M。
如果剩余的空间都是按照设个转移率来转移到old代的话，且知道MinorGC的频率是每2.147秒一次。因此，这个转移率是.147s差不多10M/s,那么一共的空间是2736M空间需要273.6s差不多4.5分钟一次。
因此，通过前面的案例分析，应用的最差延迟的频率是4.5分钟。这个评估可以通过让应用处于稳定运行状态超过4.5分钟来验证。
如果评估和观察的FullGC的频率高于了应用对最坏延迟频率的要求，那么可以提高old代的空间大小。如果改变old代的大小，保持young代的空间恒定，在优化young代的时候也说这个问题，两者应该独立优化，以保证有高效。
如果这步已经达到了你最坏延迟的要求，那么这一步调优延迟就算已经完成了，就可以进入下一步去调优“吞吐量”了。
如果你未能达到了应用对最坏延迟时间和频率的性能要求，由于FullGC的执行时间太长了，然后你可以把垃圾回收器切换CMS（concurrent garbage collection）。CMS有能力让垃圾回收尽量是多线程的，即让程序保持在运行状态。要使用CMS可以通过下面这条命令选项:-XX:+UseConcMarkSweepGC。
后面详细说明如何调优CMS。
同步发布CSDN：
论坛回复 /
(3 / 2921)
浏览: 15888 次
来自: 杭州
你好，这篇文章是你翻译的吗？有原文地址吗？谢谢！
ganlv 写道mercyblitz 写道koujun 写道推 ...
mercyblitz 写道koujun 写道推荐下：jetty ...
Servlet就是一个线程不安全的，一个Web（JVM）服务器 ...
koujun 写道推荐下：jettyWeb服务器中依赖的是HT ...JVM调优总结：调优方法
14:35 和你在一起 和你在一起的博客&字号：&|&
下面文章将讲解JVM的调优工具以及如何去调优等等问题，还有一些异常问题的处理。详细请看下文。
JVM调优工具
Jconsole，jProfile，VisualVM
Jconsole：jdk自带，功能简单，但是可以在系统有一定负荷的情况下使用。对垃圾回收算法有很详细的跟踪。详细说明参考这里
JProfiler：商业软件，需要付费。功能强大。详细说明参考这里
VisualVM：JDK自带，功能强大，与JProfiler类似。推荐。
观察内存释放情况、集合类检查、对象树
上面这些调优工具都提供了强大的功能，但是总的来说一般分为以下几类功能
堆信息查看
可查看堆空间大小分配（年轻代、年老代、持久代分配）
提供即时的垃圾回收功能
垃圾监控（长时间监控回收情况）
查看堆内类、对象信息查看：数量、类型等
对象引用情况查看
有了堆信息查看方面的功能，我们一般可以顺利解决以下问题：
--年老代年轻代大小划分是否合理
--内存泄漏
--垃圾回收算法设置是否合理
线程信息监控：系统线程数量
线程状态监控：各个线程都处在什么样的状态下
Dump线程详细信息：查看线程内部运行情况
CPU热点：检查系统哪些方法占用的大量CPU时间
内存热点：检查哪些对象在系统中数量最大（一定时间内存活对象和销毁对象一起统计）
这两个东西对于系统优化很有帮助。我们可以根据找到的热点，有针对性的进行系统的瓶颈查找和进行系统优化，而不是漫无目的的进行所有代码的优化。
快照是系统运行到某一时刻的一个定格。在我们进行调优的时候，不可能用眼睛去跟踪所有系统变化，依赖快照功能，我们就可以进行系统两个不同运行时刻，对象（或类、线程等）的不同，以便快速找到问题
举例说，我要检查系统进行垃圾回收以后，是否还有该收回的对象被遗漏下来的了。那么，我可以在进行垃圾回收前后，分别进行一次堆情况的快照，然后对比两次快照的对象情况。
内存泄漏检查
内存泄漏是比较常见的问题，而且解决方法也比较通用，这里可以重点说一下，而线程、热点方面的问题则是具体问题具体分析了。
内存泄漏一般可以理解为系统资源（各方面的资源，堆、栈、线程等）在错误使用的情况下，导致使用完毕的资源无法回收（或没有回收），从而导致新的资源分配请求无法完成，引起系统错误。
内存泄漏对系统危害比较大，因为他可以直接导致系统的崩溃。
需要区别一下，内存泄漏和系统超负荷两者是有区别的，虽然可能导致的最终结果是一样的。内存泄漏是用完的资源没有回收引起错误，而系统超负荷则是系统确实没有那么多资源可以分配了（其他的资源都在使用）。
年老代堆空间被占满
异常：java.lang.OutOfMemoryError: Java heap space
这是最典型的内存泄漏方式，简单说就是所有堆空间都被无法回收的垃圾对象占满，虚拟机无法再在分配新空间。
如上图所示，这是非常典型的内存泄漏的垃圾回收情况图。所有峰值部分都是一次垃圾回收点，所有谷底部分表示是一次垃圾回收后剩余的内存。连接所有谷底的点，可以发现一条由底到高的线，这说明，随时间的推移，系统的堆空间被不断占满，最终会占满整个堆空间。因此可以初步认为系统内部可能有内存泄漏。（上面的图仅供示例，在实际情况下收集数据的时间需要更长，比如几个小时或者几天）
这种方式解决起来也比较容易，一般就是根据垃圾回收前后情况对比，同时根据对象引用情况（常见的集合对象引用）分析，基本都可以找到泄漏点。
持久代被占满
异常：java.lang.OutOfMemoryError: PermGen space
Perm空间被占满。无法为新的class分配存储空间而引发的异常。这个异常以前是没有的，但是在Java反射大量使用的今天这个异常比较常见了。主要原因就是大量动态反射生成的类不断被加载，最终导致Perm区被占满。
更可怕的是，不同的classLoader即便使用了相同的类，但是都会对其进行加载，相当于同一个东西，如果有N个classLoader那么他将会被加载N次。因此，某些情况下，这个问题基本视为无解。当然，存在大量classLoader和大量反射类的情况其实也不多。
1. -XX:MaxPermSize=16m
2. 换用JDK。比如JRocket。
异常：java.lang.StackOverflowError
说明：这个就不多说了，一般就是递归没返回，或者循环调用造成
线程堆栈满
异常：Fatal: Stack size too small
说明：java中一个线程的空间大小是有限制的。JDK5.0以后这个值是1M。与这个线程相关的数据将会保存在其中。但是当线程空间满了以后，将会出现上面异常。
解决：增加线程栈大小。-Xss2m。但这个配置无法解决根本问题，还要看代码部分是否有造成泄漏的部分。
系统内存被占满
异常：java.lang.OutOfMemoryError: unable to create new native thread
这个异常是由于操作系统没有足够的资源来产生这个线程造成的。系统创建线程时，除了要在Java堆中分配内存外，操作系统本身也需要分配资源来创建线程。因此，当线程数量大到一定程度以后，堆中或许还有空间，但是操作系统分配不出资源来了，就出现这个异常了。
分配给Java虚拟机的内存愈多，系统剩余的资源就越少，因此，当系统内存固定时，分配给Java虚拟机的内存越多，那么，系统总共能够产生的线程也就越少，两者成反比的关系。同时，可以通过修改-Xss来减少分配给单个线程的空间，也可以增加系统总共内生产的线程数。
1. 重新设计系统减少线程数量。
2. 线程数量不能减少的情况下，通过-Xss减小单个线程大小。以便能生产更多的线程。
原文链接：
阅读(...) 评论()出处：http://coderbee.net 最近有两个系统先后被恶意扫描，出现 CPU 使用率高的现象。很好，把问题暴露出来解决掉。
CPU 使用率很高，首先是要找出 CPU 在执行什么样的代码，然后在分析这些代码有什么问题。
一、问题定位
用命令 “ps aux | grep APP” 找出应用的进程 id：
8 28.8 2100 pts/2 Sl
11:19 /usr/jdk1.6.0_38/bin/java APP
找出耗CPU的线程，在Linux系统下用命令：
”， pid 就是前面找出来的应用进程 ID 。这个命令会显示出当前占用CPU高的线程。
Tasks: 426 total,
0 running, 426 sleeping,
0 stopped,
0.0%ni, 72.3%id, 26.6%wa,
3924912k total,
3308088k used,
616824k free,
768k buffers
8388600k total,
3236720k used,
5151880k free,
12304k cached
SHR S %CPU %MEM
84784 appdeplo
0 g 3816 S
0:00.85 java
84903 appdeplo
0 g 3816 S
0:34.66 java
84983 appdeplo
0 g 3816 S
0:00.99 java
85091 appdeplo
0 g 3816 S
0:02.69 java
85164 appdeplo
0 g 3816 S
0:04.92 java
84703 appdeplo
0 g 3816 S
0:00.00 java
84704 appdeplo
0 g 3816 S
0:00.42 java
84705 appdeplo
0 g 3816 S
0:02.52 java
84706 appdeplo
0 g 3816 S
0:02.64 java
84707 appdeplo
0 g 3816 S
0:02.46 java
84708 appdeplo
0 g 3816 S
0:02.39 java
84709 appdeplo
0 g 3816 S
0:33.99 java
这里的 PID 比如
84784 是十进制的，需要转换为十六进制，用windows的计算器就可以转换了，转换为十六进制是：
dump 出进程的所有线程栈，用命令
“./jstack -F -m -l 84703 & 84703.stack”，
84703 是 pid。
dump出的其中一个线程栈大概是这样的：
&container-332& prio=10 tid=0xfa800 nid=0x13c7a runnable [0xec8000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
- locked &0x2728& (a java.io.BufferedInputStream)
at java.io.DataInputStream.readInt(DataInputStream.java:370)
at com.ibm.mq.MQInternalCommunications.timedReadInt(MQInternalCommunications.java:2748)
at com.ibm.mq.MQInternalCommunications.receiveBytesFaster(MQInternalCommunications.java:2846)
- locked &0x24e0& (a com.ibm.mq.MQv6InternalCommunications)
at com.ibm.mq.MQInternalCommunications.receive(MQInternalCommunications.java:1179)
- locked &0x24e0& (a com.ibm.mq.MQv6InternalCommunications)
at com.ibm.mq.MQSESSIONClient.lowLevelComms(MQSESSIONClient.java:2841)
- locked &0x2e10& (a java.lang.Integer)
at com.ibm.mq.MQSESSIONClient.MQGET(MQSESSIONClient.java:1852)
at com.ibm.mq.MQQueue.getMsg2Int(MQQueue.java:1217)
- locked &0xc4c738& (a com.ibm.mq.MQSPIQueue)
at com.ibm.mq.MQQueue.getMsg2(MQQueue.java:1074)
- locked &0xc4c738& (a com.ibm.mq.MQSPIQueue)
at com.ibm.mq.jms.MQMessageConsumer.getMessage(MQMessageConsumer.java:3451)
at com.ibm.mq.jms.MQMessageConsumer.receiveInternal(MQMessageConsumer.java:2866)
at com.ibm.mq.jms.MQMessageConsumer.receive(MQMessageConsumer.java:2669)
at com.ibm.mq.connector.outbound.MessageConsumerWrapper.receive(MessageConsumerWrapper.java:180)
at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveMessage(AbstractPollingMessageListenerContainer.java:429)
at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:310)
at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:263)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1058)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1050)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:947)
at java.lang.Thread.run(Thread.java:662)
第一行的 nid 就是前面转换出来的十六进制数字，所有线程都有这样的对应线程栈。线程dump文件是文本文件，直接用文本编辑器查看就可以了。从上面的线程栈，我们就可以看到占用cpu高的线程在做什么。
二、问题分析
这两个问题虽然原因不同，但都可以通过上面的方法找到问题代码。
复杂正则导致 CPU 使用率高
从当时 dump 出来的线程栈来看，CPU 一直在执行正则匹配。
以前一直以为正则匹配是很高效的，其实不是。Java 的正则匹配采用的贪婪模式，也就是对每个模式，采用尽可能匹配最多个字符，当匹配不成功时，再回退，这样可能导致匹配的复杂度跟字符串的长度成阶乘的关系，可以看看这篇
随便写了个上百个字符的字符串去测试我们的正则，发现几个钟都没匹配完，汗！
HashMap 在并发访问下导致 CPU 使用率高
HashMap 是非线程安全的，在并发访问的情况下就可能出现死循环，这个死循环的分析网上很多了。Spring 的缓存模块（spring-modules-cache-0.7.jar）用它作为缓存，在平时并发访问度不高，没有问题，被恶意扫描时，就触发了死循环，可以看这个bug 报告
相关 [jvm cpu 问题] 推荐：
- 码蜂笔记
最近有两个系统先后被恶意扫描，出现 CPU 使用率高的现象. CPU 使用率很高，首先是要找出 CPU 在执行什么样的代码，然后在分析这些代码有什么问题. 1、
用命令 “ps aux | grep APP” 找出应用的进程 id：. 2、
找出耗CPU的线程，在Linux系统下用命令：
”， pid 就是前面找出来的应用进程 ID.
- Java - 编程语言 - ITeye博客
使用tomcat做为java容器，cpu占用偏高的原因，目前公司服务器上面跑的ubuntu环境nginx+tomcat+mysql运行一段时间之后java进程cpu偏高，会出现网站打不开的情况. 一，首先查看tomcat日志，如果有出现OOM错误（内存溢出）可以对应的加大jvm的内存大小. 1，修改tomcat目录下bin目录下的catalina.sh文件,在.
- 五四陈科学院-坚信科学，分享技术
以下内容由 [五四陈科学院]提供. 如果遇到线上java进程占用过多的cpu，可以用这个脚本来帮助你快速找到代码的问题. 先用top或者是jps定位占用cpu过多的java进程的pid是多少. 然后执行如下过程即可得到结论：. *centos系统下测试通过. 想快点找到作者也可以到Twitter上留言:
- 四火的唠叨
文章系本人原创，转载请保持完整性并注明出自
《四火的唠叨》. JDB是基于文本和命令行的调试工具，Jikes在JDB的基础上提供了GUI. 熟悉JDB还是有价值的，很多情况下需要我们在命令行下完成简单的debug问题定位. 我们可能更熟悉使用下面这样的方式来进行调试，但本质上就是在使用JDB：.
- ITeye博客
上一个专题中讲述了JVM中自带的各种性能测试的小工具：包括jps,jstatck,jmap,jhat,jsats,hprof.
这样会造成不必要的麻烦，难道就没有一个tool可以 包括如上所有的功能. 答案是有的，自从 JDK 6 Update 7以后，提供了一全新的性能检测工具:VisualVM,VisualVM对运行中的Java应用提供了可视化的信息展示, 它是很多工具的整合包，整合了JConsole,jstat,jinfo,jstack以及jmap.
SVCHOST是微软操作系统中的一项进程，微软官方对它的解释是：SVCHOST进程是从动态链接库（DLL）中运行的服务的通用主机进程名称. 这个程序对系统的正常运行是非常重要，而且是不能被结束的. 此前这个进程出现漏洞并困扰着许多用户长达几个月之久，这个漏洞使得XP系统运行过程中CPU的利用率居高不下.
- CSDN博客推荐文章
1.用top找到最耗资源的进程id. 2.查询最消耗资源的java进程. 3.打印java 栈 信息. 4.将耗资源的javaPID转换为16进制（&16进制&
去百度找 ：十进制转十六进制）. PID 对应 堆栈中的nid（16进制）. 去stack.txt 中查找nid=1720的问题.
- OurMySQL
在Linux VPS系统上有时候会发现MySQL占用CPU高，导致系统的负载比较高. 这种情况很可能是某个SQL语句执行的时间太长导致的. 优化一下这个SQL语句或者优化一下这个SQL引用的某个表的索引一般能解决问题.
但是怎么找到是哪个SQL语句的执行时间过长呢. 可以通过MySQL Slow Log来找，详解如下.
- Web前端 - ITeye博客
针对某个java程序cpu占用过高问题分析，要想找到问题的真正原因，首先要明确cpu过高的进程，通过对进程下线程的分析，定位到具体的应用代码，从而定位问题的原因所在.
在jdk自带的分析工具中，通过jconsole只能分析到应用程序的相关系统资源使用情况，但无法定位应用程序，故通过此工具了解到应用程序存在问题，但要具体定位到哪块程序不合理造成的是很困难的.
- Java译站
这篇文章会检验你有关JVM的知识以及项目交付相关的技能；尤其是涉及到JVM升级的时候. 期待你们的评论及回复，一起探讨下如何规避这类的项目可能产生的性能问题. 最近碰到了一个影响到线上生产环境的问题，我们使用的是WebLogic 10以及32位的Hotspot JVM 1.6. 鉴于目前的一些问题以及未来负载上升的预测，我们决定将HotSpot JVM 1.6升级成64位的.
坚持分享优质有趣的原创文章，并保留作者信息和版权声明，任何问题请联系：@。