JVM里的GC(Garbage Collection)的算法有很多种,如标记清除收集器,压缩收集器,分代收集器等等,详见HotSpot VM GC 的种类
现在比较常用的是分代收集(generational collection,也是SUN VM使用的,J2SE1.2之后引入),即将内存分为几个区域,将不同生命周期的对象放在不同区域里:young generation,tenured generation和permanet generation。绝大部分的objec被分配在young generation(生命周期短),并且大部分的object在这里die。当young generation满了之后,将引发minor collection(YGC)。在minor collection后存活的object会被移动到tenured generation(生命周期比较长)。最后,tenured generation满之后触发major collection。major collection(Full gc)会触发整个heap的回收,包括回收young generation。permanet generation区域比较稳定,主要存放classloader信息。
young generation有eden、2个survivor 区域组成。其中一个survivor区域一直是空的,是eden区域和另一个survivor区域在下一次copy collection后活着的objecy的目的地。object在survivo区域被复制直到转移到tenured区。
我们要尽量减少 Full gc 的次数(tenured generation一般比较大,收集的时间较长,频繁的Full gc会导致应用的性能收到严重的影响)。
堆内存GC
JVM(采用分代回收的策略),用较高的频率对年轻的对象(young generation)进行YGC,而对老对象(tenuredgeneration)较少(tenuredgeneration 满了后才进行)进行Full GC。这样就不需要每次GC都将内存中所有对象都检查一遍。
非堆内存不GC
GC不会在主程序运行期对PermGen Space进行清理,所以如果你的应用中有很多CLASS(特别是动态生成类,当然permgen space存放的内容不仅限于类)的话,就很可能出现PermGen Space错误。
内存申请、对象衰老过程
一、内存申请过程
二、对象衰老过程
GC类型 | 触发条件 | 触发时发生了什么 | 注意 | 查看方式 |
YGC | eden空间不足 | 清空Eden+from survivor中所有no ref的对象占用的内存 重新调整Eden 和from的大小(parallel GC会触发此项) |
全过程暂停应用 是否为多线程处理由具体的GC决定 |
jstat –gcutil gc log |
FGC | old空间不足 |
清空heap中no ref的对象 permgen中已经被卸载的classloader中加载的class信息 如配置了CollectGenOFirst,则先触发YGC(针对serial GC) 如配置了ScavengeBeforeFullGC,则先触发YGC(针对serial GC) |
全过程暂停应用 是否为多线程处理由具体的GC决定 是否压缩需要看配置的具体GC |
jstat –gcutil gc log |
参考:
http://jiangyongyuan.javaeye.com/blog/356502
http://www.helloying.com/blog/archives/164
http://www.cnblogs.com/redcreen/archive/2011/05/04/2037056.html