root@mobile-site2:/data/logs/pay1.api.xxx.com# jmap -heap 8379
Attaching to process ID 8379, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 23.7-b01
using thread-local object allocation.
Parallel GC with 13 thread(s)
Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 1073741824 (1024.0MB)
NewSize = 1310720 (1.25MB)
MaxNewSize = 17592186044415 MB
OldSize = 5439488 (5.1875MB)
NewRatio = 2
SurvivorRatio = 8
PermSize = 134217728 (128.0MB)
MaxPermSize = 134217728 (128.0MB)
G1HeapRegionSize = 0 (0.0MB)
Heap Usage:
PS Young Generation
Eden Space:
capacity = 348848128 (332.6875MB)
used = 194877664 (185.84982299804688MB)
free = 153970464 (146.83767700195312MB)
55.863181814179036% used
From Space:
capacity = 4390912 (4.1875MB)
used = 0 (0.0MB)
free = 4390912 (4.1875MB)
0.0% used
To Space:
capacity = 4521984 (4.3125MB)
used = 0 (0.0MB)
free = 4521984 (4.3125MB)
0.0% used
PS Old Generation
capacity = 715849728 (682.6875MB)
used = 30494688 (29.082000732421875MB)
free = 685355040 (653.6054992675781MB)
4.259928698331502% used
PS Perm Generation
capacity = 134217728 (128.0MB)
used = 45301880 (43.20323944091797MB)
free = 88915848 (84.79676055908203MB)
33.75253081321716% used
20226 interned Strings occupying 2414832 bytes.
===============================================================
两次间隔12小时
^Croot@mobile-site1:/data/logs/pay1.api.xxx.com# jstat -gcutil 8533 1000 100
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 61.76 84.46 10.44 41.00 5009 32.750 158 19.519 52.269
0.00 61.76 84.46 10.44 41.00 5009 32.750 158 19.519 52.269
0.00 61.76 84.61 10.44 41.00 5009 32.750 158 19.519 52.269
0.00 61.76 88.24 10.44 41.00 5009 32.750 158 19.519 52.269
0.00 61.76 89.61 10.44 41.00 5009 32.750 158 19.519 52.269
0.00 61.76 89.61 10.44 41.00 5009 32.750 158 19.519 52.269
0.00 61.76 94.61 10.44 41.00 5009 32.750 158 19.519 52.269
root@mobile-site1:/data/logs/pay1.api.xxx.com# jstat -gcutil 8533 1000 100
S0 S1 E O P YGC YGCT FGC FGCT GCT
69.60 0.00 62.84 8.21 40.94 5142 33.704 168 20.788 54.492
69.60 0.00 62.84 8.21 40.94 5142 33.704 168 20.788 54.492
69.60 0.00 62.84 8.21 40.94 5142 33.704 168 20.788 54.492
69.60 0.00 63.77 8.21 40.94 5142 33.704 168 20.788 54.492
69.60 0.00 63.77 8.21 40.94 5142 33.704 168 20.788 54.492
69.60 0.00 63.77 8.21 40.94 5142 33.704 168 20.788 54.492
69.60 0.00 63.77 8.21 40.94 5142 33.704 168 20.788 54.492
结论：年轻代:984ms 12h 133 req 7.1723ms/per
结论：年老代:1269ms 12h 10 req 129.00ms/per
复制(Copying) 新生代
标记整理(Mark-Compact) 年老代
标记-清除（Mark-Sweep） 没有用
串行收集器:单核 小应用
并行收集器:吞吐量优先 吞吐量大，后台系统。般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是，这样可以尽可能回收掉大部分短期对象，减少中期的对象，而年老代尽存放长期存活对象
并发收集器:中断优先，实时性高， 交易系统。并发收集器主要是保证系统的响应时间，减少垃圾收集时的停顿时间。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。 花在年轻代和年老代回收上的时间比例 减少年轻代和年老代花费的时间，一般会提高应用的效率
并行：
jdk1.5年轻代默认 -XX:+UseParallelGC ，年老代只有:-XX:+UseSerialGC
jdk1.6年老代代支持，需设置 -XX:+UseParallelOldGC
串行 serial -XX:+UseSerialGC：策略为年轻代串行复制，年老代串行标记整理
并发 parallel -XX:+UseParallelGC：这是JDK5 -server的默认值。策略为：年轻代：暂停应用程序，多个垃圾收集线程并行的复制收集，线程数默认为CPU个数，CPU很多时，可用-XX:ParallelGCThreads= 设定线程数。年老代：暂停应用程序，与串行收集器一样，单垃圾收集线程标记整理。
并行 Concurrent -XX:+UseConcMarkSweepGC：这是以上两种策略的升级版，策略为：年轻代：同样是暂停应用程序，多个垃圾收集线程并行的复制收集。年老代：则只有两次短暂停，其他时间应用程序与收集线程并发的清除
使用G1收集器时，Java堆的内存布局与就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。
G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回价值最大的Region（这也就是Garbage-First名称的来由）。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内获可以获取尽可能高的收集效率。G1把内存“化整为零”的思路.
参数介绍：http://www.blogjava.net/chhbjh/archive/2012/01/28/368936.html
http://www.blogjava.net/bitbit/archive/2009/11/30/304247.html
http://developer.51cto.com/art/201311/417461.htm jdk命令
http://blog.csdn.net/on_my_way20xx/article/details/8562055
http://my.oschina.net/u/565871/blog/183346
