对于大多数应用来说，Java 堆（Java Heap）是Java 虚拟机所管理的内存中最大的一块。Java 堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。
JVM内存模型
根据 JVM 规范，JVM 内存共分为虚拟机栈、堆、方法区、程序计数器、本地方法栈五个部分。
1、虚拟机栈（Java Virtual Machine Stacks）：
虚拟机栈是线程私有的，随着线程的创建而创建。栈里面存着的是一种叫“栈帧”的东西，每一个方法从调用到执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。栈帧中存放了局部变量表（基本数据类型和对象引用）、操作数栈、动态链接、方法出口等信息。局部变量表存储了编译期可知的各种基本数据类型(boolean, byte, char, short, int, float, double, long), 对象引用(reference类型和returnAddress类型(指向一条字节码指令的地址)。线程请求的栈深度不够会报StackOverflowError异常，栈动态扩展的容量不够会报OutOfMemoryError异常。
2、本地方法栈（Method Native Stack）：
与虚拟机栈的作用非常相似，区别是虚拟机栈为虚拟机执行java方法服务，而本地方法栈则为虚拟机使用到的Native方法服务。Java 应用程序员并不需要关心这部分的内容。
3、程序计数器（Program Counter Register）：
有些文档中也叫PC寄存器，是一块较小的内存空间，可以看做是当前线程所执行的字节码的行号指示器，我们知道JVM执行代码是一行一行执行字节码，所以需要一个计数器来记录当前执行的行数。在虚拟机的概念模型里，字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖计数器完成。如果线程正在执行一个JAVA方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址，如果正在执行的是NATIVE方法，这个计数器值为空(Undefined)，此内存区域是唯一一个在JAVA虚拟机规范中没有规定任何OutOfMemoryError的区域。
4、堆（Java Heap）：
此内存区域的唯一作用就是用来存放对象实例，几乎所有的对象实例都在这里分配内存。堆是java虚拟机管理的内存中最大的一块，被所有线程共享。由于堆是垃圾收集器管理的主要区域，所以也被称为GC堆。当申请不到空间时会抛出 OutOfMemoryError。由于现代收集器基本都采用分代收集算法，所以java堆中还可以细分为新生代，老年代。新生代又细分为Edan区、From Survivor区(S0)、To Survivor区（S1）。
4.1 堆空间内存分配（默认情况下）
- 老年代 ： 三分之二的堆空间
- 年轻代 ： 三分之一的堆空间
- eden区： 8/10 的年轻代空间
- survivor0 : 1/10 的年轻代空间
- survivor1 : 1/10 的年轻代空间
5、元空间（Metaspace）：
存储已被虚拟机加载的类信息。随着JDK8的到来，JVM不再有方法区（PermGen），原方法区存储的信息被分成两部分：1、虚拟机加载的类信息，2、运行时常量池。分别被移动到了元空间和堆中。
GC详解及Minor GC、Major GC和Full GC触发条件
针对HotSpot VM的实现，它里面的GC其实准确分类只有两大种：
- Partial GC：并不收集整个GC堆的模式
- Young GC：只收集young gen的GC
- Old GC：只收集old gen的GC。只有CMS的concurrent collection是这个模式
- Mixed GC：收集整个young gen以及部分old gen的GC。只有G1有这个模式
- Full GC：收集整个堆，包括young gen、old gen、perm gen（如果存在的话）等所有部分的模式。
- Minor GCMinor GC指新生代GC，即发生在新生代（包括Eden区和Survivor区）的垃圾回收操作，当新生代无法为新生对象分配内存空间的时候，会触发Minor GC。因为新生代中大多数对象的生命周期都很短，所以发生Minor GC的频率很高，虽然它会触发stop-the-world，但是它的回收速度很快。Minor GC（新生代GC）的触发条件：
- 当Eden区满时，触发Minor GC。
- Major GC和Full GCMajor GC指老年代GC，出现Major GC通常会出现至少一次Minor GC。Full GC是针对整个新生代、老生代、元空间（metaspace，java8以上版本取代perm gen）的全局范围的GC。Major GC通常是跟full GC是等价的，收集整个GC堆，但Full GC不完全等于Major GC，也不完全等于Minor GC+Major GC，发生Full GC需要看使用了什么垃圾收集器组合，才能解释是什么样的垃圾回收。收集整个GC堆，需要关注当前的 GC 是否停止了所有应用程序的线程（stop the world），还是能够并发的处理而不用停掉应用程序的线程。Full GC触发条件：
- （1）System.gc()方法的调用
- （2）老年代空间不足
- （3）方法区空间不足
- （4）通过Minor GC后进入老年代的平均大小大于老年代的可用内存
- （5）由Eden区、From Space区向To Space区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小
如何判断哪些对象需要被回收？
JVM的内存结构包括五大区域：程序计数器、虚拟机栈、本地方法栈、堆区、方法区。其中程序计数器、虚拟机栈、本地方法栈3个区域随线程而生、随线程而灭，因此这几个区域的内存分配和回收都具备确定性，就不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟随着回收了。而Java堆区和方法区则不一样，这部分内存的分配和回收是动态的，正是垃圾收集器所需关注的部分。java堆中存放着几乎所有的对象实例，垃圾回收器在对java堆进行回收前，需要知道哪些对象还活着，哪些对象已经死了（即不可能再被引用的对象）。
判断对象是否存活有两种方法：引用计数法和可达性分析法。
1. 引用计数法
给每个对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器就减1；任何时刻计数器为0的对象就是不可能再被使用的对象，此时该对象为可回收对象。
客观的说，引用计数法实现简单，判定效率也很高，但是其存在一个致命的弱点：无法解决对象之间循环引用的问题。如对象A和对象B都有字段instance，令A.instance = B;B.instance=A;除此之外，两个对象再无任何引用，现令A=null;B=null;实际上这两个对象已经不再可能被引用，但是因为它们之间相互引用，导致它们的计数器值都不为0，因此GC无法回收它们。
2. 可达性分析法
该算法的基本思想是通过一系列的成为“GC roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（reference chain），当一个对象到GC roots没有任何引用链相连时，则证明此对象是不可用的。在java语言中，可作为GC roots的对象包括以下几种：
- 1）虚拟机栈（栈帧中的本地变量表）中引用的对象；
- 2）方法区中类静态属性引用的对象；
- 3）方法区中常量引用的对象；
- 4）本地方法栈中JNI（即native方法）引用的对象。
垃圾收集算法
1.标记清除算法
2.复制算法
3.标记整理算法
4.分代收集算法
常见的垃圾收集器
这里我们讨论的是JDK1.7 以后的HotSpot虚拟机中的垃圾收集器，因为JDK1.7 之后添加了G1回收器。
图中展示了7种作用于不同分代的收集器，如果两个收集器之间存在连线，则说明它们可以搭配使用。虚拟机所处的区域则表示它是属于新生代还是老年代收集器。
新生代收集器：Serial、ParNew、Parallel Scavenge
老年代收集器：CMS、Serial Old、Parallel Old
整堆收集器： G1
一：Serial 收集器
Serial收集器是最基本的、发展历史最悠久的收集器。
特点：单线程、简单高效（与其他收集器的单线程相比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程手机效率。收集器进行垃圾回收时，必须暂停其他所有的工作线程，直到它结束（Stop The World）。
应用场景：适用于Client模式下的虚拟机。
Serial / Serial Old收集器运行示意图
二：ParNew收集器
ParNew收集器其实就是Serial收集器的多线程版本。
除了使用多线程外其余行为均和Serial收集器一模一样（参数控制、收集算法、Stop The World、对象分配规则、回收策略等）。
特点：多线程、ParNew收集器默认开启的收集线程数与CPU的数量相同，在CPU非常多的环境中，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。
和Serial收集器一样存在Stop The World问题
应用场景：ParNew收集器是许多运行在Server模式下的虚拟机中首选的新生代收集器，因为它是除了Serial收集器外，唯一一个能与CMS收集器配合工作的。
ParNew/Serial Old组合收集器运行示意图如下：
三：Parallel Scavenge 收集器
与吞吐量关系密切，故也称为吞吐量优先收集器。
特点：属于新生代收集器也是采用复制算法的收集器，又是并行的多线程收集器（与ParNew收集器类似）。
该收集器的目标是达到一个可控制的吞吐量。还有一个值得关注的点是：GC自适应调节策略（与ParNew收集器最重要的一个区别）
GC自适应调节策略：Parallel Scavenge收集器可设置-XX:+UseAdptiveSizePolicy参数。当开关打开时不需要手动指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRation）、晋升老年代的对象年龄（-XX:PretenureSizeThreshold）等，虚拟机会根据系统的运行状况收集性能监控信息，动态设置这些参数以提供最优的停顿时间和最高的吞吐量，这种调节方式称为GC的自适应调节策略。
Parallel Scavenge收集器使用两个参数控制吞吐量：
- XX:MaxGCPauseMillis 控制最大的垃圾收集停顿时间
- XX:GCRatio 直接设置吞吐量的大小。
四：Serial Old 收集器
Serial Old是Serial收集器的老年代版本。
特点：同样是单线程收集器，采用标记-整理算法。
应用场景：主要也是使用在Client模式下的虚拟机中。也可在Server模式下使用。
Server模式下主要的两大用途：
- 在JDK1.5以及以前的版本中与Parallel Scavenge收集器搭配使用。
- 作为CMS收集器的后备方案，在并发收集Concurent Mode Failure时使用。
Serial / Serial Old收集器工作过程图（Serial收集器图示相同）：
五：Parallel Old 收集器
是Parallel Scavenge收集器的老年代版本。
特点：多线程，采用标记-整理算法。
应用场景：注重高吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge+Parallel Old 收集器。
Parallel Scavenge/Parallel Old收集器工作过程图：
六：CMS收集器
一种以获取最短回收停顿时间为目标的收集器。
特点：基于标记-清除算法实现。并发收集、低停顿。
应用场景：适用于注重服务的响应速度，希望系统停顿时间最短，给用户带来更好的体验等场景下。如web程序、b/s服务。
CMS收集器的运行过程分为下列4步：
初始标记：标记GC Roots能直接到的对象。速度很快但是仍存在Stop The World问题。
并发标记：进行GC Roots Tracing 的过程，找出存活对象且用户线程可并发执行。
重新标记：为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录。仍然存在Stop The World问题。
并发清除：对标记的对象进行清除回收。
CMS收集器的内存回收过程是与用户线程一起并发执行的。
CMS收集器的工作过程图：
CMS收集器的缺点：
- 对CPU资源非常敏感。
- 无法处理浮动垃圾，可能出现Concurrent Model Failure失败而导致另一次Full GC的产生。
- 因为采用标记-清除算法所以会存在空间碎片的问题，导致大对象无法分配空间，不得不提前触发一次Full GC。
七：G1收集器
一款面向服务端应用的垃圾收集器。
特点如下：
并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短Stop-The-World停顿时间。部分收集器原本需要停顿Java线程来执行GC动作，G1收集器仍然可以通过并发的方式让Java程序继续运行。
分代收集：G1能够独自管理整个Java堆，并且采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。
空间整合：G1运作期间不会产生空间碎片，收集后能提供规整的可用内存。
可预测的停顿：G1除了追求低停顿外，还能建立可预测的停顿时间模型。能让使用者明确指定在一个长度为M毫秒的时间段内，消耗在垃圾收集上的时间不得超过N毫秒。
G1为什么能建立可预测的停顿时间模型？
因为它有计划的避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的大小，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。这样就保证了在有限的时间内可以获取尽可能高的收集效率。
G1与其他收集器的区别：
其他收集器的工作范围是整个新生代或者老年代、G1收集器的工作范围是整个Java堆。在使用G1收集器时，它将整个Java堆划分为多个大小相等的独立区域（Region）。虽然也保留了新生代、老年代的概念，但新生代和老年代不再是相互隔离的，他们都是一部分Region（不需要连续）的集合。
G1收集器存在的问题：
Region不可能是孤立的，分配在Region中的对象可以与Java堆中的任意对象发生引用关系。在采用可达性分析算法来判断对象是否存活时，得扫描整个Java堆才能保证准确性。其他收集器也存在这种问题（G1更加突出而已）。会导致Minor GC效率下降。
G1收集器是如何解决上述问题的？
采用Remembered Set来避免整堆扫描。G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序在对Reference类型进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用对象是否处于多个Region中（即检查老年代中是否引用了新生代中的对象），如果是，便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set中。当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆进行扫描也不会有遗漏。
如果不计算维护 Remembered Set 的操作，G1收集器大致可分为如下步骤：
初始标记：仅标记GC Roots能直接到的对象，并且修改TAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象。（需要线程停顿，但耗时很短。）
并发标记：从GC Roots开始对堆中对象进行可达性分析，找出存活对象。（耗时较长，但可与用户程序并发执行）
最终标记：为了修正在并发标记期间因用户程序执行而导致标记产生变化的那一部分标记记录。且对象的变化记录在线程Remembered Set Logs里面，把Remembered Set Logs里面的数据合并到Remembered Set中。（需要线程停顿，但可并行执行。）
筛选回收：对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划。（可并发执行）
G1收集器运行示意图：
参考博客
本文已通过「原本」原创作品认证，转载请注明文章出处及链接。
