之前几篇我们介绍了jvm的内存模型以及垃圾回收机制，而本篇我们将介绍几个JVM中对象在分配内存是应该遵循的策略。毕竟，想要去优化程序，不仅要考虑垃圾回收的过程，还要从对象内存分配的角度减少gc的代价。

一、gc日志格式

在这里先介绍一下gc日志的格式，分析gc日志是了解gc过程最直接的方式。对于大量的日志分析，直接查看日志文件当然不方便，我们一般会使用日志分析工具，后边会有介绍，但是对于简短的日志（如十几条），一般直接查看就行了。开启日志输出的JVM参数如下：

-XX:+PrintGCDetails     //打印gc日志
-XX:+PrintGCDateStamps    //打印时间
-Xloggc:gc.log   //输出路径

对应的日志输出格式如下(采用不同参数或不同虚拟机可能不同，但大同小异)：

2014-03-09T18:10:47.639+0800: 36.408: [GC 36.408: [DefNew: 35072K->4352K(39424K), 0.0108988 secs] 75088K->45293K(126848K), 0.0109419 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 
2014-03-09T18:10:48.562+0800: 37.331: [Full GC 37.343: [Tenured: 40941K->42890K(87424K), 0.1340821 secs] 62210K->42890K(126848K), [Perm : 36863K->36863K(36864K)], 0.1341736 secs] [Times: user=0.13 sys=0.00, real=0.15 secs]

35072K->4352K(39424K):gc前使用内存大小->gc后使用大小(该区域总大小)
    2014-03-09T18:10:47.639+0800: gc时间
    36.408: gc耗时
    GC 36.408:  表示停顿类型和停顿时间，如果是Full表示gc是Stop-The-World的
    DefNew: Tenured:  Perm : gc发生的区域，DefNew年轻代；Tenured年老代；Perm永久代
    Times: user=0.13 sys=0.00, real=0.15 secs user：用户态耗时；sys：内核态耗时；real：gc从开始到结束消耗的Wall Clock Time耗时（墙钟时间，名字好怪，包括各种非运算的等待耗时和cpu耗时）

二、内存分配策略

1、对象优先在Eden分配

新的对象大多数情况下在Eden去分配，这样在Eden区域没有足够空间时，JVM会首先进行Minor Gc，仅对Eden进行gc，并将符合条件的对象移至年老代。这样如果Eden在gc后满足新对象的空间需求，则能避免进行Full GC。

2、大对象直接进入年老代

这一点十分好理解，多数情况下大对象的生命周期是相对较长的，而大对象如果分配在Eden，不仅占用大量空间，触发gc，还可能会在Eden区/两个Survivor区之间来回复制，十分耗费资源。因此，多数时候对于大对象，应该直接分配至年老代，开始用-XX:PertenureSizeThreshold参数指定直接分配年老代的大小。

3、长期存活的对象进入年老代

一般经过多次Minor GC而不死的对象，继续活下去的可能新更大，因此应该进入年老代。为了判断哪些对象长期存活，虚拟机给每个对象都定义了一个Age计数器，没经历一次Minor GC就+1，可以通过-XX:MaxTenuringThreshold的值来决定age达到多少时进入年老代。

4、动态对象年龄判断

为了能更好地适应不同程序的内存状况，虚拟机并不总是要求对象的年龄必须达到MaxTenuringThreshold 才能晋升老年代，如果在 Survivor 空间中相同年龄所有对象大小的总和大于Survivor 空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold 中要求的年龄。

5、空间分配担保

在发生 Minor GC 时，虚拟机会检测之前每次晋升到老年代的平均大小是否大于老年代的剩余空间大小，如果大于，则改为直接进行一次 Full GC。如果小于，则查看 HandlePromotionFailure 设置是否允许担保失败；如果允许，那只会进行 Minor GC；如果不允许，则也要改为进行一次 Full GC。 前面提到过，新生代使用复制收集算法，但为了内存利用率，只使用其中一个 Survivor 空间来作为轮换备份，因此当出现大量对象在 Minor GC 后仍然存活的情况时（最极端就是内存回收后新生代中所有对象都存活），就需要老年代进行分配担保，让 Survivor 无法容纳的对象直接进入老年代。与生活中的贷款担保类似，老年代要进行这样的担保，前提是老年代本身还有容纳这些对象的剩余空间，一共有多少对象会活下来，在实际完成内存回收之前是无法明确知道的，所以只好取之前每一次回收晋升到老年代对象容量的平均大小值作为经验值，与老年代的剩余空间进行比较，决定是否进行 Full GC来让老年代腾出更多空间。

本篇介绍完毕，下一篇将介绍JVM监控相关的一些工具。