堆内存划分为 Eden、Survivor 和 Tenured/Old 空间，如下图所示：
从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC，对老年代GC称为Major GC,而Full GC是对整个堆来说的，在最近几个版本的JDK里默认包括了对永生带即方法区的回收（JDK8中无永生带了），出现Full GC的时候经常伴随至少一次的Minor GC,但非绝对的。Major GC的速度一般会比Minor GC慢10倍以上。下边看看有那种情况触发JVM进行Full GC及应对策略。
1、System.gc()方法的调用
此方法的调用是建议JVM进行Full GC,虽然只是建议而非一定,但很多情况下它会触发 Full GC,从而增加Full GC的频率,也即增加了间歇性停顿的次数。强烈影响系建议能不使用此方法就别使用，让虚拟机自己去管理它的内存，可通过通过-XX:+ DisableExplicitGC来禁止RMI调用System.gc。
2、老年代代空间不足
老年代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象，当执行Full GC后空间仍然不足，则抛出如下错误：
Java.lang.OutOfMemoryError: Java heap space
为避免以上两种状况引起的Full GC，调优时应尽量做到让对象在Minor GC阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。
3、永生区空间不足
JVM规范中运行时数据区域中的方法区，在HotSpot虚拟机中又被习惯称为永生代或者永生区，Permanet Generation中存放的为一些class的信息、常量、静态变量等数据，当系统中要加载的类、反射的类和调用的方法较多时，Permanet Generation可能会被占满，在未配置为采用CMS GC的情况下也会执行Full GC。如果经过Full GC仍然回收不了，那么JVM会抛出如下错误信息：
java.lang.OutOfMemoryError: PermGen space
为避免Perm Gen占满造成Full GC现象，可采用的方法为增大Perm Gen空间或转为使用CMS GC。
4、CMS GC时出现promotion failed和concurrent mode failure
对于采用CMS进行老年代GC的程序而言，尤其要注意GC日志中是否有promotion failed和concurrent mode failure两种状况，当这两种状况出现时可能
会触发Full GC。
promotion failed是在进行Minor GC时，survivor space放不下、对象只能放入老年代，而此时老年代也放不下造成的；concurrent mode failure是在
执行CMS GC的过程中同时有对象要放入老年代，而此时老年代空间不足造成的（有时候“空间不足”是CMS GC时当前的浮动垃圾过多导致暂时性的空间不足触发Full GC）。
对措施为：增大survivor space、老年代空间或调低触发并发GC的比率，但在JDK 5.0+、6.0+的版本中有可能会由于JDK的bug29导致CMS在remark完毕
后很久才触发sweeping动作。对于这种状况，可通过设置-XX: CMSMaxAbortablePrecleanTime=5（单位为ms）来避免。
5、统计得到的Minor GC晋升到旧生代的平均大小大于老年代的剩余空间
这是一个较为复杂的触发情况，Hotspot为了避免由于新生代对象晋升到旧生代导致旧生代空间不足的现象，在进行Minor GC时，做了一个判断，如果之
前统计所得到的Minor GC晋升到旧生代的平均大小大于旧生代的剩余空间，那么就直接触发Full GC。
例如程序第一次触发Minor GC后，有6MB的对象晋升到旧生代，那么当下一次Minor GC发生时，首先检查旧生代的剩余空间是否大于6MB，如果小于6MB，
则执行Full GC。
当新生代采用PS GC时，方式稍有不同，PS GC是在Minor GC后也会检查，例如上面的例子中第一次Minor GC后，PS GC会检查此时旧生代的剩余空间是否
大于6MB，如小于，则触发对旧生代的回收。
除了以上4种状况外，对于使用RMI来进行RPC或管理的Sun JDK应用而言，默认情况下会一小时执行一次Full GC。可通过在启动时通过- java -
Dsun.rmi.dgc.client.gcInterval=3600000来设置Full GC执行的间隔时间或通过-XX:+ DisableExplicitGC来禁止RMI调用System.gc。
6、堆中分配很大的对象
所谓大对象，是指需要大量连续内存空间的java对象，例如很长的数组，此种对象会直接进入老年代，而老年代虽然有很大的剩余空间，但是无法找到足够大的连续空间来分配给当前对象，此种情况就会触发JVM进行Full GC。
为了解决这个问题，CMS垃圾收集器提供了一个可配置的参数，即-XX:+UseCMSCompactAtFullCollection开关参数，用于在“享受”完Full GC服务之后额外免费赠送一个碎片整理的过程，内存整理的过程无法并发的，空间碎片问题没有了，但提顿时间不得不变长了，JVM设计者们还提供了另外一个参数 -XX:CMSFullGCsBeforeCompaction,这个参数用于设置在执行多少次不压缩的Full GC后,跟着来一次带压缩的。
1. JVM性能监控
1、定位系统问题
- 依据
- GC日志
- 堆转储快照（heapdump/hprof文件）
- 线程快照（threaddump/javacore文件）
- 运行日志
- 异常堆栈
- 分析依据的工具
- jps：显示指定系统内的所有JVM进程
- jstat：收集JVM各方面的运行数据
- jinfo：显示JVM配置信息
- jmap：形成堆转储快照（heapdump文件）
- jhat：分析heapdump文件
- jstack：显示JVM的线程快照
- jconsole
- visualVM
说明：后边两种是具有图形化界面的。
2、jps（是其他所有命令的基础）
作用：列出所有的JVM虚拟机进程。
格式：jps -l
3、jstat（是没有GUI界面的情况下，在运行期定位JVM性能问题的首选）
作用：查看gc数据和类加载卸载数据
格式：jstat option PID interval count
意义：每隔interval毫秒做一次option，一共做count次
说明：S0(from区)使用了41.74%；S1(to区)使用了0；E(Eden区)使用了54.35%；O(Old，年老代)使用了62.41%；P(Perment，永久代)使用了99.63%；YGC(Young GC)了32次，YGCT(Young GC Time)花销0.132秒；FGC(Full GC)了1次，FGCT(Full GC Time)花销0.102秒；GCT(GC Time)总花销0.234秒。
分析：其实上边这个查询结果可以直接看出，我们需要加大P（永久代大小）
说明：加载了3683个类，总共占有4355.3字节；卸载了0个类，卸载的类的字节数为0，类的加载与卸载共花销3.16秒
更多的jstat的使用，参看http://my.oschina.net/skyline520/blog/304805
4、jinfo
作用：查看和运行期修改JVM的配置参数
格式：jinfo -flag parameter PID
说明：查看3732进程下的MaxTenuringThreshold参数值。
说明：修改3732进程下的MaxTenuringThreshold参数值，但是windows下失败。
5、jmap
作用：生成堆转储快照和查看最占内存的元素，用于分析内存泄露问题
格式（生成堆转储快照）：jmap -dump:format=b,file=文件名 PID
说明：生成了3732进程的堆转储文件myfile
格式（查看最占内存的元素）：jmap -histo PID
说明：结果自己去看，太多了
6、jhat
作用：分析堆转储快照（与jmap配合）
格式：jhat 文件名
说明：执行上述命令后，打开localhost:7000，找到如下红框部分打开，这里才是我们最关注的东西。
注意：该工具是万不得已才用的。
推出命令使用"ctrl+c"
7、jstack
作用：生成线程快照，定位线程长时间卡顿的原因（线程间死锁、死循环、请求外部资源导致的长时间等待）
格式：jstack -l PID
说明：查看3732进程中的所有线程的堆栈信息
《深入理解Java虚拟机》的作者提供了一个工具jsp页面，使得我们可以在程序运行时，随时运行该jsp页面，来查看线程堆栈信息，代码如下：
1 <%@ page language="java" contentType="text/html; charset=UTF-8" 2 pageEncoding="UTF-8" import="java.util.Map"%> 3 <!DOCTYPE html> 4 <html> 5 <head> 6 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 7 <title>jstack</title> 8 </head> 9 <body> 10 <% 11 for(Map.Entry<Thread, StackTraceElement[]> stackTrace : Thread.getAllStackTraces().entrySet()){ 12 Thread thread = (Thread)stackTrace.getKey(); 13 StackTraceElement[] elements = (StackTraceElement[])stackTrace.getValue(); 14 15 /* if(thread.equals(Thread.currentThread())){ 16 continue; 17 } */ 18 out.println(" 线程："+thread.getName()+" "); 19 for(StackTraceElement ele : elements){ 20 out.println(" "+ele+" "); 21 } 22 } 23 %> 24 </body> 25 </html>
注意：代码中我注释掉一段，是因为想也查出当前线程的堆栈信息，作者并没有这个注释。
总结：
- JVM性能相关的6个常用的JDK命令
- jps：查询JVM中的所有进程，找出将要操作的PID，是所有命令的基础
- jstat：查看相应JVM进程的gc、类加载卸载信息，是没有GUI界面查看JVM运行数据的首选
- jinfo：查看和在运行期动态修改JVM配置参数
- jmap：生成堆转储快照和比较占内存的对象
- jhat：配合jmap分析堆转储日志，除非没有其他工具可做这个事儿，否则就不用该工具
- jstack：生成线程快照，定位线程长时间卡顿的原因（线程间死锁、死循环、请求外部资源导致的长时间等待）
- 输出gc信息到控制台
- -XX:+PrintGCDetails：输出GC的详细信息
- -XX:+PrintGCTimeStamps：输出GC的时间信息
- -XX:+PrintGCApplicatonStoppedTime：GC造成的应用暂停的时间
- -XX:+PrintGCDetails：输出GC的详细信息
- 输出gc信息到文件
- 以上三个参数在这里依旧适用
- -Xloggc:文件路径/gc.log：输出到文件
图形化的JVM性能监控
1、图像化的故障处理工具
- Jconsole
- visualVM
2、Jconsole
进入"E:Javajdk1.6in"，双击"jconsole.exe"，弹出如下框：
说明：这里列出了所有的JVM进程，一个Jconsole进程，一个eclipse（PID：4684），这相当于jps命令。
选中其中一个PID，假设选中了eclipse，双击，出现下图：（注：之后的各个叶签，都是每4秒刷新一次）
"内存"：相当于jstat -gc，在上图中的详细信息部分，该部分对应的信息就是头部图表部分所写的参数（这里是"整个堆"的情况），同时对应的也是右下角部分柱状图所选中的柱子（这里是"堆"），对于"非堆"指的就是"方法区"（或者称为"永久代"）。当然，这里也可以选择时间范围来查看相应的信息。
"类"：相当于jstat -class，列出了装载类和卸载类的相关信息。
"线程"：相当于jstack，折线图显示了线程数目的变化情况，包括峰值线程数量、活动线程数量；左下角展示了所有线程名称。双击相应的线程名称
"VM摘要"：相当于jinfo
最后，测试一下线程死锁的现象。代码如下：
View
Code执行main()方法，之后去查看"线程"标签，点击"检测死锁"，如下：
发现线程Thread-95和Thread-106死锁（彼此拥有对方想要的锁）
分析：
1）Integer缓存机制
Integer.valueOf(int xxx)，该方法为了减少对象的创建，节省内存，会将xxx转化成的Integer对象缓存起来，之后只要是相同的xxx，那么这个方法都会直接从缓存中取出对象来。假设代码中的Integer.valueOf(1)生成的对象是java.lang.Integer@987197，而Integer.valueOf(2)生成的对象是java.lang.Integer@15e293a，那么之后无论调用多少次Integer.valueOf(1)，也无论是哪一个线程去调用该方法，返回的都只是同一个对象java.lang.Integer@987197。也就是说上边的这段代码中的Integer.valueOf(i)只会生成两个不同的对象，就是java.lang.Integer@987197和java.lang.Integer@15e293a，而这两个对象也就是我们的锁对象。
2）死锁发生的时机
假设线程"Thread-95"执行到其第一个synchronized块中时（假设刚刚获取了锁对象java.lang.Integer@987197），这时候CPU时间片切换给了线程"Thread-106"，而"Thread-106"执行其第一个synchronized块（获取了锁对象java.lang.Integer@15e293a），之后"Thread-106"要执行第二个synchronized块儿来获取锁对象java.lang.Integer@987197，这时候就获取不到了，因为这个锁对象正被"Thread-95"所持有，于是"Thread-106"就阻塞在java.lang.Integer@987197这个锁对象上，这时，假设CPU时间片又切换给了"Thread-95"，该线程要执行第二个synchronized块来获取java.lang.Integer@15e293a，就获取不到了，因为该锁对象已被"Thread-106"所持有
3）结果
"Thread-95"持有锁对象java.lang.Integer@987197，阻塞在锁对象java.lang.Integer@15e293a；
"Thread-106"持有锁对象java.lang.Integer@15e293a，阻塞在锁对象java.lang.Integer@987197
3、visualVM
是一块更加全面的GUI监视工具，包含很多插件（需要自己下载），具体的见《深入理解Java虚拟机（第二版）》
JVM调优
1、JVM的调优主要是内存的调优，主要调两个方面：
- 各个代的大小
- 垃圾收集器选择
2、各个代的大小
- 常用的调节参数
- -Xmx
- -Xms
- -Xmn
- -XX:SurvivorRatio
- -XX:MaxTenuringThreshold
- -XX:PermSize
- -XX:MaxPermSize
- 原则
- -Xmx==-Xms：防止堆内存频繁进行调整，调整的时机见《第一章 JVM内存结构》
- -Xmn：通常设为-Xmx/4（这是我在企业中实习时的设置方式，系统运行正常、平稳、速度也快），林昊推荐的是-Xmx/3，所以-Xmn==-Xmx/4~-Xmx/3
- 调节时机：minor GC太频繁
- -Xmn过小：minor GC太频繁；小对象可能也会直接进入年老代，提前导致Full GC
- -Xmn过大：年轻代大了，minor GC的时间变长了；年老代变小了，Full GC会频繁
- 调节策略：若-Xmx可调大，则调大，且保持-Xmn==-Xmx/4~-Xmx/3；若-Xmx不可调大，在保持-Xmn==-Xmx/4~-Xmx/3的范围内增大-Xmn，若-Xmn也不可调了，则试着调大-XX:SurvivorRatio来看看情况
- -XX:SurvivorRatio：默认8
- -XX:SurvivorRatio过大：Eden变大，Survivor变小，minor GC可能减少，但是由于suvivor减小了，所以如果minor GC存活下来的对象大于suvivor，则会直接进入年老代
- -XX:SurvivorRatio过小：Eden变小，Survivor变大，minor GC可能增多，但是由于suvivor变大了，能够存储更多存活下来的对象，进入年老代的对象可能会减少
- -XX:MaxTenuringThreshold：默认为15
- -XX:SurvivorRatio过大：对象在年轻代的存活时间变长，可能在年轻代就被回收掉而不必进入年老代，但是相应的复制的时候survivor区就会被占用更多的空间。
- -XX:SurvivorRatio过大：对象在年轻代的存活时间变短，可能会早早进入年老代而失去在年轻代被回收的机会，但是相应的复制的时候survivor区也就有更多内存了，这样可能会避免部分大对象直接进入年老代
- -XX:MaxPermSize==-XX:PermSize
- 在实际开发中，前台不要使用jsp，使用velocity等模板引擎技术
- 不要引入无关的jar
3、垃圾收集器选择
企业中最常用的两个组合：（这里由于大部分大型企业用的还是JDK1.6，所以G1不说）
关于下边两组垃圾收集器的详细原理见：第五章 JVM垃圾收集器（1）
- Parallel Scavenge/Parallel Old
- 注重吞吐量（吞吐量越大，说明CPU利用率越高）
- 主要用于处理很多的CPU计算任务而用户交互任务较少的情况
- 也用于让JVM自动调优而我们袖手旁观的情况（-XX:+UseParallelOldGC，-XX:GCTimeRatio，-Xmx，-XX:+UseAdaptiveSizePolicy）
- -XX:+UseParallelOldGC：指定使用该组合
- ParNew/CMS
- 注重STW的缩短（该时间越短，用户体验越好，而且会减少部分请求的请求超时问题）
- -XX:+UseConcMarkSweepGC：指定使用该组合
- -XX:CMSInitiatingOccupancyFraction：来指定当年老代空间满了多少后（百分比）进行垃圾回收
- 关于上边两种组合的说明
- 一般而言，在企业中，机器的CPU数量都比较多，且CPU的计算能力也不会成为瓶颈，所以对于CMS的并发标记与并发清除阶段，会占用CPU资源的问题，其实不是大事儿；而对于Parallel的注重吞吐量的问题也就不是什么大事儿了，毕竟CPU是强大的
- 所以，ParNew/CMS是首选（在G1不能用的情况下），Parallel Scavenge/Parallel Old只在想让JVM自动管理内存的情况下使用
注意：在实际调优过程中，可以使用jstat、jconsole、visualVM或GC日志的检测数据来调，具体的示例见《深入理解java虚拟机（第二版）》p142对eclipse运行速度的调优。
关于GC日志的参数含义与每一种垃圾收集器的GC日志的格式，查看《深入理解Java虚拟机（第二版）》的P89和《深入分析Java Web技术内幕（修订版）》的P224
Java堆内存被划分为新生代和年老代两部分，新生代主要使用复制和标记-清除垃圾回收算法，年老代主要使用标记-整理垃圾回收算法，因此java虚拟中针对新生代和年老代分别提供了多种不同的垃圾收集器，JDK1.6中Sun
HotSpot虚拟机的垃圾收集器如下：
图中如果两个垃圾收集器直接有连线，则表明这两个垃圾收集器可以搭配使用。
(1).Serial垃圾收集器：
Serial是最基本、历史最悠久的垃圾收集器，使用复制算法，曾经是JDK1.3.1之前新生代唯一的垃圾收集器。
Serial是一个单线程的收集器，它不仅仅只会使用一个CPU或一条线程去完成垃圾收集工作，并且在进行垃圾收集的同时，必须暂停其他所有的工作线程，直到垃圾收集结束。
Serial垃圾收集器虽然在收集垃圾过程中需要暂停所有其他的工作线程，但是它简单高效，对于限定单个CPU环境来说，没有线程交互的开销，可以获得最高的单线程垃圾收集效率，因此Serial垃圾收集器依然是java虚拟机运行在Client模式下默认的新生代垃圾收集器。
(2).ParNew垃圾收集器：
ParNew垃圾收集器其实是Serial收集器的多线程版本，也使用复制算法，除了使用多线程进行垃圾收集之外，其余的行为和Serial收集器完全一样，ParNew垃圾收集器在垃圾收集过程中同样也要暂停所有其他的工作线程。
ParNew收集器默认开启和CPU数目相同的线程数，可以通过-XX:ParallelGCThreads参数来限制垃圾收集器的线程数。
ParNew虽然是除了多线程外和Serial收集器几乎完全一样，但是ParNew垃圾收集器是很多java虚拟机运行在Server模式下新生代的默认垃圾收集器。
(3).Parallel Scavenge收集器：
Parallel Scavenge收集器也是一个新生代垃圾收集器，同样使用复制算法，也是一个多线程的垃圾收集器，它重点关注的是程序达到一个可控制的吞吐量（Thoughput，CPU用于运行用户代码的时间/CPU总消耗时间，即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)），高吞吐量可以最高效率地利用CPU时间，尽快地完成程序的运算任务，主要适用于在后台运算而不需要太多交互的任务。
Parallel Scavenge收集器提供了两个参数用于精准控制吞吐量：
a.-XX:MaxGCPauseMillis：控制最大垃圾收集停顿时间，是一个大于0的毫秒数。
b.-XX:GCTimeRation：直接设置吞吐量大小，是一个大于0小于100的整数，也就是程序运行时间占总时间的比率，默认值是99，即垃圾收集运行最大1%（1/(1+99)）的垃圾收集时间。
Parallel Scavenge是吞吐量优先的垃圾收集器，它还提供一个参数：-XX:+UseAdaptiveSizePolicy，这是个开关参数，打开之后就不需要手动指定新生代大小(-Xmn)、Eden与Survivor区的比例(-XX:SurvivorRation)、新生代晋升年老代对象年龄(-XX:PretenureSizeThreshold)等细节参数，虚拟机会根据当前系统运行情况收集性能监控信息，动态调整这些参数以达到最大吞吐量，这种方式称为GC自适应调节策略，自适应调节策略也是ParallelScavenge收集器与ParNew收集器的一个重要区别。
(4).Serial Old收集器：
Serial Old是Serial垃圾收集器年老代版本，它同样是个单线程的收集器，使用标记-整理算法，这个收集器也主要是运行在Client默认的java虚拟机默认的年老代垃圾收集器。
在Server模式下，主要有两个用途：
a.在JDK1.5之前版本中与新生代的Parallel Scavenge收集器搭配使用。
b.作为年老代中使用CMS收集器的后备垃圾收集方案。
新生代Serial与年老代Serial Old搭配垃圾收集过程图：
新生代Parallel Scavenge收集器与ParNew收集器工作原理类似，都是多线程的收集器，都使用的是复制算法，在垃圾收集过程中都需要暂停所有的工作线程。
新生代Parallel Scavenge/ParNew与年老代Serial Old搭配垃圾收集过程图：
(5).Parallel Old收集器：
Parallel Old收集器是Parallel Scavenge的年老代版本，使用多线程的标记-整理算法，在JDK1.6才开始提供。
在JDK1.6之前，新生代使用ParallelScavenge收集器只能搭配年老代的Serial Old收集器，只能保证新生代的吞吐量优先，无法保证整体的吞吐量，Parallel Old正是为了在年老代同样提供吞吐量优先的垃圾收集器，如果系统对吞吐量要求比较高，可以优先考虑新生代Parallel Scavenge和年老代Parallel Old收集器的搭配策略。
新生代Parallel Scavenge和年老代Parallel Old收集器搭配运行过程图：
(6).CMS收集器：
Concurrent mark sweep(CMS)收集器是一种年老代垃圾收集器，其最主要目标是获取最短垃圾回收停顿时间，和其他年老代使用标记-整理算法不同，它使用多线程的标记-清除算法。
最短的垃圾收集停顿时间可以为交互比较高的程序提高用户体验，CMS收集器是Sun HotSpot虚拟机中第一款真正意义上并发垃圾收集器，它第一次实现了让垃圾收集线程和用户线程同时工作。
CMS工作机制相比其他的垃圾收集器来说更复杂，整个过程分为以下4个阶段：
a.初始标记：只是标记一下GC Roots能直接关联的对象，速度很快，仍然需要暂停所有的工作线程。
b.并发标记：进行GC Roots跟踪的过程，和用户线程一起工作，不需要暂停工作线程。
c.重新标记：为了修正在并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，仍然需要暂停所有的工作线程。
d.并发清除：清除GC Roots不可达对象，和用户线程一起工作，不需要暂停工作线程。
由于耗时最长的并发标记和并发清除过程中，垃圾收集线程可以和用户现在一起并发工作，所以总体上来看CMS收集器的内存回收和用户线程是一起并发地执行。
CMS收集器工作过程：
CMS收集器有以下三个不足：
a.CMS收集器对CPU资源非常敏感，其默认启动的收集线程数=(CPU数量+3)/4，在用户程序本来CPU负荷已经比较高的情况下，如果还要分出CPU资源用来运行垃圾收集器线程，会使得CPU负载加重。
b.CMS无法处理浮动垃圾(Floating Garbage)，可能会导致Concurrent ModeFailure失败而导致另一次Full GC。由于CMS收集器和用户线程并发运行，因此在收集过程中不断有新的垃圾产生，这些垃圾出现在标记过程之后，CMS无法在本次收集中处理掉它们，只好等待下一次GC时再将其清理掉，这些垃圾就称为浮动垃圾。
CMS垃圾收集器不能像其他垃圾收集器那样等待年老代机会完全被填满之后再进行收集，需要预留一部分空间供并发收集时的使用，可以通过参数-XX:CMSInitiatingOccupancyFraction来设置年老代空间达到多少的百分比时触发CMS进行垃圾收集，默认是68%。
如果在CMS运行期间，预留的内存无法满足程序需要，就会出现一次ConcurrentMode Failure失败，此时虚拟机将启动预备方案，使用Serial Old收集器重新进行年老代垃圾回收。
c.CMS收集器是基于标记-清除算法，因此不可避免会产生大量不连续的内存碎片，如果无法找到一块足够大的连续内存存放对象时，将会触发因此Full GC。CMS提供一个开关参数-XX:+UseCMSCompactAtFullCollection，用于指定在Full GC之后进行内存整理，内存整理会使得垃圾收集停顿时间变长，CMS提供了另外一个参数-XX:CMSFullGCsBeforeCompaction，用于设置在执行多少次不压缩的Full GC之后，跟着再来一次内存整理。
(7).G1收集器：
Garbage first垃圾收集器是目前垃圾收集器理论发展的最前沿成果，相比与CMS收集器，G1收集器两个最突出的改进是：
a.基于标记-整理算法，不产生内存碎片。
b.可以非常精确控制停顿时间，在不牺牲吞吐量前提下，实现低停顿垃圾回收。
G1收集器避免全区域垃圾收集，它把堆内存划分为大小固定的几个独立区域，并且跟踪这些区域的垃圾收集进度，同时在后台维护一个优先级列表，每次根据所允许的收集时间，优先回收垃圾最多的区域。
区域划分和优先级区域回收机制，确保G1收集器可以在有限时间获得最高的垃圾收集效率。
Java虚拟机常用的垃圾收集器相关参数如下：
|
参数 |
描述 |
|
UseSerialGC |
虚拟机运行在Client模式的默认值，打开此开关参数后， |
|
UseParNewGC |
打开此开关参数后，使用ParNew+Serial Old收集器组合进 |
|
UseConcMarkSweepGC |
打开此开关参数后，使用ParNew+CMS+Serial Old收集器组 |
|
UseParallelGC |
虚拟机运行在Server模式的默认值，打开此开关参数后， |
|
UseParallelOldGC |
打开此开关参数后， |
|
SurvivorRation |
新生代内存中Eden区域与Survivor区域容量比值，默认是8，即 |
|
PretenureSizeThreshold |
直接晋升到年老代的对象大小，设置此参数后，超过该大小的 |
|
MaxTenuringThreshold |
直接晋升到年老代的对象年龄，每个对象在一次Minor GC之后还 |
|
UseAdaptiveSizePolicy |
java虚拟机动态自适应策略，动态调整年老代对象年龄和各个区域大小。 |
|
HandlePromotionFailure |
是否允许担保分配内存失败，即整个年老代空间不足，而整个新生代中Eden和Survivor对象都存活的极端情况。 |
|
ParallelGCThreads |
设置并行GC时进行内存回收的线程数。 |
|
GCTimeRation |
Parallel Scavenge收集器运行时间占总时间比率。 |
|
MaxGCPauseMillis |
Parallel Scavenge收集器最大GC停顿时间。 |
|
CMSInitiatingOccupancyFraction |
设置CMS收集器在年老代空间被使用多少百分比之后触发垃圾收集，默认是68%。 |
|
UseCMSCompactAtFullCollection |
设置CMS收集器在完成垃圾收集之后是否进行一次内存整理。 |
|
CMSFullGCsBeforeCompaction |
设置CMS收集器在进行多少次垃圾收集之后才进行一次内存整理。 |
-verbose:gc可以查看Java虚拟机垃圾收集结果。
1. JVM性能监控
1、定位系统问题
- 依据
- GC日志
- 堆转储快照（heapdump/hprof文件）
- 线程快照（threaddump/javacore文件）
- 运行日志
- 异常堆栈
- 分析依据的工具
- jps：显示指定系统内的所有JVM进程
- jstat：收集JVM各方面的运行数据
- jinfo：显示JVM配置信息
- jmap：形成堆转储快照（heapdump文件）
- jhat：分析heapdump文件
- jstack：显示JVM的线程快照
- jconsole
- visualVM
说明：后边两种是具有图形化界面的。
2、jps（是其他所有命令的基础）
作用：列出所有的JVM虚拟机进程。
格式：jps -l
3、jstat（是没有GUI界面的情况下，在运行期定位JVM性能问题的首选）
作用：查看gc数据和类加载卸载数据
格式：jstat option PID interval count
意义：每隔interval毫秒做一次option，一共做count次
说明：S0(from区)使用了41.74%；S1(to区)使用了0；E(Eden区)使用了54.35%；O(Old，年老代)使用了62.41%；P(Perment，永久代)使用了99.63%；YGC(Young GC)了32次，YGCT(Young GC Time)花销0.132秒；FGC(Full GC)了1次，FGCT(Full GC Time)花销0.102秒；GCT(GC Time)总花销0.234秒。
分析：其实上边这个查询结果可以直接看出，我们需要加大P（永久代大小）
说明：加载了3683个类，总共占有4355.3字节；卸载了0个类，卸载的类的字节数为0，类的加载与卸载共花销3.16秒
更多的jstat的使用，参看http://my.oschina.net/skyline520/blog/304805
4、jinfo
作用：查看和运行期修改JVM的配置参数
格式：jinfo -flag parameter PID
说明：查看3732进程下的MaxTenuringThreshold参数值。
说明：修改3732进程下的MaxTenuringThreshold参数值，但是windows下失败。
5、jmap
作用：生成堆转储快照和查看最占内存的元素，用于分析内存泄露问题
格式（生成堆转储快照）：jmap -dump:format=b,file=文件名 PID
说明：生成了3732进程的堆转储文件myfile
格式（查看最占内存的元素）：jmap -histo PID
说明：结果自己去看，太多了
6、jhat
作用：分析堆转储快照（与jmap配合）
格式：jhat 文件名
说明：执行上述命令后，打开localhost:7000，找到如下红框部分打开，这里才是我们最关注的东西。
注意：该工具是万不得已才用的。
推出命令使用"ctrl+c"
7、jstack
作用：生成线程快照，定位线程长时间卡顿的原因（线程间死锁、死循环、请求外部资源导致的长时间等待）
格式：jstack -l PID
说明：查看3732进程中的所有线程的堆栈信息
《深入理解Java虚拟机》的作者提供了一个工具jsp页面，使得我们可以在程序运行时，随时运行该jsp页面，来查看线程堆栈信息，代码如下：
1 <%@ page language="java" contentType="text/html; charset=UTF-8" 2 pageEncoding="UTF-8" import="java.util.Map"%> 3 <!DOCTYPE html> 4 <html> 5 <head> 6 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 7 <title>jstack</title> 8 </head> 9 <body> 10 <% 11 for(Map.Entry<Thread, StackTraceElement[]> stackTrace : Thread.getAllStackTraces().entrySet()){ 12 Thread thread = (Thread)stackTrace.getKey(); 13 StackTraceElement[] elements = (StackTraceElement[])stackTrace.getValue(); 14 15 /* if(thread.equals(Thread.currentThread())){ 16 continue; 17 } */ 18 out.println(" 线程："+thread.getName()+" "); 19 for(StackTraceElement ele : elements){ 20 out.println(" "+ele+" "); 21 } 22 } 23 %> 24 </body> 25 </html>
注意：代码中我注释掉一段，是因为想也查出当前线程的堆栈信息，作者并没有这个注释。
总结：
- JVM性能相关的6个常用的JDK命令
- jps：查询JVM中的所有进程，找出将要操作的PID，是所有命令的基础
- jstat：查看相应JVM进程的gc、类加载卸载信息，是没有GUI界面查看JVM运行数据的首选
- jinfo：查看和在运行期动态修改JVM配置参数
- jmap：生成堆转储快照和比较占内存的对象
- jhat：配合jmap分析堆转储日志，除非没有其他工具可做这个事儿，否则就不用该工具
- jstack：生成线程快照，定位线程长时间卡顿的原因（线程间死锁、死循环、请求外部资源导致的长时间等待）
- 输出gc信息到控制台
- -XX:+PrintGCDetails：输出GC的详细信息
- -XX:+PrintGCTimeStamps：输出GC的时间信息
- -XX:+PrintGCApplicatonStoppedTime：GC造成的应用暂停的时间
- -XX:+PrintGCDetails：输出GC的详细信息
- 输出gc信息到文件
- 以上三个参数在这里依旧适用
- -Xloggc:文件路径/gc.log：输出到文件
图形化的JVM性能监控
1、图像化的故障处理工具
- Jconsole
- visualVM
2、Jconsole
进入"E:Javajdk1.6in"，双击"jconsole.exe"，弹出如下框：
说明：这里列出了所有的JVM进程，一个Jconsole进程，一个eclipse（PID：4684），这相当于jps命令。
选中其中一个PID，假设选中了eclipse，双击，出现下图：（注：之后的各个叶签，都是每4秒刷新一次）
"内存"：相当于jstat -gc，在上图中的详细信息部分，该部分对应的信息就是头部图表部分所写的参数（这里是"整个堆"的情况），同时对应的也是右下角部分柱状图所选中的柱子（这里是"堆"），对于"非堆"指的就是"方法区"（或者称为"永久代"）。当然，这里也可以选择时间范围来查看相应的信息。
"类"：相当于jstat -class，列出了装载类和卸载类的相关信息。
"线程"：相当于jstack，折线图显示了线程数目的变化情况，包括峰值线程数量、活动线程数量；左下角展示了所有线程名称。双击相应的线程名称
"VM摘要"：相当于jinfo
最后，测试一下线程死锁的现象。代码如下：
View
Code执行main()方法，之后去查看"线程"标签，点击"检测死锁"，如下：
发现线程Thread-95和Thread-106死锁（彼此拥有对方想要的锁）
分析：
1）Integer缓存机制
Integer.valueOf(int xxx)，该方法为了减少对象的创建，节省内存，会将xxx转化成的Integer对象缓存起来，之后只要是相同的xxx，那么这个方法都会直接从缓存中取出对象来。假设代码中的Integer.valueOf(1)生成的对象是java.lang.Integer@987197，而Integer.valueOf(2)生成的对象是java.lang.Integer@15e293a，那么之后无论调用多少次Integer.valueOf(1)，也无论是哪一个线程去调用该方法，返回的都只是同一个对象java.lang.Integer@987197。也就是说上边的这段代码中的Integer.valueOf(i)只会生成两个不同的对象，就是java.lang.Integer@987197和java.lang.Integer@15e293a，而这两个对象也就是我们的锁对象。
2）死锁发生的时机
假设线程"Thread-95"执行到其第一个synchronized块中时（假设刚刚获取了锁对象java.lang.Integer@987197），这时候CPU时间片切换给了线程"Thread-106"，而"Thread-106"执行其第一个synchronized块（获取了锁对象java.lang.Integer@15e293a），之后"Thread-106"要执行第二个synchronized块儿来获取锁对象java.lang.Integer@987197，这时候就获取不到了，因为这个锁对象正被"Thread-95"所持有，于是"Thread-106"就阻塞在java.lang.Integer@987197这个锁对象上，这时，假设CPU时间片又切换给了"Thread-95"，该线程要执行第二个synchronized块来获取java.lang.Integer@15e293a，就获取不到了，因为该锁对象已被"Thread-106"所持有
3）结果
"Thread-95"持有锁对象java.lang.Integer@987197，阻塞在锁对象java.lang.Integer@15e293a；
"Thread-106"持有锁对象java.lang.Integer@15e293a，阻塞在锁对象java.lang.Integer@987197
3、visualVM
是一块更加全面的GUI监视工具，包含很多插件（需要自己下载），具体的见《深入理解Java虚拟机（第二版）》
JVM调优
1、JVM的调优主要是内存的调优，主要调两个方面：
- 各个代的大小
- 垃圾收集器选择
2、各个代的大小
- 常用的调节参数
- -Xmx
- -Xms
- -Xmn
- -XX:SurvivorRatio
- -XX:MaxTenuringThreshold
- -XX:PermSize
- -XX:MaxPermSize
- 原则
- -Xmx==-Xms：防止堆内存频繁进行调整，调整的时机见《第一章 JVM内存结构》
- -Xmn：通常设为-Xmx/4（这是我在企业中实习时的设置方式，系统运行正常、平稳、速度也快），林昊推荐的是-Xmx/3，所以-Xmn==-Xmx/4~-Xmx/3
- 调节时机：minor GC太频繁
- -Xmn过小：minor GC太频繁；小对象可能也会直接进入年老代，提前导致Full GC
- -Xmn过大：年轻代大了，minor GC的时间变长了；年老代变小了，Full GC会频繁
- 调节策略：若-Xmx可调大，则调大，且保持-Xmn==-Xmx/4~-Xmx/3；若-Xmx不可调大，在保持-Xmn==-Xmx/4~-Xmx/3的范围内增大-Xmn，若-Xmn也不可调了，则试着调大-XX:SurvivorRatio来看看情况
- -XX:SurvivorRatio：默认8
- -XX:SurvivorRatio过大：Eden变大，Survivor变小，minor GC可能减少，但是由于suvivor减小了，所以如果minor GC存活下来的对象大于suvivor，则会直接进入年老代
- -XX:SurvivorRatio过小：Eden变小，Survivor变大，minor GC可能增多，但是由于suvivor变大了，能够存储更多存活下来的对象，进入年老代的对象可能会减少
- -XX:MaxTenuringThreshold：默认为15
- -XX:SurvivorRatio过大：对象在年轻代的存活时间变长，可能在年轻代就被回收掉而不必进入年老代，但是相应的复制的时候survivor区就会被占用更多的空间。
- -XX:SurvivorRatio过大：对象在年轻代的存活时间变短，可能会早早进入年老代而失去在年轻代被回收的机会，但是相应的复制的时候survivor区也就有更多内存了，这样可能会避免部分大对象直接进入年老代
- -XX:MaxPermSize==-XX:PermSize
- 在实际开发中，前台不要使用jsp，使用velocity等模板引擎技术
- 不要引入无关的jar
3、垃圾收集器选择
企业中最常用的两个组合：（这里由于大部分大型企业用的还是JDK1.6，所以G1不说）
关于下边两组垃圾收集器的详细原理见：第五章 JVM垃圾收集器（1）
- Parallel Scavenge/Parallel Old
- 注重吞吐量（吞吐量越大，说明CPU利用率越高）
- 主要用于处理很多的CPU计算任务而用户交互任务较少的情况
- 也用于让JVM自动调优而我们袖手旁观的情况（-XX:+UseParallelOldGC，-XX:GCTimeRatio，-Xmx，-XX:+UseAdaptiveSizePolicy）
- -XX:+UseParallelOldGC：指定使用该组合
- ParNew/CMS
- 注重STW的缩短（该时间越短，用户体验越好，而且会减少部分请求的请求超时问题）
- -XX:+UseConcMarkSweepGC：指定使用该组合
- -XX:CMSInitiatingOccupancyFraction：来指定当年老代空间满了多少后（百分比）进行垃圾回收
- 关于上边两种组合的说明
- 一般而言，在企业中，机器的CPU数量都比较多，且CPU的计算能力也不会成为瓶颈，所以对于CMS的并发标记与并发清除阶段，会占用CPU资源的问题，其实不是大事儿；而对于Parallel的注重吞吐量的问题也就不是什么大事儿了，毕竟CPU是强大的
- 所以，ParNew/CMS是首选（在G1不能用的情况下），Parallel Scavenge/Parallel Old只在想让JVM自动管理内存的情况下使用
注意：在实际调优过程中，可以使用jstat、jconsole、visualVM或GC日志的检测数据来调，具体的示例见《深入理解java虚拟机（第二版）》p142对eclipse运行速度的调优。
关于GC日志的参数含义与每一种垃圾收集器的GC日志的格式，查看《深入理解Java虚拟机（第二版）》的P89和《深入分析Java Web技术内幕（修订版）》的P224