JVM区域总体分两类，heap区和非heap区。
heap区又分为：
- Eden Space（伊甸园）、
- Survivor Space(幸存者区)、
- Old Gen（老年代）。

非heap区又分：
- Code Cache(代码缓存区)；
- Perm Gen（永久代）；
- Jvm Stack(java虚拟机栈)；
- Local Method Statck(本地方法栈)；

　　年轻代/新生代:

　　　　所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。年轻代分三个区。一个Eden区，两个Survivor区(一般而言)。大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当这个Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当这个Survivor去也满了的时候，从第一个Survivor区复制过来的并且此时还存活的对象，将被复制“年老区(Tenured)”。需要注意，Survivor的两个区是对称的，没先后关系，所以同一个区中可能同时存在从Eden复制过来对象，和从前一个Survivor复制过来的对象，而复制到年老区的只有从第一个Survivor去过来的对象。而且，Survivor区总有一个是空的。同时，根据程序需要，Survivor区是可以配置为多个的（多于两个），这样可以增加对象在年轻代中的存在时间，减少被放到年老代的可能。

　　年老代/老年代:

　　　　在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。

　　持久代:

　　　　用于存放静态文件，如今Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代大小通过-XX:MaxPermSize=<N>进行设置。

　　年轻代中的GC

　　 HotSpot JVM把年轻代分为了三部分：1个Eden区和2个Survivor区（分别叫from和to）。默认比例为8：1,为啥默认会是这个比例，接下来我们会聊到。一般情况下，新创建的对象都会被分配到Eden区(一些大对象特殊处理),这些对象经过第一次Minor GC后，如果仍然存活，将会被移到Survivor区。对象在Survivor区中每熬过一次Minor GC，年龄就会增加1岁，当它的年龄增加到一定程度时，就会被移动到年老代中。

　　　因为年轻代中的对象基本都是朝生夕死的(80%以上)，所以在年轻代的垃圾回收算法使用的是复制算法，复制算法的基本思想就是将内存分为两块，每次只用其中一块，当这一块内存用完，就将还活着的对象复制到另外一块上面。复制算法不会产生内存碎片。

