1. JVM内存管理：深入垃圾收集器与内存分配策略
http://www.iteye.com/topic/802638
http://www.iteye.com/topic/212967
1 资料
- JDK5.0垃圾收集优化之–Don’t Pause(花钱的年华)
- 编写对GC友好，又不泄漏的代码(花钱的年华)
- JVM调优总结
- JDK 6所有选项及默认值
2 GC日志打印
GC调优是个很实验很伽利略的活儿，GC日志是先决的数据参考和最终验证：
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps(GC发生的时间)
-XX:+PrintGCApplicationStoppedTime(GC消耗了多少时间)
-XX:+PrintGCApplicationConcurrentTime(GC之间运行了多少时间)
3 收集器选择
CMS收集器：暂停时间优先
配置参数：-XX:+UseConcMarkSweepGC
已默认无需配置的参数：-XX:+UseParNewGC(Parallel收集新生代) -XX:+CMSPermGenSweepingEnabled(CMS收集持久代) -XX:UseCMSCompactAtFullCollection(full gc时压缩年老代)
初始效果：1g堆内存的新生代约60m，minor gc约5-20毫秒，full gc约130毫秒。
Parallel收集器：吞吐量优先
配置参数： -XX:+UseParallelGC -XX:+UseParallelOldGC(Parallel收集年老代，从JDK6.0开始支持)
已默认无需配置的参数： -XX:+UseAdaptiveSizePolicy(动态调整新生代大小)
初始效果：1g堆内存的新生代约90-110m(动态调整)，minor gc约5-20毫秒，full gc有无UseParallelOldGC 参数分别为1.3/1.1秒，差别不大。
另外-XX:MaxGCPauseMillis=100 设置minor gc的期望最大时间，JVM会以此来调整新生代的大小，但在此测试环境中对象死的太快，此参数作用不大。
4 调优实战
Parallel收集高达1秒的暂停时间基本不可忍受，所以选择CMS收集器。
在被压测的Mule 2.0应用里，每秒都有大约400M的海量短命对象产生：
- 因为默认60M的新生代太小了，频繁发生minor gc，大约0.2秒就进行一次。
- 因为CMS收集器中MaxTenuringThreshold(生代对象撑过过多少次minor gc才进入年老代的设置)默认0，存活的临时对象不经过Survivor区直接进入年老代，不久就占满年老代发生full gc。
对这两个参数的调优，既要改善上面两种情况，又要避免新生代过大，复制次数过多造成minor gc的暂停时间过长。
- 使用-Xmn调到1/3 总内存。观察后设置-Xmn500M，新生代实际约460m。(用-XX:NewRatio设置无效，只能用 -Xmn)。
- 添加-XX:+PrintTenuringDistribution 参数观察各个Age的对象总大小，观察后设置-XX:MaxTenuringThreshold=5。
优化后，大约1.1秒才发生一次minor gc，且速度依然保持在15-20ms之间。同时年老代的增长速度大大减缓，很久才发生一次full gc，
参数定稿：
-server -Xms1024m -Xmx1024m -Xmn500m -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=5
-XX:+ExplicitGCInvokesConcurrent
最后服务处理速度从1180 tps 上升到1380 tps，调整两个参数提升17%的性能还是笔很划算的买卖。
另外，JDK6 Update 7自带了一个VisualVM工具，内里就是之前也有用过的Netbean Profiler，类似JConsole一样使用，可以看到线程状态，内存中对象以及方法的CPU时间等调优重要参考依据。免费捆绑啊，Sun 这样搞法，其他做Profiler的公司要关门了。
3.JVM gc参数设置与分析
来自：http://hi.baidu.com/i1see1you/blog/item/7ba0d250c30131481038c20c.html
一.概述
java的最大好处是自动垃圾回收，这样就无需我们手动的释放对象空间了，但是也产生了相应的负效果，gc是需要时间和资源的，不好的gc会严重影响系统的系能，因此良好的gc是JVM的高性能的保证。JVM堆分为新生代，旧生代和年老代，新生代可用的gc方式有：串行gc（Serial Copying），并行回收gc(Parellel Scavenge)，并行gc(ParNew)，旧生代和年老代可用的gc方式有串行gc(Serial MSC),并行gc(Parallel MSC)，并发gc（CMS）。
二.回收方式的选择
jvm有client和server两种模式，这两种模式的gc默认方式是不同的：
clien模式下，新生代选择的是串行gc，旧生代选择的是串行gc
server模式下，新生代选择的是并行回收gc，旧生代选择的是并行gc
一般来说我们系统应用选择有两种方式：吞吐量优先和暂停时间优先，对于吞吐量优先的采用server默认的并行gc方式，对于暂停时间优先的选用并发gc（CMS）方式。
三.CMS gc
CMS，全称Concurrent Low Pause Collector，是jdk1.4后期版本开始引入的新gc算法，在jdk5和jdk6中得到了进一步改进，它的主要适合场景是对响应时间的重要性需求大于对吞吐量的要求，能够承受垃圾回收线程和应用线程共享处理器资源，并且应用中存在比较多的长生命周期的对象的应用。CMS是用于对tenured generation的回收，也就是年老代的回收，目标是尽量减少应用的暂停时间，减少full gc发生的几率，利用和应用程序线程并发的垃圾回收线程来标记清除年老代。在我们的应用中，因为有缓存的存在，并且对于响应时间也有比较高的要求，因此希望能尝试使用CMS来替代默认的server型JVM使用的并行收集器，以便获得更短的垃圾回收的暂停时间，提高程序的响应性。
CMS并非没有暂停，而是用两次短暂停来替代串行标记整理算法的长暂停，它的收集周期是这样：
初始标记(CMS-initial-mark) -> 并发标记(CMS-concurrent-mark) -> 重新标记(CMS-remark) -> 并发清除(CMS-concurrent-sweep) ->并发重设状态等待下次CMS的触发(CMS-concurrent-reset)。
其中的1，3两个步骤需要暂停所有的应用程序线程的。第一次暂停从root对象开始标记存活的对象，这个阶段称为初始标记；第二次暂停是在并发标记之后，暂停所有应用程序线程，重新标记并发标记阶段遗漏的对象（在并发标记阶段结束后对象状态的更新导致）。第一次暂停会比较短，第二次暂停通常会比较长，并且 remark这个阶段可以并行标记。
而并发标记、并发清除、并发重设阶段的所谓并发，是指一个或者多个垃圾回收线程和应用程序线程并发地运行，垃圾回收线程不会暂停应用程序的执行，如果你有多于一个处理器，那么并发收集线程将与应用线程在不同的处理器上运行，显然，这样的开销就是会降低应用的吞吐量。Remark阶段的并行，是指暂停了所有应用程序后，启动一定数目的垃圾回收进程进行并行标记，此时的应用线程是暂停的。
四.full gc
full gc是对新生代，旧生代，以及持久代的统一回收，由于是对整个空间的回收，因此比较慢，系统中应当尽量减少full gc的次数。
如下几种情况下会发生full gc：
《旧生代空间不足
《持久代空间不足
《CMS GC时出现了promotion failed和concurrent mode failure
《统计得到新生代minor gc时晋升到旧生代的平均大小小于旧生代剩余空间
《直接调用System.gc，可以DisableExplicitGC来禁止
《存在rmi调用时，默认会每分钟执行一次System.gc，可以通过-Dsun.rmi.dgc.server.gcInterval=3600000来设置大点的间隔。
五.示例
下面对如下的参数进行分析：
JAVA_OPTS=”-server -Xms2000m -Xmx2000m -Xmn800m -XX:PermSize=64m -XX:MaxPermSize=256m -XX:SurvivorRatio=4
-verbose:gc -Xloggc:$CATALINA_HOME/logs/gc.log -Djava.awt.headless=true -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Dsun.rmi.dgc.server.gcInterval=600000 -Dsun.rmi.dgc.client.gcInterval=600000
-XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=15″
-Xms2000m -Xmx2000m -Xmn800m -XX:PermSize=64m -XX:MaxPermSize=256m
Xms，即为jvm启动时得JVM初始堆大小,Xmx为jvm的最大堆大小，xmn为新生代的大小，permsize为永久代的初始大小，MaxPermSize为永久代的最大空间。
-XX:SurvivorRatio=4
SurvivorRatio为新生代空间中的Eden区和救助空间Survivor区的大小比值，默认是32，也就是说Eden区是 Survivor区的32倍大小，要注意Survivo是有两个区的，因此Surivivor其实占整个young genertation的1/34。调小这个参数将增大survivor区，让对象尽量在survitor区呆长一点，减少进入年老代的对象。去掉救助空间的想法是让大部分不能马上回收的数据尽快进入年老代，加快年老代的回收频率，减少年老代暴涨的可能性，这个是通过将-XX:SurvivorRatio 设置成比较大的值（比如65536)来做到。
-verbose:gc -Xloggc:$CATALINA_HOME/logs/gc.log
将虚拟机每次垃圾回收的信息写到日志文件中，文件名由file指定，文件格式是平文件，内容和-verbose:gc输出内容相同。
-Djava.awt.headless=true
Headless模式是系统的一种配置模式。在该模式下，系统缺少了显示设备、键盘或鼠标。
-XX:+PrintGCTimeStamps -XX:+PrintGCDetails
设置gc日志的格式
-Dsun.rmi.dgc.server.gcInterval=600000 -Dsun.rmi.dgc.client.gcInterval=600000
指定rmi调用时gc的时间间隔
-XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=15
采用并发gc方式，经过15次minor gc 后进入年老代六.一些常见问题1.为了避免Perm区满引起的full gc，建议开启CMS回收Perm区选项：
+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled
2.默认CMS是在tenured generation沾满68%的时候开始进行CMS收集，如果你的年老代增长不是那么快，并且希望降低CMS次数的话，可以适当调高此值：
-XX:CMSInitiatingOccupancyFraction=80
3.遇到两种fail引起full gc：Prommotion failed和Concurrent mode failed时：
Prommot
