jvm堆内存和GC简介
最近经常遇到jvm内存问题，觉得还是有必要整理下jvm内存的相关逻辑，这里只描述jvm堆内存，对外内存暂不阐述。
jvm内存简图
-
jvm内存分为堆内存和非堆内存，堆内存分为年轻代、老年代，非堆内存里只有个永久代。
-
年轻代分为生成区（Eden）和幸存区（Survivor），幸存区由FromSpace和Tospace两部分组成，默认情况下，内存大小比例：Eden：FromSpace：ToSpace 为 8:1:1。
-
堆内存存放的是对象，垃圾收集器回收的就是这里的对象，不同区域的对象根据不同的GC算法回收，比如年轻代对应Minor GC，老年代对应Major GC。
-
非堆内存即永久代，也称为方法区，存储的是程序运行时长期存活的对象，比如类的元数据、方法、常量、属性等。
-
在jdk1.8废弃了永久代，使用元空间（MetaSpace）取而代之，元空间存储的对象与永久代相同，区别是：元空间并不在jvm中，使用的是本地内存。
为什么移除永久代呢
为融合HotSpot JVM与JRockit VM（新JVM技术）而做出的改变，因为JRockit没有永久代。
分代概念
首先，GC是Garbage Collection，即垃圾回收。
新生成的对象首先存放在生成区，当生成区满了，触发Minor GC，存活下来的对象转移到Survivor0，即FromSpace，Survivor0区满后触发执行Minor GC，存活对象移动到Suvivor1区，即ToSpace，经过多次Minor GC仍然存活的对象转移到老年代。
所以老年代存储的是长期活动的对象，当老年代满了会触发Major GC。
Minor GC和Major GC是俗称，有些情况下Major GC和Full GC是等价的，如果出发了Full GC,那么所有线程必须等待GC完成才能继续（见GC分类和算法）。
分代原因
将对象根据存活概率进行分类，对存活时间长的对象，放到固定区，从而减少扫描垃圾时间及GC频率。针对分类进行不同的垃圾回收算法，对算法扬长避短。
为什么幸存区分为大小相同的两部分：S0，S1
主要为了解决碎片化，因为回收一部分对象后，剩余对象占用的内存不连续，也就是碎片化，过于严重的话，当前连续的内存不够新对象存放就会触发GC，这样会提高GC的次数，降低性能，当S0 GC后存活对象转移到S1后存活对象占用的就是连续的内存。
GC分类和相关算法
我们来看下GC分类，才能清楚什么时候触发Full GC、和非Full GC，GC大致分为两种：
- Partial GC：并不收集整个GC堆的模式，即可以理解为非Full GC
- Young GC：只收集young gen的GC
- Old GC：只收集old gen的GC。只有CMS有这个模式
- Mixed GC：收集整个young gen以及部分old gen的GC。只有G1有这个模式
- Full GC：收集整个堆，包括young gen、old gen、perm gen（如果存在的话）等所有部分的模式。
上面说的CMS和G1都是GC的算法，相关GC算法如下：
Serial GC算法：Serial Young GC ＋ Serial Old GC （实际上它是全局范围的Full GC）；
Parallel GC算法：Parallel Young GC ＋ 非并行的PS MarkSweep GC / 并行的Parallel Old GC（这俩实际上也是全局范围的Full GC），选PS MarkSweep GC 还是 Parallel Old GC 由参数UseParallelOldGC来控制；
CMS算法：ParNew（Young）GC + CMS（Old）GC ＋ Full GC for CMS算法；
G1 GC算法：Young GC + mixed GC（新生代，再加上部分老生代）＋ Full GC for G1 GC算法（应对G1 GC算法某些时候的不赶趟，开销很大）；
GC触发条件
-
Young GC：各种Young GC触发的条件都是Eden区满了。
-
Serial Old GC／PS MarkSweep GC／Parallel Old GC：当准备要触发一次young GC时，如果发现统计数据说之前young GC的平均晋升大小比目前old gen剩余的空间大，则不会触发young GC而是转为触发full GC。
-
Full GC for CMS：老年代使用比率超过某个值。
-
Full GC for G1 GC：Heap使用比率超过某个值。
-
如果有perm gen的话，要在perm gen分配空间但已经没有足够空间时，也要触发一次full GC。
小结：不同算法对应的GC回收条件是不同的。
GC方式
标记-清除（Mark-Sweep）
GC分为两个阶段，标记和清除。首先标记所有可回收的对象，在标记完成后统一回收所有被标记的对象。同时会产生不连续的内存碎片，碎片过多会导致以后程序运行时需要分配较大对象时，无法找到足够的连续内存，而不得已再次触发GC。
红色代表被标记的可回收对象，绿色代表存活对象
清除后如下：
复制（Copy）
将内存按容量划分为两块，每次只使用其中一块。当这一块内存用完了，就将存活的对象复制到另一块上，然后再把已使用的内存空间一次清理掉。这样使得每次都是对半个内存区回收，也不用考虑内存碎片问题，简单高效。缺点需要两倍的内存空间。
清除前后如下：
标记-整理（Mark-Compact）
也分为两个阶段，首先标记可回收的对象，再将存活的对象都向一端移动，然后清理掉边界以外的内存。此方 法避免标记-清除算法的碎片问题，同时也避免了复制算法的空间问题。
一般年轻代中执行GC后，会有少量的对象存活，就会选用复制算法，只要付出少量的存活对象复制成本就可以 完成收集。而老年代中因为对象存活率高，没有额外过多内存空间分配，就需要使用标记-清理或者标记-整理算法来进行回收。
清除前后如下：
GC算法参数
| 参数 | 描述 |
|---|---|
| -XX:+UseSerialGC | 串行收集器 |
| -XX:+UseParallelGC | 并行收集器 |
| -XX:+UseParallelGCThreads=8 | 并行收集器线程数，同时有多少个线程进行垃圾回收，一般与CPU数量相等 |
| -XX:+UseParallelOldGC | 指定老年代为并行收集 |
| -XX:+UseConcMarkSweepGC | CMS收集器（并发收集器） |
| -XX:+UseCMSCompactAtFullCollection | 开启内存空间压缩和整理，防止过多内存碎片 |
| -XX:CMSFullGCsBeforeCompaction=0 | 表示多少次Full GC后开始压缩和整理，0表示每次Full GC后立即执行压缩和整理 |
| -XX:CMSInitiatingOccupancyFraction=80% | 表示老年代内存空间使用80%时开始执行CMS收集，防止过多的Full GC |
| -XX:+UseG1GC | G1收集器 |
| -XX:MaxTenuringThreshold=0 | 在年轻代经过几次GC后还存活，就进入老年代，0表示直接进入老年代 |
OOM原因
1）老年代内存不足：java.lang.OutOfMemoryError:Javaheapspace
2）永久代内存不足：java.lang.OutOfMemoryError:PermGenspace
3）代码bug，占用内存无法及时回收。
可以通过添加个参数-XX:+HeapDumpOnOutMemoryError，让虚拟机在出现内存溢出异常时Dump出当前的内存堆转储快照以便事后分析。