　　　在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor区“To”是空的。紧接着进行GC，Eden区中所有存活的对象都会被复制到“To”，而在“From”区中，仍存活的对象会根据他们的年龄值来决定去向。年龄达到一定值(年龄阈值，可以通过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中，没有达到阈值的对象会被复制到“To”区域。经过这次GC后，Eden区和From区已经被清空。这个时候，“From”和“To”会交换他们的角色，也就是新的“To”就是上次GC前的“From”，新的“From”就是上次GC前的“To”。不管怎样，都会保证名为To的Survivor区域是空的。Minor GC会一直重复这样的过程，直到“To”区被填满，“To”区被填满之后，会将所有对象移动到年老代中。

　　内存申请过程

1. JVM会试图为相关Java对象在Eden中初始化一块内存区域；
2. 当Eden空间足够时，内存申请结束。否则到下一步；
3. JVM试图释放在Eden中所有不活跃的对象（minor collection），释放后若Eden空间仍然不足以放入新对象，则试图将部分Eden中活跃对象放入Survivor区；
4. Survivor区被用来作为Eden及old的中间交换区域，当old区空间足够时，Survivor区的对象会被移到Old区，否则会被保留在Survivor区；
5. 当old区空间不够时，JVM会在old区进行major collection；
6. 完全垃圾收集后，若Survivor及old区仍然无法存放从Eden复制过来的部分对象，导致JVM无法在Eden区为新对象创建内存区域，则出现"Out of memory错误"；
内存分配：
1、对象优先在EDEN分配
2、大对象直接进入老年代
3、长期存活的对象将进入老年代
4、适龄对象也可能进入老年代：动态对象年龄判断

对象衰老过程

新创建的对象的内存都分配自eden。Minor collection的过程就是将eden和在用survivor space中的活对象copy到空闲survivor space中。对象在young generation里经历了一定次数(可以通过参数配置)的minor collection后，就会被移到old generation中，称为tenuring。

GC触发条件

GC类型

触发条件

触发时发生了什么

注意

查看方式

Minor GC

eden空间不足

（1）清空Eden+from survivor中所有no ref（无引用）的对象占用的内存
（2）将eden+from survivor中所有存活的对象copy到to survivor中
（3）一些对象将晋升到old中:
▲to sur放不下的
▲存活次数超过turning threshold中的
▲重新计算tenuring threshold （年龄计数器）(serial parallel GC会触发此项)

▲重新调整Eden 和from的大小(parallel GC会触发此项)

全过程暂停应用
是否为多线程处理由具体的GC决定

jstat –gcutil gc log

Full
GC

（1）old空间不足
（2）perm空间不足
（3）显示调用System.GC, RMI等的定时触发
（4）YGC时的悲观策略
（5）dump live的内存信息时(jmap –dump:live)

（1）清空heap中no ref的对象
（2）permgen（永久代）中已经被卸载的classloader中加载的class信息
（3）如配置了CollectGenOFirst,则先触发YGC(针对serial GC)
（4）如配置了ScavengeBeforeFullGC,则先触发YGC(针对serial GC)

全过程暂停应用
是否为多线程处理由具体的GC决定

是否压缩需要看配置的具体GC

jstat –gcutil gc log

　　总结一下：

　　　　1、对象优先在Eden分配，这里大部分对象具有朝生夕灭的特征，Minor GC主要清理该处
　　　　2、大对象（占内存大）、老对象（使用频繁）

　　　　3、Survivor无法容纳的对象，将进入老年代，Full GC的主要清理该处

JVM的GC机制　　

　　JVM有2个GC线程

　　第一个线程负责回收Heap的Young区
　　第二个线程在Heap不足时，遍历Heap，将Young 区升级为Older区

　　Older区的大小等于-Xmx减去-Xmn，不能将-Xms的值设的过大，因为第二个线程被迫运行会降低JVM的性能。

　　堆内存GC

　　JVM(采用分代回收的策略)，用较高的频率对年轻的对象(young generation)进行YGC，而对老对象(tenured generation)较少(tenured generation 满了后才进行)进行Full GC。这样就不需要每次GC都将内存中所有对象都检查一遍。

　　非堆内存不GC

　　GC不会在主程序运行期对PermGen Space进行清理，所以如果你的应用中有很多CLASS(特别是动态生成类，当然permgen space存放的内容不仅限于类)的话,就很可能出现PermGen Space错误。

监视JVM GC

　　监视JVM GC，可以用JDK中的jstat工具，也可以在java程序启动的opt里加上如下几个参数（注:这两个参数只针对SUN的HotSpotVM）：

-XX:-PrintGCPrintmessagesatgarbagecollection.Manageable.
-XX:-PrintGCDetailsPrintmoredetailsatgarbagecollection.Manageable.(Introducedin1.4.0.)
-XX:-PrintGCTimeStampsPrinttimestampsatgarbagecollection.Manageable(Introducedin1.4.0.)

　　当把-XX:-PrintGCDetails加入到javaopt里以后可以看见如下输出：

　　[GC[DefNew:34538K->2311K(36352K),0.0232439secs]45898K->15874K(520320K),0.0233874secs]

　　[FullGC[Tenured:13563K->15402K(483968K),0.2368177secs]21163K->15402K(520320K),[Perm:28671K->28635K(28672K)],0.2371537secs]

　　他们分别显示了JVM GC的过程，清理出了多少空间。第一行GC使用的是‘普通GC’(MinorCollections)，第二行使用的是‘全GC’(MajorCollections)。他们的区别很大，在第一行最后我们可以看见他的时间是0.0233874秒，而第二行的FullGC的时间是0.2371537秒。第二行的时间是第一行的接近10倍，也就是我们这次调优的重点，减少FullGC的次数，以为FullGC会暂停程序比较长的时间，如果FullGC的次数比较多。程序就会经常性的假死。

注：

　　GC信息的格式

　　[GC [<collector>: <starting occupancy1> -> <ending occupancy1>, <pause time1> secs] <starting occupancy3> -> <ending occupancy3>, <pause time3> secs]
　　<collector> GC为minor收集过程中使用的垃圾收集器起的内部名称.
　　<starting occupancy1> young generation 在进行垃圾收集前被对象使用的存储空间.
　　<ending occupancy1> young generation 在进行垃圾收集后被对象使用的存储空间
　　<pause time1> minor收集使应用暂停的时间长短(秒)
　　<starting occupancy3> 整个堆(Heap Size)在进行垃圾收集前被对象使用的存储空间
　　<ending occupancy3> 整个堆(Heap Size)在进行垃圾收集后被对象使用的存储空间
　　<pause time3> 整个垃圾收集使应用暂停的时间长短(秒),包括major收集使应用暂停的时间(如果发生了major收集).

GC信息的选项

　　-XX:+PrintGCDetails 显示GC的详细信息
　　-XX:+PrintGCApplicationConcurrentTime 打印应用执行的时间
　　-XX:+PrintGCApplicationStoppedTime 打印应用被暂停的时间

collector收集器的种类

GC在 HotSpot VM 5.0里有四种：

incremental (sometimes called train) low pause collector已被废弃,不在介绍.

类别	serial collector	parallel collector ( throughput collector )	concurrent collector (concurrent low pause collector)
介绍	单线程收集器使用单线程去完成所有的gc工作，没有线程间的通信，这种方式会相对高效	并行收集器使用多线程的方式，利用多CUP来提高GC的效率主要以到达一定的吞吐量为目标	并发收集器使用多线程的方式,利用多CUP来提高GC的效率并发完成大部分工作，使得gc pause短
试用场景	单处理器机器且没有pause time的要求	适用于科学技术和后台处理有中规模/大规模数据集大小的应用且运行在多处理器上，关注吞吐量(throughput)	适合中规模/大规模数据集大小的应用，应用服务器,电信领域关注response time，而不是throughput
使用	Client模式下默认可使用可用-XX:+UseSerialGC强制使用优点:对server应用没什么优点缺点:慢,不能充分发挥硬件资源	Server模式下默认 --YGC:PS FGC:Parallel MSC 可用-XX:+UseParallelGC或-XX:+UseParallelOldGC强制指定 --ParallelGC代表FGC为Parallel MSC --ParallelOldGC代表FGC为Parallel Compacting 优点:高效缺点:当heap变大后,造成的暂停时间会变得比较长	可用-XX:+UseConcMarkSweepGC强制指定优点: 对old进行回收时,对应用造成的暂停时间非常端,适合对latency要求比较高的应用缺点: 1.内存碎片和浮动垃圾 2.old去的内存分配效率低 3.回收的整个耗时比较长 4.和应用争抢CPU
内存回收触发	YGC eden空间不足 FGC old空间不足 perm空间不足显示调用System.gc() ,包括RMI等的定时触发 YGC时的悲观策略 dump live的内存信息时(jmap –dump:live)	YGC eden空间不足 FGC old空间不足 perm空间不足显示调用System.gc() ,包括RMI等的定时触发 YGC时的悲观策略--YGC前&YGC后 dump live的内存信息时(jmap –dump:live)	YGC eden空间不足 CMS GC 1.old Gen的使用率大的一定的比率默认为92% 2.配置了CMSClassUnloadingEnabled,且Perm Gen的使用达到一定的比率默认为92% 3.Hotspot自己根据估计决定是否要触法 4.在配置了ExplictGCInvokesConcurrent的情况下显示调用了System.gc. Full GC(Serial MSC) promotion failed 或 concurrent Mode Failure时;
内存回收触发时发生了什么	YGC eden空间不足 FGC old空间不足 perm空间不足显示调用System.gc() ,包括RMI等的定时触发 YGC时的悲观策略 dump live的内存信息时(jmap –dump:live)	YGC 同serial动作基本相同,不同点: 1.多线程处理 2.YGC的最后不仅重新计算Tenuring Threshold,还会重新调整Eden和From的大小 FGC 1.如配置了ScavengeBeforeFullGC(默认),则先触发YGC(??) 2.MSC:清空heap中的no ref对象,permgen中已经被卸载的classloader中加载的class信息,并进行压缩 3.Compacting:清空heap中部分no ref的对象,permgen中已经被卸载的classloader中加载的class信息,并进行部分压缩多线程做以上动作.	YGC 同serial动作基本相同,不同点: 1.多线程处理 CMSGC: 1.old gen到达比率时只清除old gen中no ref的对象所占用的空间 2.perm gen到达比率时只清除已被清除的classloader加载的class信息 FGC 同serial
细节参数	可用-XX:+UseSerialGC强制使用 -XX:SurvivorRatio=x,控制eden/s0/s1的大小 -XX:MaxTenuringThreshold,用于控制对象在新生代存活的最大次数 -XX:PretenureSizeThreshold=x,控制超过多大的字节的对象就在old分配.	-XX:SurvivorRatio=x,控制eden/s0/s1的大小 -XX:MaxTenuringThreshold,用于控制对象在新生代存活的最大次数 -XX:UseAdaptiveSizePolicy 去掉YGC后动态调整eden from已经tenuringthreshold的动作 -XX:ParallelGCThreads 设置并行的线程数	-XX:CMSInitiatingOccupancyFraction 设置old gen使用到达多少比率时触发 -XX:CMSInitiatingPermOccupancyFraction,设置Perm Gen使用到达多少比率时触发 -XX:+UseCMSInitiatingOccupancyOnly禁止hostspot自行触发CMS GC

注：

throughput collector与concurrent low pause collector的区别是throughput collector只在young area使用使用多线程，而concurrent low pause collector则在tenured generation也使用多线程。
根据官方文档，他们俩个需要在多CPU的情况下，才能发挥作用。在一个CPU的情况下，会不如默认的serial collector，因为线程管理需要耗费CPU资源。而在两个CPU的情况下，也提高不大。只是在更多CPU的情况下，才会有所提高。当然 concurrent low pause collector有一种模式可以在CPU较少的机器上，提供尽可能少的停顿的模式，见CMS GC Incremental mode。
当要使用throughput collector时，在java opt里加上-XX:+UseParallelGC，启动throughput collector收集。也可加上-XX:ParallelGCThreads=<desired number>来改变线程数。还有两个参数 -XX:MaxGCPauseMillis=<nnn>和 -XX:GCTimeRatio=<nnn>，MaxGCPauseMillis=<nnn>用来控制最大暂停时间，而-XX: GCTimeRatio可以提高GC说占CPU的比，以最大话的减小heap。

文章出处：https://blog.csdn.net/kobejayandy/article/details/8496663

JVM内存区