一、内存区域
1、运行时数据区域
1.1 程序计数器
当前线程所执行的字节码的行号指示器。每个线程都有一个独立的程序计数器，各计数器互不影响，独立存储，从而实现线程切换后能够恢复到原来的位置。如果线程执行Java方法，则计数器记录正在执行的字节码指令地址，若是native方法，则为空。
唯一一个没有任何OutOfMemoryError情况的区域
1.2 Java虚拟机栈
描述Java方法执行的内存模型。在每个方法执行时，都会创建一个栈帧来存储方法中的局部变量表，操作数栈，动态链接，方法出口信息等。每个方法从调用到执行完成的过程，就对应着栈帧在虚拟机栈入栈到出栈的过程。每个线程对应一个Java虚拟机栈，生命周期一致，当栈中所有栈帧都出栈时，线程也完成使命。
局部变量表
局部变量表所需的内存空间在编译期间完成分配。包括8种基本数据类型，对象引用reference类型和returnAddress类型（指向一条字节码指令的地址）
操作数栈
与局部变量表一样，操作数栈也是被组织成一个以字长为单位的数组，不过并不是像变量表一样使用索引来访问，而是通过标准的栈操作：入栈和出栈来访问的。比如方法中的语句 int a = 2;则先把操作数2入栈，然后操作数栈出栈将2赋值给方法中的a，即变量表中的int a = 2被初始化完成。
规定两种异常：
- StackOverflowError：线程请求的栈深度大于虚拟机允许的深度
- OutOfMemoryError：扩展时无法申请到足够的内存
1.3 本地方法栈
描述Native方法执行的内存模型。与Java虚拟机栈发挥的作用相似。会抛出StackOverflowError和OutOfMemoryError两种异常
1.4 Java堆
Java虚拟机内存管理的内存种最大的一块，几乎所有的对象实例在这分配内存。垃圾收集器管理的主要区域，也称“GC堆”
从回收角度可分为两大类：
- 新生代：Eden空间，From Survivor空间，To Survivior空间，通常Eden与Survivor区域大小是8：1的比例的关系
- 老年代
堆分区的作用
为了性能的优化，提高GC的效率。如果没有分代，则当堆发生GC操作时，会对整个堆进行扫描，然后回收可回收对象，这样效率就会很慢。当分代后，我们就可以把新创建的对象放到某个地方，然后对其他区域进行回收，GC效率就会很高。
Survivor空间的作用
减少被送到老年代的对象，进而减少Full GC的发生。一般情况下，只有经历16次MinorGC还能在新生代存活的对象，才会被送到老年代。如果没有Survivor区域，即新生代不分区的话，则当Minor GC时，存活的对象就会被送到老年代。然后老年代就会很快被填满，然后触发Full GC。老年代的内存空间很大，当进行Full GC的操作消耗的时间更长，影响了程序的执行和相应速度。
Java堆允许处于不连续的物理空间中，只要逻辑连续即可。如果在堆中没有内存完成实例分配，且不可扩展时抛出OutOfMemoryError异常
1.5 方法区
用于存储已被虚拟机加载的类信息，常量，静态变量等数据。除了和堆一样不需要连续的内存和可扩展，还可以不实现垃圾收集，相对而言，垃圾收集机制在这个区域出现的较少。当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常
1.6 运行时常量池
方法区的一部分，类加载后，用于存放编译时期生成的各种字面量和字符引用。运行时常量池是方法区的一部分，自然当方法区无法分配足够内存时，将会抛出OutOfMemoryError异常。
2、对象的创建
2.1 类加载检查过程
JVM遇到new指令时，首先检查指令参数是否能够在常量池中定位到一个类的符号引用：
- 如果能够定位到，则检查这个符号引用代表的类是否被加载，解析和初始化
- 如果不能或没有检查到，则必须执行相应的类加载过程
2.2 为对象分配内存
对象所需要的内存在类加载后便可确定，故分配内存的任务等于Java堆划分一块确定大小的内存
2.2.1 分配方式
指针碰撞
如果Java堆内存规整：一边是用过的内存，一边是空闲的内存。指针移动所需的内存大小的距离
空闲列表
如果Java堆内存不规整：用过与空闲内存交叉，故空闲列表就是记录可用内存块，根据实例所需内存大小从列表中划分对应的空间
Java堆内存是否规整由所采用的垃圾收集器是否带有压缩整理功能决定。当使用Serial，ParNew收集器时，系统采用的分配方式是指针碰撞。当使用CMS基于标记-整理算法的收集器时，通常采用空闲列表
2.2.2 线程问题
并发情况下，两种分配方式都不是线程安全的。故有两种解决方法：
A. 对分配内存空间的动作进行同步处理
B.把内存分配的动作按照线程划分在不同的空间之中进行。每个线程在Java堆中预先分配本地线程分配缓冲（TLAB）,那个线程需要分配内存，就在那个线程的TLAB上分配，只有用完当前的TLAB并分配新的TLAB时，才需要进行同步锁定。
2.3 对象内存初始化为零值
假如使用TLAB，则在TLAB分配时进行初始化。保证了对象实例字段可不用赋初值，就可以直接使用
2.4 对象进行必要的设置
主要设置对象的哈希码，GC分代年龄，类元数据信息等
2.5 执行方法
3、对象内存布局
3.1 对象头
包括两个部分信息，第一部分主要用于存储对象自身运行时数据，如哈希码，GC分代年龄，线程持有的锁。第二部分为类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是那个类的实例。
3.2 实例数据
对象真正存储的有效信息，即各种类型的字段内容。包括父类继承下来的和子类中定义的字段内容。而实例数据的分配顺序受虚拟机的分配策略参数和字段在Java源码中定义顺序的影响。
分配策略：相同宽度字段分配到一起。longs/doubles、int、shorts/chars、bytes、booleans、oops。在满足这个的前提下，父类定义的变量在子类之前
3.3 对齐填充
占位符作用，不是必然存在。因为HotSpot VM要求对象内存大小必须是8字节的整数倍，当对象实例数据部分没有对齐时吗，就需要对齐填充来补全。
4、对象的访问
核心：通过Java栈上的reference数据来操作堆上的具体对象
主流访问方式：使用句柄和直接指针
4.1 使用句柄
当使用句柄访问时，Java堆中先划分一块内存作为句柄池，reference存储的就是对象的句柄地址，句柄地址包含了对象实例数据地址和对象类型数据。reference存储的是稳定的句柄地址，在对象被移动时只会改变句柄中的实例数据指针，而refreence本身不需要修改。
4.2 直接地址
reference存储的直接就是对象的地址，而Java堆对象布局就得考虑如何放置访问对象类型数据的地址。使用直接地址访问对象速度更快，节省了一次指针定位的时间开销（对象创建频繁）,HotSpot使用该种访问方法进行对象访问
二、垃圾收集器
1、概述
垃圾收集器（Garbage Collection），大部分我们都喜欢称之为GC。GC的职责主要围绕三个问题：
- 哪些内存需要回收
- 什么时候回收
- 如何回收
在Java中GC是系统自动完成的，并且在Java中GC只关注Java堆和方法区，因为在这两个区域只有在程序运行期间才知道创建了哪些对象，内存分配和回收都是动态的。而Java虚拟机栈，程序计数器，本地方法栈这几个区域由于内存分配和回收都具有确定性，故GC不需要过多关注这几个区域。
2、对象可回收判定方法
引用计数算法
思路：给对象添加一个计数器，每当一个地方引用它时，计数器就加1；当引用失效时，计数值就减1；任何时刻计数器为0的对象就不可能再被使用，即计数器为0的对象可回收。
缺点：很难解决对象之间相互循环引用的问题
可达性分析算法
思路：从“GC Roots”的对象为起始点，从这些节点向下搜索，所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链时，即该对象不可达时，则证明该对象是可回收对象。
而在Java中可作为GC Roots的对象有下面四种：
- 虚拟机栈中引用的对象
- native方法引用的对象
- 方法区中类静态属性引用的对象
- 方法区中常量引用的对象
引用
无论是引用计数算法还是可达性分析算法，判定对象是否可回收都与“引用”有关，而引用主要分为四种：
- 强引用：类似 Object obj= new Object()这种引用，只要强引用还在，则对象就不会被回收
- 软引用：有用但非必须的对象。在系统将要发生内存溢出之前，将进行二次回收，如果这次回收还没有足够内存，才会抛出内存溢出异常。
- 弱引用：非必须对象，只能生存到下一次垃圾回收发生之前。当垃圾收集器工作时，无论内存是否足够，都会回收掉只被弱引用关联的对象
- 虚引用：幽灵引用，最弱的引用。唯一目的是能在这个对象被gc时收到一个系统通知。
3、对象死亡
判断对象死亡还是生存的整体流程如下图所示：
关键点：至少两次标记
第一次标记
如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，则会被第一次标记并进行筛选。筛选的条件是此对象是否有必要执行finalize方法，当对象没有覆盖finalize方法或者finalize已经被虚拟机执行过一次，都认为是没必要执行finalize方法，此时对象死亡，虚拟机将会对该对象进行回收。
第二次标记
如果该对象是有必要执行finalize（）方法，则虚拟机会将该对象放置到F-Queue队列中，并稍后由虚拟机的Finalizer线程执行finalize方法。finalize方法是对象逃脱死亡命运的最后一次机会，稍后GC会对F-Queue中的对象进行第二次标记，如果对象要在finalize中成功拯救自己-只要在finalize方法中重新与引用链上的对象建立关联即可。那么在第二次标记时，该对象将从”即将回收“集合中移除。如果对象这时候还未逃脱，则基本上被回收。
注：任何一个对象的finalize（)方法只会被系统自动调用一次，并且在《深入Java虚拟机第二版》中也建议不使用该方法来拯救对象
4、垃圾收集算法
4.1 标记-清除算法
思路：最基础的收集算法，后续收集算法都基于该算法进行改进。算法分为两个阶段：
- 标记：标记出所有需要回收的对象
- 清除：统一回收所有被标记的对象
标记-清除算法示意图：
不足：一是效率不高；二是标记清除后会产生大量不连续的内存空间，导致以后在分配较大对象时，可能会提前触发GC
4.2 复制算法
思路：将可用的空间划分为两个大小相等的两块，每次只使用其中一块，当这一块用完时，就将当前用完的这块内存的所有存活对象复制到另外一块上面，然后把当前用完的内存一次清理掉。复制算法执行过程如下图：
优点：实现简单，运行高效
缺点：内存缩小为原来的一半，代价较高，并且当存活对象比较多时，要进行较多的复制操作，效率会降低
总结：适用于对象存活率较低的新生代
4.3 标记-整理算法
思路：过程与标记-清除一致，但标记后并不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。标记-整理执行过程如下图：
总结：适用于对象存活率高的老年代
4.4 分代收集算法
思路：根据各个年代的特点采用最适当的收集算法。
- 新生代：每次GC时有大批对象死亡，只有少量存活，因此适合使用复制算法
- 老年代：对象存活率高，没有额外空间对它进行分配担保，必须使用“标记-整理”算法或者“标记-清除”算法进行回收
5 、垃圾收集器
垃圾收集器是内存回收的具体实现，一个虚拟机可以有多个垃圾收集器，下图为HotSpot虚拟机的垃圾收集器以及组合情况：如果两个收集器之间存在连线，则说明它们可以搭配使用。
5.1 Serial收集器
含义：单线程收集器，在进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束
特点：简单高效，是运行在Client模式下的默认新生代的收集器
5.2 ParNew收集器
含义：Serial收集器的多线程版本
特点：运行在Server模式下的虚拟机首选的新生代收集器，除Serial收集器外，目前只有它能与CMS收集器配合工作。
5.3 Parallel Scavenge收集器
含义：使用复制算法、并行多线程、吞吐量优先的新生代收集器
特点：关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间））。
停顿时间越短就越适合需要与用户交互的程序，提升用户体验。高吞吐量可以高效地利用CPU时间，尽快完成程序的运算任务，适用在后台运算而不需要太多交互的任务
5.4 Serial Old收集器
含义：Serial收集器的老年代版本，使用标记-整理算法的单线程收集器
特点：给Client模式下的虚拟机使用，如果在Server模式下，则有两大用途：一种是JDK1.5以前的版本中与Parallel Scavenge收集器搭配使用，另一种是作为CMS收集器的后备预案
5.5 Parallel Old收集器
Parallel Scavenge收集器的老年代版本，JDK1.6后提供。主要使用多线程标记－整理算法。在注重吞吐量以及CPU资源敏感的场合优先考虑Parallel Scavenge+Parallel Old收集器。
5.6 CMS收集器
含义：一种以获取最短回收停顿时间为目标的收集器
特点：基于标记－清除算法，过程分为4个步骤：
- 初始标记
- 并发标记
- 重新标记
- 并发清除
初始标记和重新标记需要“Stop the World”,即停止其它线程。
总结：
- 优点：并发收集，低停顿
- 缺点：对CPU资源非常敏感，无法处理浮动垃圾，基于标记－清除算法，故收集结束会有大量空间碎片产生。
5.7 G１收集器
含义：面向服务端应用的垃圾收集器
特点：并行和并发，分代收集，空间整合，可预测的停顿。运行分为4个步骤：
- 初始标记
- 并发标记
- 最终标记
- 筛选回收
6、内存分配与回收策略
对象的内存分配，大方向讲就是在堆上进行分配，对象主要分配在新生代的Eden区，如果启动了本地线程分配缓冲，则按线程优先在TLAB上分配，少数对象也会直接分配到老年代。根据垃圾收集器的不同组合以及虚拟机内存相关参数的设置，会导致分配策略有所不同，下面为Serial／Serial Old收集器组合下的内存分配和回收策略。
GC类别：
Minor GC：新生代GC，指发生在新生代的垃圾收集动作
Full GC／Major GC：老年代GC，经常伴随至少一次的Minor GC，Full GC速度一般比Minor GC慢10倍以上
6.1 对象优先在新生代Eden区分配
大多数情况下，对象在新生代的Eden区进行分配，当Eden区没有内存进行分配时，将会进行一次Minor GC。
6.2 大对象直接进入老年代
大对象指的是需要大量连续内存的Java对象，典型代表为很长的字符串以及数组。
应避免创建一群短命大对象，当出现大对象时容易导致内存还有不少空间就提前触发GC以获取足够的连续空间来安置它们
6.3 长期存活的对象进入老年代
每个对象定义了一个对象年龄计数器。如果对象在Eden出生并经历第一次的Minor GC后仍然存活，并且能够被Survivor容纳的话，对象将移到Survivor空间，并且对象年龄计为1。后续对象每经历一次Minor GC后仍然存活，则年龄依次加1。当年龄增大到一定程度时（默认为15岁），该对象将转移到老年代。
对象晋升老年代的年龄可以通过参数设置
6.4 动态对象年龄判定
对象的年龄并非一定要达到阈值才能晋升到老年代。如果Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，则大于或等于该年龄的对象就可以直接进入到老年代。
6.5 空间分配担保
空间分配担保流程图如下：
老年代进行担保的原因：当进行Minor GC时，前提是老年代本身还有容纳这些对象的剩余空间，因为新生代中有多少对象会存活下来在实际完成Minor GC是不知道的，所以只好取之前回收晋升到老年代对象的平均大小作为经验值，与老年代剩余空间进行比较，决定是否进行Full GC来让老年代腾出更多的空间。