JVM调优步骤：
第一步：监测JVM（JavaVirtual Machine）/GC（Garbage Collector）
第二步：调优
一、监测JVM/GC
==========================以下段落摘自网络（google或百度均可查到）========================
jps：与unix上的ps类似，用来显示本地的java进程，可以查看本地运行着几个java程序，并显示他们的进程号。
jinfo：可以输出并修改运行时的java 进程的opts。
jstat：一个极强的监视VM内存工具。可以用来监视VM内存内的各种堆和非堆的大小及其内存使用量。
jmap：打印出某个java进程（使用pid）内存内的，所有‘对象’的情况（如：产生那些对象，及其数量）。
jconsole：一个java GUI监视工具，可以以图表化的形式显示各种数据。并可通过远程连接监视远程的服务器VM。
jstat工具特别强大，有众多的可选项，详细查看堆内各个部分的使用量，以及加载类的数量。使用时，需加上查看进程的进程id，和所选参数。以下详细介绍各个参数的意义。
jstat -class pid:显示加载class的数量，及所占空间等信息。
jstat -compiler pid:显示VM实时编译的数量等信息。
jstat -gc pid:可以显示gc的信息，查看gc的次数，及时间。其中最后五项，分别是young gc的次数，young gc的时间，full gc的次数，full gc的时间，gc的总时间。
jstat -gccapacity:可以显示，VM内存中三代（young,old,perm）对象的使用和占用大小，如：PGCMN显示的是最小perm的内存使 用量，PGCMX显示的是perm的内存最大使用量，PGC是当前新生成的perm内存占用量，PC是但前perm内存占用量。其他的可以根据这个类推，OC是old内纯的占用量。
jstat -gcnew pid:new对象的信息。
jstat -gcnewcapacity pid:new对象的信息及其占用量。
jstat -gcold pid:old对象的信息。
jstat -gcoldcapacity pid:old对象的信息及其占用量。
jstat -gcpermcapacity pid: perm对象的信息及其占用量。
jstat -util pid:统计gc信息统计。
jstat -printcompilation pid:当前VM执行的信息。
jstat -gcutil: 个人最喜欢用的，后面将详解。
除了以上一个参数外，还可以同时加上 两个数字，如：jstat -printcompilation 3024 250 6是每250毫秒打印一次，一共打印6次，还可以加上-h3每三行显示一下标题。
jmap是一个可以输出所有内存中对象的工具，甚至可以将VM 中的heap，以二进制输出成文本。使用方法 jmap -histo pid。如果连用SHELL jmap -histo pid>a.log可以将其保存到文本中去，在一段时间后，使用文本对比工具，可以对比出GC回收了哪些对象。jmap -dump:format=b,file=String 3024可以将3024进程的内存heap输出出来到String文件里。
jinfo的用处比较简单，就是能输出并修改运行时的java进程的运行参数。用法是jinfo -opt pid 如：查看2788的MaxPerm大小可以用 jinfo -flag MaxPermSize 2788。
jconsole是一个用java写的GUI程序，用来监控VM，并可监控远程的VM，非常易用，而且功能非常强。由于是GUI程序，这里就不详细介绍了，不会的地方可以参考ＳＵＮ的官方文档。使用方法：命令行里打jconsole，选择进程就可以了。
使用jstat -gcutil 监控gc垃圾回收情况：
:~$ sudo jps
15734 WatchdogManager
15773 Resin
21947 Jps
:~$ sudo jstat -gcutil -t 15773 4s 50
Timestamp S0 S1 E O P YGC YGCT FGC FGCT GCT
5670.6 47.81 0.00 2.60 12.93 21.35 68 1.035 13 11.821 12.856
5674.7 47.81 0.00 6.65 12.93 21.35 68 1.035 13 11.821 12.856
5678.7 47.81 0.00 8.87 12.93 21.35 68 1.035 13 11.821 12.856
5682.7 47.81 0.00 10.35 12.93 21.35 68 1.035 13 11.821 12.856
5686.7 47.81 0.00 11.69 12.93 21.35 68 1.035 13 11.821 12.856
5690.7 47.81 0.00 14.15 12.93 21.35 68 1.035 13 11.821 12.856
5694.7 47.81 0.00 15.83 12.93 21.35 68 1.035 13 11.821 12.856
5698.7 47.81 0.00 17.07 12.93 21.35 68 1.035 13 11.821 12.856
5702.7 47.81 0.00 20.12 12.93 21.35 68 1.035 13 11.821 12.856
5706.6 47.81 0.00 23.22 12.93 21.35 68 1.035 13 11.821 12.856
5710.7 47.81 0.00 26.57 12.93 21.35 68 1.035 13 11.821 12.856
5714.7 47.81 0.00 29.78 12.93 21.35 68 1.035 13 11.821 12.856
5718.7 47.81 0.00 31.34 12.93 21.35 68 1.035 13 11.821 12.856
5722.7 47.81 0.00 33.45 12.93 21.35 68 1.035 13 11.821 12.856
5726.7 47.81 0.00 35.53 12.93 21.35 68 1.035 13 11.821 12.856
5730.7 47.81 0.00 37.80 12.93 21.35 68 1.035 13 11.821 12.856
5734.7 47.81 0.00 40.90 12.93 21.35 68 1.035 13 11.821 12.856
... ... ... ...
其中：
S0：Heap上的 Survivor space 0 段已使用空间的百分比
S1：Heap上的 Survivor space 1 段已使用空间的百分比
E： Heap上的 Eden space 段已使用空间的百分比
O： Heap上的 Old space 段已使用空间的百分比
P： Perm space 已使用空间的百分比
YGC：从程序启动到采样时发生Young GC的次数
YGCT：Young GC所用的时间(单位秒)
FGC：从程序启动到采样时发生Full GC的次数
FGCT：Full GC所用的时间(单位秒)
GCT：用于垃圾回收的总时间(单位秒)
针对上面的结果，稍微说说垃圾收集GC的基本操作过程如下：
首先，GC把内存大体分成4块，分别是old generation(年老代),eden(年轻代)，以及survivor space1(ss1),survivor space0(ss0)。
当声明变量的时候，首先是把变量声明在年轻代中，然后当年轻代被填满，则发生次要垃圾收集，将其中存活对象复制到SS1中，再将年轻代清空。继续在eden中声明对象，当eden再次填满，则再次发生次要垃圾收集，这次是把ss1的内容计算存活期，如果很长就复制到年老代，其余的存活的复制到ss0，然后将ss1清空，并对eden进行前述的次要垃圾收集。 当年老代也被填满，则产生一次主要垃圾收集，非常耗费时间。
==================================================
附1：JDK1.6官方文档首页和以上工具集的帮助文档：Java SE 6 Documentation：
JDK Tools and Utilities（JDK工具和适用程序）：
Monitoring Tools（监视工具）:
jps - Java Virtual Machine Process Status Tool：
jstat - Java Virtual Machine Statistics Monitoring Tool
Troubleshooting Tools（故障排除工具）:
jinfo - Configuration Info
jmap - Memory Map
Java Troubleshooting，Profiling，Monitoring and Management Tools（Java的故障排除，性能分析，监控和管理工具）：
jconsole - Java Monitoring and Management Console
二、调优
========================= 以下段落摘自网络（google或百度均可查到） =========================
JVM参数详解以及配置调优
基本概念：
PermGen space：全称是Permanent Generation space。就是说是永久保存的区域,用于存放Class和Meta信息，Class在被Load的时候被放入该区域。
Heap space：存放Instance。GC(Garbage Collection)应该不会对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS的话，就很可能出现PermGen space错误。
Java Heap分为3个区，Young，Old和Permanent。Young保存刚实例化的对象。当该区被填满时，GC会将对象移到Old区。Permanent区则负责保存反射对象。
JVM有2个GC线程：
第一个线程负责回收Heap的Young区。
第二个线程在Heap不足时，遍历Heap，将Young 区升级为Older区。Older区的大小等于-Xmx减去-Xmn，不能将-Xms的值设的过大，因为第二个线程被迫运行会降低JVM的性能。
为什么一些程序频繁发生GC？有如下原因：
1） 程序内调用了System.gc()或Runtime.gc()。
2） 一些中间件软件调用自己的GC方法，此时需要设置参数禁止这些GC。
3） Java的Heap太小，一般默认的Heap值都很小。
4） 频繁实例化对象，Release对象。此时尽量保存并重用对象，例如使用StringBuffer()和String()。
如果你发现每次GC后，Heap的剩余空间会是总空间的50%，这表示你的Heap处于健康状态。许多Server端的Java程序每次GC后最好能有65%的剩余空间。
建议Server端JVM最好将-Xms和-Xmx设为相同值。为了优化GC，最好让-Xmn值约等于-Xmx的1/3。一个GUI程序最好是每10到20秒间运行一次GC，每次在半秒之内完成。
增加Heap的大小虽然会降低GC的频率，但也增加了每次GC的时间。并且GC运行时，所有的用户线程将暂停，也就是GC期间，Java应用程序不做任何工作。
Heap大小并不决定进程的内存使用量。进程的内存使用量要大于-Xmx定义的值，因为Java为其他任务分配内存，例如每个线程的Stack等。
Stack的设定：
每个线程都有他自己的Stack。
-Xss 每个线程的Stack大小
Stack的大小限制着线程的数量。如果Stack过大就会导致内存溢漏。-Xss参数决定Stack大小，例如-Xss1024K。如果Stack太小，也会导致Stack溢漏。
硬件环境也影响GC的效率，例如机器的种类，内存，swap空间，和CPU的数量。
如果你的程序需要频繁创建很多transient对象，会导致JVM频繁GC。这种情况你可以增加机器的内存，来减少Swap空间的使用。
4种GC：
第一种为单线程GC，也是默认的GC。该GC适用于单CPU机器。
第二种为Throughput GC，是多线程的GC，适用于多CPU，使用大量线程的程序。第二种GC与第一种GC相似，不同在于GC在收集Young区是多线程的，但在Old区和第一种一样，仍然采用单线程。-XX:+UseParallelGC参数启动该GC。
第三种为Concurrent Low Pause GC，类似于第一种，适用于多CPU，并要求缩短因GC造成程序停滞的时间。这种GC可以在Old区的回收同时，运行应用程序。-XX:+UseConcMarkSweepGC参数启动该GC。
第四种为Incremental Low Pause GC，适用于要求缩短因GC造成程序停滞的时间。这种GC可以在Young区回收的同时，回收一部分Old区对象。-Xincgc参数启动该GC。
部分JVM参数配置：
1、 heap size
a: -Xmx
指定 jvm 的最大 heap 大小，如：-Xmx=2g
b: -Xms
指定 jvm 的最小 heap 大小，如：-Xms=2g，高并发应用建议和-Xmx一样，防止因为内存收缩/突然增大带来的性能影响。
c: -Xmn
指定 jvm 中 New Generation 的大小，如：-Xmn256m。 这个参数很影响性能，如果你的程序需要比较多的临时内存，建议设置到512M，如果用的少，尽量降低这个数值，一般来说128/256足以使用了。
d: -XX:PermSize=
指定 jvm 中 Perm Generation 的最小值，如：-XX:PermSize=32m。 这个参数需要看你的实际情况，可以通过jmap 命令看看到底需要多少。
e: -XX:MaxPermSize=
指定 Perm Generation 的最大值，如：-XX:MaxPermSize=64m
f: -Xss
指定线程桟大小，如：-Xss128k，一般来说，webx框架下的应用需要256K。 如果你的程序有大规模的递归行为，请考虑设置到512K/1M。 这个需要全面的测试才能知道。不过，256K已经很大了。 这个参数对性能的影响比较大的。
g: -XX:NewRatio=
指定 jvm 中 Old Generation heap size 与 New Generation 的比例，在使用 CMS GC 的情况下此参数失效，如:-XX:NewRatio=2
h: -XX:SurvivorRatio=
指定 New Generation 中 Eden Space 与一个 Survivor Space 的 heap size 比例，-XX:SurvivorRatio=8，那么在总共New Generation为10m 的情况下，Eden Space为8m
i: -XX:MinHeapFreeRatio=
指定 jvm heap在使用率小 n的情况下，heap进行收缩，Xmx==Xms 的情况下无效，如:-XX:MinHeapFreeRatio=30
j: -XX:MaxHeapFreeRatio=
指定 jvm heap在使用率大于n的情况下，heap进行扩张，Xmx==Xms 的情况下无效，如:-XX:MaxHeapFreeRatio=70
k: -XX:LargePageSizeInBytes=
指定 Java heap 的分页页面大小，如：-XX:LargePageSizeInBytes=128m
2: garbage collector
a: -XX:+UseParallelGC
指定在 New Generation 使用 parallel collector，并行收集，暂停app threads，同时启动多个垃圾回收thread，不能和 CMS gc 一起使用。系统吨吐量优先，但是会有较长长时间的app pause，后台系统任务可以使用此gc
b: -XX:ParallelGCThreads=
指定 parallel collection 时启动的 thread 个数，默认是物理 processor 的个数。
c: -XX:+UseParallelOldGC
指定在 Old Generation 使用 parallel collector。
d: -XX:+UseParNewGC
指定在 New Generation 使用 parallel collector，是 UseParallelGC 的 gc 的升级版本，有更好的性能或者优点，可以和 CMS gc 一起使用。
e: -XX:+CMSParallelRemarkEnabled
在使用 UseParNewGC 的情况下，尽量减少 mark 的时间。
f: -XX:+UseConcMarkSweepGC
指定在 Old Generation 使用 concurrent cmark sweep gc,gc thread 和 app thread 并行 ( 在 init-mark 和 remark 时 pause app thread)。app pause 时间较短，适合交互性强的系统，如 web server。
g: -XX:+UseCMSCompactAtFullCollection
在使用 concurrent gc 的情况下，防止 memory fragmention，对 live object 进行整理，使 memory 碎片减少。
h: -XX:CMSInitiatingOccupancyFraction=
指示在 old generation 在使用了 n% 的比例后，启动 concurrent collector，默认值是 68，如：-XX:CMSInitiatingOccupancyFraction=70。
i: -XX:+UseCMSInitiatingOccupancyOnly
指示只有在 old generation 在使用了初始化的比例后 concurrent collector 启动收集。
3、others
a: -XX:MaxTenuringThreshold=
指定一个 object 在经历了 n 次 young gc 后转移到 old generation 区，在 linux64 的 java6 下默认值是 15，此参数对于 throughput collector 无效，如：-XX:MaxTenuringThreshold=31。
b: -XX:+DisableExplicitGC
禁止 java 程序中的 full gc，如 System.gc() 的调用. 最好加上么，防止程序在代码里误用了。对性能造成冲击。
c: -XX:+UseFastAccessorMethods
get,set 方法转成本地代码。
d: -XX:+PrintGCDetails
打应垃圾收集的情况如： [GC 15610.466: [ParNew: 229689K->20221K(235968K)，0.0194460 secs] 1159829K->953935K(2070976K)，0.0196420 secs]。
e: -XX:+PrintGCTimeStamps
打应垃圾收集的时间情况，如： [Times: user=0.09 sys=0.00，real=0.02 secs]。
f: -XX:+PrintGCApplicationStoppedTime
打应垃圾收集时，系统的停顿时间，如： Total time for which application threads were stopped: 0.0225920 seconds。
==================================================
附2：官方JVM参数说明文档JavaTM Virtual Machine Technology（Java的虚拟机技术）：
Java HotSpot VM Options（Java HotSpot虚拟机选项）：
http://dolphin-ygj.iteye.com/blog/366216
JVM监控工具介绍jstack, jconsole, jinfo, jmap, jdb, jsta
博客分类：
调优
JVMJDKLinux多线程算法
JVM监控工具介绍
jstatd
启动jvm监控服务。它是一个基于rmi的应用，向远程机器提供本机jvm应用程序的信息。默认端口1099。
实例：jstatd -J-Djava.security.policy=my.policy
my.policy文件需要自己建立，内如如下：
grant codebase "file:$JAVA_HOME/lib/tools.jar" {
permission java.security.AllPermission;
};
这是安全策略文件，因为jdk对jvm做了jaas的安全检测，所以我们必须设置一些策略，使得jstatd被允许作网络操作
jps
列出所有的jvm实例
实例：
jps
列出本机所有的jvm实例
jps 192.168.0.77
列出远程服务器192.168.0.77机器所有的jvm实例，采用rmi协议，默认连接端口为1099
（前提是远程服务器提供jstatd服务）
输出内容如下：
jones@jones:~/data/ebook/java/j2se/jdk_gc$ jps
6286 Jps
6174 Jstat
jconsole
一个图形化界面，可以观察到java进程的gc，class，内存等信息。虽然比较直观，但是个人还是比较倾向于使用jstat命令（在最后一部分会对jstat作详细的介绍）。
jinfo（linux下特有）
观察运行中的java程序的运行环境参数：参数包括Java System属性和JVM命令行参数
实例：jinfo 2083
其中2083就是java进程id号，可以用jps得到这个id号。
输出内容太多了，不在这里一一列举，大家可以自己尝试这个命令。
jstack（linux下特有）
可以观察到jvm中当前所有线程的运行情况和线程当前状态
jstack 2083
输出内容如下：
99148782-fe1a-39a3-a987-9967928fb6f4.png
jmap（linux下特有，也是很常用的一个命令）
观察运行中的jvm物理内存的占用情况。
参数如下：
-heap：打印jvm heap的情况
-histo：打印jvm heap的直方图。其输出信息包括类名，对象数量，对象占用大小。
-histo：live ：同上，但是只答应存活对象的情况
-permstat：打印permanent generation heap情况
命令使用：
jmap -heap 2083
可以观察到New Generation（Eden Space，From Space，To Space）,tenured generation,Perm Generation的内存使用情况
输出内容：
38cee2b2-9eaa-3eca-ac45-2d917ac99436.png
jmap -histo 2083 ｜ jmap -histo:live 2083
可以观察heap中所有对象的情况（heap中所有生存的对象的情况）。包括对象数量和所占空间大小。
输出内容：
ffc0bb45-0466-3892-9c68-131e9f91c78f.png
写个脚本，可以很快把占用heap最大的对象找出来，对付内存泄漏特别有效。
jstat
最后要重点介绍下这个命令。
这是jdk命令中比较重要，也是相当实用的一个命令，可以观察到classloader，compiler，gc相关信息
具体参数如下：
-class：统计class loader行为信息
-compile：统计编译行为信息
-gc：统计jdk gc时heap信息
-gccapacity：统计不同的generations（不知道怎么翻译好，包括新生区，老年区，permanent区）相应的heap容量情况
-gccause：统计gc的情况，（同-gcutil）和引起gc的事件
-gcnew：统计gc时，新生代的情况
-gcnewcapacity：统计gc时，新生代heap容量
-gcold：统计gc时，老年区的情况
-gcoldcapacity：统计gc时，老年区heap容量
-gcpermcapacity：统计gc时，permanent区heap容量
-gcutil：统计gc时，heap情况
-printcompilation：不知道干什么的，一直没用过。
一般比较常用的几个参数是：
jstat -class 2083 1000 10 （每隔1秒监控一次，一共做10次）
输出内容含义如下：
Loaded Number of classes loaded.
Bytes Number of Kbytes loaded.
Unloaded Number of classes unloaded.
Bytes Number of Kbytes unloaded.
Time Time spent performing class load and unload operations.
jstat -gc 2083 2000 20（每隔2秒监控一次，共做10）
输出内容含义如下：
S0C Current survivor（存活的） space 0 capacity (KB).
EC Current eden space capacity (KB).
EU Eden space utilization (KB).
OC Current old space capacity (KB).
OU Old space utilization (KB).
PC Current permanent space capacity (KB).
PU Permanent space utilization (KB).
YGC Number of young generation GC Events.
YGCT Young generation garbage collection time.
FGC Number of full GC events.
FGCT Full garbage collection time.
GCT Total garbage collection time.
输出内容：
715fcb42-0481-39d7-8162-2bbf033eb806.png
监控内存使用情况 参数 （查看内存溢出相对有用）
jstat -gccause 2083 5000 （每隔5秒监控一次）
输出内容含义如下：
S0 Survivor space 0 utilization as a percentage of the space's current capacity.
S1 Survivor space 1 utilization as a percentage of the space's current capacity.
E Eden space utilization as a percentage of the space's current capacity.
O Old space utilization as a percentage of the space's current capacity.
P Permanent space utilization as a percentage of the space's current capacity.
YGC Number of young generation GC events.
YGCT Young generation garbage collection time.
FGC Number of full GC events.
FGCT Full garbage collection time.
GCT Total garbage collection time.
LGCC Cause of last Garbage Collection.
GCC Cause of current Garbage Collection.
评论
4 楼 swanky_yao 2011-03-18
jstack（linux下特有）
jdk6 windows下也有了
3 楼 swanky_yao 2011-03-18
jstack（linux下特有）
jdk6 windows下也有了
2 楼 dolphin_ygj 2009-04-12
java内存模型 http://dolphin-ygj.iteye.com/blog/366280
关于JVM内存管理（适用于所有J2EE产品）
援引JDK1.3为例(JDK 1.4除了在垃圾回收上有变化，其他的变化不大)：
现在无论是JDK1.3还是1.4，我们都是使用Sun JDK。
请注意：weblogic8.0自带了2种JDK，一种是Sun JDK，另一种是BEA自己的JRocket。
1. JVM内存段分配及启动参数：
J2EE服务器的内存组成：
? Java堆：我们的程序和对象都在这个堆进行管理
? C堆：当引用到一些Native的对象，如网络访问、OCI方式的数据库连接等都在C堆里进行管理
Java堆的描述：
如下图
44ccef05-d76a-3530-a80a-f62c77770a27.png
内存由 Perm 和 Heap 组成. 其中
Heap = {Old + young = { Eden , from, to } }
? Young及Old区域用来存放由Java类而生成的内存对象；
? Perm区域用来存放Java类及其他虚拟机自己的静态数据
垃圾回收描述：
垃圾回收分多级，0级为全部(Full)的垃圾回收，会回收OLD段中的垃圾；1级或以上为部分垃圾回收，只会回收Young中的垃圾，内存溢出通常发生于OLD段或Perm段垃圾回收后，仍然无内存空间容纳新的Java对象的情况。
当一个URL被访问时，内存申请过程如下：
A. JVM会试图为相关Java对象在Eden中初始化一块内存区域
B. 当Eden空间足够时，内存申请结束。否则到下一步
C. JVM试图释放在Eden中所有不活跃的对象（这属于1或更高级的垃圾回收）；释放后若Eden空间仍然不足以放入新对象，则试图将部分Eden中活跃对象放入Survivor区/OLD区
D. Survivor区被用来作为Eden及OLD的中间交换区域，当OLD区空间足够时，Survivor区的对象会被移到Old区，否则会被保留在Survivor区
E. 当OLD区空间不够时，JVM会在OLD区进行完全的垃圾收集（0级）
F. 完全垃圾收集后，若Survivor及OLD区仍然无法存放从Eden复制过来的部分对象，导致JVM无法在Eden区为新对象创建内存区域，则出现”out of memory错误”
Java堆相关参数：
ms/mx：定义YOUNG+OLD段的总尺寸，ms为JVM启动时YOUNG+OLD的内存大小；mx为最大可占用的YOUNG+OLD内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。
NewSize/MaxNewSize：定义YOUNG段的尺寸，NewSize为JVM启动时YOUNG的内存大小；MaxNewSize为最大可占用的YOUNG内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。
PermSize/MaxPermSize：定义Perm段的尺寸，PermSize为JVM启动时Perm的内存大小；MaxPermSize为最大可占用的Perm内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。
SurvivorRatio：设置Survivor空间和Eden空间的比例
例：
MEM_ARGS="-Xms512m -Xmx512m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:PermSize=128m -XX:MaxPermSize=128m -XX:SurvivorRatio=6"
在上面的例子中：
YOUNG+OLD: 512M
YOUNG: 256M
Perm: 128M
Eden: YOUNG*6/(6+1+1)=192M
Survivor: YOUNG/(6+1+1)=32M
Java堆的总尺寸=YOUNG+OLD+Perm=640M
2. JVM内存分析工具
可以使用HPjmeter来进行分析，需要将JDK的GC日志打开(-verbose:gc)，可定期用HPjmeter对GC日志进行分析，Demo工具可提供Java Heap内存变化图，以及垃圾回收图，这样就很容易分析内存溢出时是哪个段产生问题
3. 内存溢出的可能性
1. OLD段溢出
这种内存溢出是最常见的情况之一，产生的原因可能是：
1) 设置的内存参数过小(ms/mx, NewSize/MaxNewSize)
2) 程序问题
? 单个程序持续进行消耗内存的处理，如循环几千次的字符串处理，对字符串处理应建议使用StringBuffer。此时不会报内存溢出错，却会使系统持续垃圾收集，无法处理其它请求，相关问题程序可通过Thread Dump获取（见系统问题诊断一章）
? 单个程序所申请内存过大，有的程序会申请几十乃至几百兆内存，此时JVM也会因无法申请到资源而出现内存溢出，对此首先要找到相关功能，然后交予程序员修改，要找到相关程序，必须在Apache日志中寻找。
? 当Java对象使用完毕后，其所引用的对象却没有销毁，使得JVM认为他还是活跃的对象而不进行回收，这样累计占用了大量内存而无法释放。由于目前市面上还没有对系统影响小的内存分析工具，故此时只能和程序员一起定位。
2. Perm段溢出
通常由于Perm段装载了大量的Servlet类而导致溢出，目前的解决办法：
1) 将PermSize扩大，一般256M能够满足要求
2) 若别无选择，则只能将servlet的路径加到CLASSPATH中，但一般不建议这么处理
3. C Heap溢出
系统对C Heap没有限制，故C Heap发生问题时，Java进程所占内存会持续增长，直到占用所有可用系统内存。以下是一个案例，发生在INCOME：
假如项目的生产环境为HPUX，使用的数据库连接池为OCI模式，在应用服务器所安装的Oracle客户端版本为Oracle 9201
症状：Java进程所占内存不断增长，直到使用完系统所有内存而崩溃。
寻找问题方法：
对UNIX操作系统来说，Java Heap在进程的数据段、C Heap在进程的堆栈段，我们持续分析Java进程的数据段及堆栈段的增长情况（系统有相关的内存分析的系统调用），结果发现其堆栈段持续增长，说明问题不在Java相关的部分，而是在其它部分。
1 楼 dolphin_ygj 2009-04-12
java6性能
J2SE 6（代号：Mustang野马）主要设计原则之一就是提升J2SE的性能和扩展能力，主要通过最大程度提升运行效率，更好的垃圾收集和一些客户端性能来达到。
1、偏向锁（Biased locking）
Java 6以前加锁操作都会导致一次原子CAS（Compare-And-Set）操作，CAS操作是比较耗时的，即使这个锁上实际上没有冲突，只被一个线程拥有，也会带来较大开销。为解决这一问题，Java 6中引入偏向锁技术，即一个锁偏向于第一个加锁的线程，该线程后续加锁操作不需要同步。大概的实现如下：一个锁最初为NEUTRAL状态，当第一个线程加锁时，将该锁的状态修改为BIASED，并记录线程ID，当这一线程进行后续加锁操作时，若发现状态是BIASED并且线程ID是当前线程ID，则只设置一下加锁标志，不需要进行CAS操作。其它线程若要加这个锁，需要使用CAS操作将状态替换为REVOKE，并等待加锁标志清零，以后该锁的状态就变成 DEFAULT，常用旧的算法处理。这一功能可用-XX：-UseBiasedLocking命令禁止。
2、锁粗化（Lock coarsening）
如果一段代码经常性的加锁和解锁，在解锁与下次加锁之间又没干什么事情，则可以将多次加加锁解锁操作合并成一对。这一功能可用-XX：-EliminateLocks禁止。
3、自适应自旋（Adaptive spinning）
一般在多CPU的机器上加锁实现都会包含一个短期的自旋过程。自旋的次数不太好决定，自旋少了会导致线程被挂起和上下文切换增加，自旋多了耗CPU.为此Java 6中引入自适应自旋技术，即根据一个锁最近自旋加锁成功概率动态调整自旋次数。
4、常用大内存分布的堆（large page heap）
在大内分页是x86/amd64架构上用来减小TLB（虚拟地址到物理地址翻译缓存）大小的TLB失配率。Java 6中的内存堆可以使用这一技术。
5、提高数组拷贝性能
对每种类型大小写一个定制的汇编数组拷贝程序。
6、后台进行代码优化
Background Compilation in HotSpot Client Compiler： 后台进行代码优化
7、线性扫描寄存器分配算法（Linear Scan Register Allocation）
一种新的寄存器分配策略，基于SSA（static single assignment），性能提高10%左右。常用的寄存器分配算法将寄存器分配看作图着色问题，时间复杂度是O（n^4），不适用于Java的JIT编译。原来的JVM里是根据一些本地启发式规则来分配寄存器，效果不太好，Java 6中使用的线性扫描寄存器算法能够达到与图颜色算法相似的效果，并且时间复杂度是线性的。
8、并行缩并垃圾收集器（Parallel Compaction Collector）
进行Full GC时使用并行垃圾收集（JDK 5里原来非Full GC是并行的但Full GC是串行的），使用-XX：+UseParallelOldGC开启这一功能
9、并行低停顿垃圾收集器（Concurrent Low Pause Collector）
显式调用gc（如System.gc）时也可以并行进行标记-清扫式垃圾收集，使用-XX：+ExplicitGCInvokesConcurrent开启。
10、Ergonomics in the 6.0 Java Virtual Machine
自动调整垃圾收集策略、堆大小等配置，这一功能在JDK 5中加入，JDK 6中得到显著增强，SPECjbb2005性能提高70%.
11、boot类装载器的优化
jre中增加一个描述package所在jar文件的元索引文件，加快classloader加载类性能，提高桌面Java应用启动速度（+15%）。内存占用也减少了10%
12、图形程序优化
在jvm启动之前显示splash.
Swing程序中每个窗口有一个后台显示缓存，当该窗口原来被遮挡，现在要显示时直接从该缓存拷贝数据进行渲染，即使该窗口的绘制线程被阻塞也可以完成这一渲染。
java jvm 参数 -Xms -Xmx -Xmn -Xss 调优总结
常见配置举例
堆大小设置
JVM 中最大堆大小有三方面限制:相关操作系统的数据模型(32-bt还是64-bit)限制;系统的可用虚拟内存限制;系统的可用物理内存限制.32位系统 下,一般限制在1.5G~2G;64为操作系统对内存无限制.我在Windows Server 2003 系统,3.5G物理内存,JDK5.0下测试,最大可设置为1478m.
典型设置:
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
-Xmx3550m:设置JVM最大可用内存为3550M.
-Xms3550m:设置JVM促使内存为3550m.此值可以设置与-Xmx相同,以避免每次垃圾回收完成后JVM重新分配内存.
-Xmn2g:设置年轻代大小为2G.整个堆大小=年轻代大小 + 年老代大小 + 持久代大小.持久代一般固定大小为64m,所以增大年轻代后,将会减小年老代大小.此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8.
-Xss128k: 设置每个线程的堆栈大小.JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K.更具应用的线程所需内存大小进行 调整.在相同物理内存下,减小这个值能生成更多的线程.但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右.
java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0
-XX:NewRatio=4:设置年轻代(包括Eden和两个Survivor区)与年老代的比值(除去持久代).设置为4,则年轻代与年老代所占比值为1:4,年轻代占整个堆栈的1/5
-XX:SurvivorRatio=4:设置年轻代中Eden区与Survivor区的大小比值.设置为4,则两个Survivor区与一个Eden区的比值为2:4,一个Survivor区占整个年轻代的1/6
-XX:MaxPermSize=16m:设置持久代大小为16m.
-XX:MaxTenuringThreshold=0: 设置垃圾最大年龄.如果设置为0的话,则年轻代对象不经过Survivor区,直接进入年老代. 对于年老代比较多的应用,可以提高效率.如果将此值设置为一个较大值,则年轻代对象会在Survivor区进行多次复制,这样可以增加对象再年轻代的存活 时间,增加在年轻代即被回收的概论.
回收器选择
JVM给了三种选择:串行收集器,并行收集器,并发收集器,但是串行收集器只适用于小数据 量的情况,所以这里的选择主要针对并行收集器和并发收集器.默认 情况下,JDK5.0以前都是使用串行收集器,如果想使用其他收集器需要在启动时加入相应参数.JDK5.0以后,JVM会根据当前系统配置进行判断.
吞吐量优先的并行收集器
如上文所述,并行收集器主要以到达一定的吞吐量为目标,适用于科学技术和后台处理等.
典型配置:
java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
-XX:+UseParallelGC:选择垃圾收集器为并行收集器.此配置仅对年轻代有效.即上述配置下,年轻代使用并发收集,而年老代仍旧使用串行收集.
-XX:ParallelGCThreads=20:配置并行收集器的线程数,即:同时多少个线程一起进行垃圾回收.此值最好配置与处理器数目相等.
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC
-XX:+UseParallelOldGC:配置年老代垃圾收集方式为并行收集.JDK6.0支持对年老代并行收集.
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100
-XX:MaxGCPauseMillis=100:设置每次年轻代垃圾回收的最长时间,如果无法满足此时间,JVM会自动调整年轻代大小,以满足此值.
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy
-XX:+UseAdaptiveSizePolicy:设置此选项后,并行收集器会自动选择年轻代区大小和相应的Survivor区比例,以达到目标系统规定的最低相应时间或者收集频率等,此值建议使用并行收集器时,一直打开.
响应时间优先的并发收集器
如上文所述,并发收集器主要是保证系统的响应时间,减少垃圾收集时的停顿时间.适用于应用服务器,电信领域等.
典型配置:
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC:设置年老代为并发收集.测试中配置这个以后,-XX:NewRatio=4的配置失效了,原因不明.所以,此时年轻代大小最好用-Xmn设置.
-XX:+UseParNewGC:设置年轻代为并行收集.可与CMS收集同时使用.JDK5.0以上,JVM会根据系统配置自行设置,所以无需再设置此值.
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction:由于并发收集器不对内存空间进行压缩,整理,所以运行一段时间以后会产生"碎片",使得运行效率降低.此值设置运行多少次GC以后对内存空间进行压缩,整理.
-XX:+UseCMSCompactAtFullCollection:打开对年老代的压缩.可能会影响性能,但是可以消除碎片
辅助信息
JVM提供了大量命令行参数,打印信息,供调试使用.主要有以下一些:
-XX:+PrintGC
输出形式:[GC 118250K->113543K(130112K), 0.0094143 secs]
[Full GC 121376K->10414K(130112K), 0.0650971 secs]
-XX:+PrintGCDetails
输出形式:[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs]
[GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]
-XX:+PrintGCTimeStamps -XX:+PrintGC:PrintGCTimeStamps可与上面两个混合使用
输出形式:11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]
-XX:+PrintGCApplicationConcurrentTime:打印每次垃圾回收前,程序未中断的执行时间.可与上面混合使用
输出形式:Application time: 0.5291524 seconds
-XX:+PrintGCApplicationStoppedTime:打印垃圾回收期间程序暂停的时间.可与上面混合使用
输出形式:Total time for which application threads were stopped: 0.0468229 seconds
-XX:PrintHeapAtGC:打印GC前后的详细堆栈信息
输出形式:
34.702: [GC {Heap before gc invocations=7:
def new generation total 55296K, used 52568K [0x1ebd0000, 0x227d0000, 0x227d0000)
eden space 49152K, 99% used [0x1ebd0000, 0x21bce430, 0x21bd0000)
from space 6144K, 55% used [0x221d0000, 0x22527e10, 0x227d0000)
to space 6144K, 0% used [0x21bd0000, 0x21bd0000, 0x221d0000)
tenured generation total 69632K, used 2696K [0x227d0000, 0x26bd0000, 0x26bd0000)
the space 69632K, 3% used [0x227d0000, 0x22a720f8, 0x22a72200, 0x26bd0000)
compacting perm gen total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
the space 8192K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
ro space 8192K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
34.735: [DefNew: 52568K->3433K(55296K), 0.0072126 secs] 55264K->6615K(124928K)Heap after gc invocations=8:
def new generation total 55296K, used 3433K [0x1ebd0000, 0x227d0000, 0x227d0000)
eden space 49152K, 0% used [0x1ebd0000, 0x1ebd0000, 0x21bd0000)
from space 6144K, 55% used [0x21bd0000, 0x21f2a5e8, 0x221d0000)
to space 6144K, 0% used [0x221d0000, 0x221d0000, 0x227d0000)
tenured generation total 69632K, used 3182K [0x227d0000, 0x26bd0000, 0x26bd0000)
the space 69632K, 4% used [0x227d0000, 0x22aeb958, 0x22aeba00, 0x26bd0000)
compacting perm gen total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
the space 8192K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
ro space 8192K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
}
, 0.0757599 secs]
-Xloggc:filename:与上面几个配合使用,把相关日志信息记录到文件以便分析.
常见配置汇总
堆设置
-Xms:初始堆大小
-Xmx:最大堆大小
-XX:NewSize=n:设置年轻代大小
-XX:NewRatio=n:设置年轻代和年老代的比值.如:为3,表示年轻代与年老代比值为1:3,年轻代占整个年轻代年老代和的1/4
-XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值.注意Survivor区有两个.如:3,表示Eden:Survivor=3:2,一个Survivor区占整个年轻代的1/5
-XX:MaxPermSize=n:设置持久代大小
收集器设置
-XX:+UseSerialGC:设置串行收集器
-XX:+UseParallelGC:设置并行收集器
-XX:+UseParalledlOldGC:设置并行年老代收集器
-XX:+UseConcMarkSweepGC:设置并发收集器
垃圾回收统计信息
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-Xloggc:filename
并行收集器设置
-XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数.并行收集线程数.
-XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间
-XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比.公式为1/(1+n)
并发收集器设置
-XX:+CMSIncrementalMode:设置为增量模式.适用于单CPU情况.
-XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时,使用的CPU数.并行收集线程数.
调优总结
年轻代大小选择
响应时间优先的应用:尽可能设大,直到接近系统的最低响应时间限制(根据实际情况选择).在此种情况下,年轻代收集发生的频率也是最小的.同时,减少到达年老代的对象.
吞吐量优先的应用:尽可能的设置大,可能到达Gbit的程度.因为对响应时间没有要求,垃圾收集可以并行进行,一般适合8CPU以上的应用.
年老代大小选择
响 应时间优先的应用:年老代使用并发收集器,所以其大小需要小心设置,一般要考虑并发会话率和会话持续时间等一些参数.如果堆设置小了,可以会造成内存碎 片,高回收频率以及应用暂停而使用传统的标记清除方式;如果堆大了,则需要较长的收集时间.最优化的方案,一般需要参考以下数据获得:
并发垃圾收集信息
持久代并发收集次数
传统GC信息
花在年轻代和年老代回收上的时间比例
减少年轻代和年老代花费的时间,一般会提高应用的效率
吞吐量优先的应用:一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代.原因是,这样可以尽可能回收掉大部分短期对象,减少中期的对象,而年老代尽存放长期存活对象.
较小堆引起的碎片问题
因 为年老代的并发收集器使用标记,清除算法,所以不会对堆进行压缩.当收集器回收时,他会把相邻的空间进行合并,这样可以分配给较大的对象.但是,当堆空 间较小时,运行一段时间以后,就会出现"碎片",如果并发收集器找不到足够的空间,那么并发收集器将会停止,然后使用传统的标记,清除方式进行回收.如果 出现"碎片",可能需要进行如下配置:
-XX:+UseCMSCompactAtFullCollection:使用并发收集器时,开启对年老代的压缩.
-XX:CMSFullGCsBeforeCompaction=0:上面配置开启的情况下,这里设置多少次Full GC后,对年老代进行压缩
在 同一个工程下,有两个类,这两个类中只有很少的变动,而最关健的FOR却没有一点变动,可是当我分别运行这两个程序的时候却出现一个很严重的问题,一个程 序循环的快,一个循环的慢.这到底是怎么回事呢~???苦苦寻找了半天也没有想到是为什么,因为程序改变的部分根不影响我循环的速度,可是结果却是有很大 的差别,一个大约是在一分钟这内就可以循环完,可是另一个却需要六七分钟,这根本就不是一个数据理级的麻.两个完全一样的循环,从代码上根本上是看不出有 什么问题.不得以求助同事吧,可是同事看了也感觉很诡异,两个人在那订着代码又看了一个多小时,最后同事让我来个干净点的,关机重启.我到也听话,就顺着 同事的意思去了,可就在关机的这个时候他突然说是不是内存的问题,我也空然想到了,还真的有可能是内存的问题,因为快的那个在我之前运行程序之前可给过 1G的内存啊,而后来的这个我好像是没有设过内存啊,机器起来了,有了这个想法进去看看吧,结果正中要害,果真是慢的那个没有开内存,程序运行时只不过是 JVM默认开的内存.我初步分析是因为内存太小,而我的程序所用内存又正好卡在JVM所开内存边上,不至于溢出.当程序运行时就得花费大部分时间去调用 GC去,这样就导致了为什么相同的循环出现两种不同的效率~!
顺便把内存使用情况的方法也贴出来:
public static String getMemUsage() {
long free = java.lang.Runtime.getRuntime().freeMemory();
long total = java.lang.Runtime.getRuntime().totalMemory();
StringBuffer buf = new StringBuffer();
buf.append("[Mem: used ").append((total-free)>>20)
.append("M free ").append(free>>20)
.append("M total ").append(total>>20).append("M]");
return buf.toString();
}
google一下,大概就说JVM是这样来操作内存:
堆(Heap)和非堆(Non-heap)内存
按 照官方的说法:"Java 虚拟机具有一个堆,堆是运行时数据区域,所有类实例和数组的内存均从此处分配.堆是在 Java 虚拟机启动时创建的.""在JVM中堆之外的内存称为非堆内存(Non-heap memory)".可以看出JVM主要管理两种类型的内存:堆和非堆.简单来说堆就是Java代码可及的内存,是留给开发人员使用的;非堆就是JVM留给 自己用的,所以方法区,JVM内部处理或优化所需的内存(如JIT编译后的代码缓存),每个类结构(如运行时常数池,字段和方法数据)以及方法和构造方法 的代码都在非堆内存中.
堆内存分配
JVM初始分配的内存由-Xms指定,默认是物理内存的1/64;JVM最大分配的内存由-Xmx指 定,默认是物理内存的1/4.默认空余堆内存小于40%时,JVM就会增大堆直到-Xmx的最大限制;空余堆内存大于70%时, JVM会减少堆直到-Xms的最小限制.因此服务器一般设置-Xms,-Xmx相等以避免在每次GC 后调整堆的大小.
非堆内存分配
JVM使用-XX:PermSize设置非堆内存初始值,默认是物理内存的1/64;由XX:MaxPermSize设置最大非堆内存的大小,默认是物理内存的1/4.
JVM内存限制(最大值)
首 先JVM内存首先受限于实际的最大物理内存,假设物理内存无限大的话,JVM内存的最大值跟操作系统有很大的关系.简单的说就32位处理器虽然可控内存空 间有4GB,但是具体的操作系统会给一个限制,这个限制一般是 2GB-3GB(一般来说Windows系统下为1.5G-2G,Linux系统下为2G-3G),而64bit以上的处理器就不会有限制了
JVM内存的调优
1. Heap设定与垃圾回收Java Heap分为3个区,Young,Old和Permanent.Young保存刚实例化的对象.当该区被填满时,GC会将对象移到Old 区.Permanent区则负责保存反射对象,本文不讨论该区.JVM的Heap分配可以使用-X参数设定,
-Xms
初始Heap大小
-Xmx
java heap最大值
-Xmn
young generation的heap大小
JVM有2个GC线程.第一个线程负责回收Heap的Young区.第二个线程在Heap不足时,遍历Heap,将Young 区升级为Older区.Older区的大小等于-Xmx减去-Xmn,不能将-Xms的值设的过大,因为第二个线程被迫运行会降低JVM的性能.
为什么一些程序频繁发生GC?有如下原因:
l 程序内调用了System.gc()或Runtime.gc().
l 一些中间件软件调用自己的GC方法,此时需要设置参数禁止这些GC.
l Java的Heap太小,一般默认的Heap值都很小.
l 频繁实例化对象,Release对象.此时尽量保存并重用对象,例如使用StringBuffer()和String().
如果你发现每次GC后,Heap的剩余空间会是总空间的50%,这表示你的Heap处于健康状态.许多Server端的Java程序每次GC后最好能有65%的剩余空间.经验之谈:
1．Server端JVM最好将-Xms和-Xmx设为相同值.为了优化GC,最好让-Xmn值约等于-Xmx的1/3[2].
2．一个GUI程序最好是每10到20秒间运行一次GC,每次在半秒之内完成[2].
注意:
1．增加Heap的大小虽然会降低GC的频率,但也增加了每次GC的时间.并且GC运行时,所有的用户线程将暂停,也就是GC期间,Java应用程序不做任何工作.
2．Heap大小并不决定进程的内存使用量.进程的内存使用量要大于-Xmx定义的值,因为Java为其他任务分配内存,例如每个线程的Stack等.
2．Stack的设定
每个线程都有他自己的Stack.
-Xss
每个线程的Stack大小
Stack的大小限制着线程的数量.如果Stack过大就好导致内存溢漏.-Xss参数决定Stack大小,例如-Xss1024K.如果Stack太小,也会导致Stack溢漏.
3．硬件环境
硬件环境也影响GC的效率,例如机器的种类,内存,swap空间,和CPU的数量.
如果你的程序需要频繁创建很多transient对象,会导致JVM频繁GC.这种情况你可以增加机器的内存,来减少Swap空间的使用[2].
4．4种GC
第一种为单线程GC,也是默认的GC.,该GC适用于单CPU机器.
第二种为Throughput GC,是多线程的GC,适用于多CPU,使用大量线程的程序.第二种GC与第一种GC相似,不同在于GC在收集Young区是多线程的,但在Old区和第一种一样,仍然采用单线程.-XX:+UseParallelGC参数启动该GC.
第三种为Concurrent Low Pause GC,类似于第一种,适用于多CPU,并要求缩短因GC造成程序停滞的时间.这种GC可以在Old区的回收同时,运行应用程序.-XX:+UseConcMarkSweepGC参数启动该GC.
第四种为Incremental Low Pause GC,适用于要求缩短因GC造成程序停滞的时间.这种GC可以在Young区回收的同时,回收一部分Old区对象.-Xincgc参数启动该GC.
4种GC的具体描述参见[3].
参考文章:
1. JVM Tuning.
2. Performance tuning Java: Tuning steps
http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,1604,00.html
3. Tuning Garbage Collection with the 1.4.2 JavaTM Virtual Machine .
阅读(1779) | 评论(0) | 转发(0) |
