文章的目的主要是针对面试官的提问，做出尽可能精简而全面的回答。若读者对某块的知识不能太理解，还请参阅其他大佬比较详细的博客或者专业书籍，谢谢大家。
以周志明《深入理解Java虚拟机》为主，部分来源于其他博客。
一、jvm运行时数据区域
线程私有：
1.程序计数器：一块较小的内存空间，当前线程所执行的字节码的行号指示器。此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。
2.Java虚拟机栈：描述的是java方法执行的内存模型：每个方法在执行的同时都会创建一个栈帧用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，就对应一个栈帧在虚拟机中入栈到出栈的过程。此区域会出现两种异常状况：StackOverflowError异常与OutOfMemoryError异常。
3.本地方法栈：与java虚拟机栈类似，虚拟机栈提供Java方法服务，本地方法栈提供Native方法服务。此区域会出现两种异常状况：StackOverflowError异常与OutOfMemoryError异常。
线程共享：
1.Java堆：是虚拟机管理的内存最大的一块，在虚拟机启动时创建。几乎所有的实例以及数组都在堆上分配。
随着JIT编译器的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化发生，所有的对象都分配在堆上也渐渐变得不是那么绝对了。
Java堆以细分为：年轻代和老年代，年轻代又可以细分为Eden空间，From Survivor空间，To Survivor空间。此区域会出现OutOfMemoryError异常。
2.方法区：存储虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码。此区域会出现OutOfMemoryError异常。
运行时常量池：是方法区的一部分，class文件中的常量池，用于存放编译期间生成的各种字面量和符号引用，这部分内容在类加载后进入方法区的运行时常量池。
二、对象的内存布局
对象在内内存中存储的布局可以分为三个区域：对象头、实例数据和对齐填充。
对象头包括两部分信息（数组对象是三部分）：
1.Mark Word：存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向ID、偏向时间戳等。
2.类型指针：对象指向它类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。
3.数组长度：对象是java数组，对象头中还必须有一块记录数组长度的数据，因为虚拟机可以通过普通Java对象的元数据信息确定Java对象的大小，但是从数组的元数据中确无法确定数组的大小。
实例数据
对象真正存储的有效信息，程序代码中所定义的各种类型的字段内容。无论是从父类继承来的还是在子类中定义的，都需要记录下来。
对齐填充
虚拟机要求对象的起始地必须是8个字节的整数倍，就是对象的大小必须是8个字节的整数倍。而对象头部分正好是8字节的整数倍，当实例数据部分没有对齐时，就需要通过对齐填充来补充。
三、判断对象是否已死的方法
1.引用计数算法：给对象添加一个引用计数器，每当有一个地方引用它时，计数器的值就加1,；当引用失效时，计数器的值就减1；任何时刻计数器为0的对象就是不可能再被使用的。
缺陷：垃圾对象相互引用。
2.可达性分析算法：通过一系列“GC Roots”对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称为引用链，当一个对象到GC Roots没有任何引用链时相连时，证明此对象是不可用的。
可以作为GC Roots的对象：
1.虚拟机栈（栈帧中的本地变量表）中引用的对象。
2.方法区中静态属性引用的对象。
3.方法区中常量引用的对象。
4.本地方法栈中JNI（一般说的Native方法）引用的对象。
四、四种引用
从上至下，引用强度逐渐减弱
1.强引用：代码中普遍存在的，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
2.软引用：描述还有用但并非必需的对象，软引用关联的对象在系统将要发生内存溢出异常之前才会被回收。SoftReference类实现软引用。
3.弱引用：描述非必需对象，弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。
4.虚引用：虚引用不影响对象的生存时间，也无法通过虚引用来取得一个对象实例。为对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。
五、四种垃圾收集算法
1.标记-清除算法：首先标记出需要回收的对象，在标记完成后统一回收所有被标记的对象。
两个缺陷：a. 效率问题：标记和清除两个过程的效率都不高。b. 空间问题：标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能导致程序在运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
2.复制算法：将内存划分为大小相等的两块，每次只使用其中一块。当这一块的内存用完了，就将还存活的对象复制到另外一块上面，然后再把使用过得内存空间一次性清理掉。
优点：每次对整个半区进行内存回收，内存分配时也不用考虑内存碎片等复杂情况，只需要移动堆顶指针，按顺序分配内存，实现简单，运行高效。
缺点：内存缩小一半，代价太高。
商业虚拟机都采用复制算法来回收新生代，研究表明，对象98%都是朝生夕死，没必要1:1划分。HotSpot虚拟机将内存划分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor，默认Eden与Survivor的大小比例为8:1，每次新生代中可用内存空间为整个新生代容量的90%，只有10%的空间会被浪费。
3.标记-整理算法：首先标记出需要回收的对象，然后让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
4.分代收集算法：吧Java堆分成新生代和老年代，在新生代中，每次收集时都发现有大批对象失去，只有少量存活，就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。老年代中因为对象存活率高、没有额外空间对它进行分配担保，必须使用“标记-清除算法”或者“标记-整理算法”。
六、垃圾收集器
年轻代垃圾收集器（均使用复制算法）
1.Serial收集器：这是一个单线程收集器，在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。它是虚拟机运行在Client模式下的默认的新生代收集器。有着优于其他收集器的地方：简单而高效。
2.ParNew收集器：Serial收集器的多线程版本，使用多条线程进行垃圾收集，其他的与Serial完全一样。它是许多运行在Server模式下的虚拟机的首选新生代垃圾收集器。有一个与性无关但很重要的原因是除了serial收集器外，只有它能与CMS收集器配合工作。
3.Parallel Scavenge：并行的多线程垃圾收集器，是一个吞吐量优先的垃圾收集器。
吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)
老年代垃圾收集器
1.Serial Old收集器（使用标记-整理算法）：Serial收集器的老年代版本，同样是一个单线程收集器，这个收集器主要意义也是给Client模式下的虚拟机使用。
2.Parallel Old收集器（使用标记-整理算法）：Parallel Scavenge收集器的老年代版本。
3.CMS 收集器（使用标记-清除算法）：以获得最短回收停顿时间为目标的收集器。它的整个运作过程分为4个步骤：
（初始标记和重新标记两个步骤仍然需要“Stop The World”，即暂停所有的工作线程。）
a.初始标记：标记一下GC Roots能直接关联到的对象，速度很快。
b.并发标记：进行GC Roots Tracing。（此过程耗时最长）
c.重新标记：修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。（此过程的停顿时间一般比初始标记阶段稍长一些，但远比并发标记的时间短。）
d.并发清除：此过程与用户线程并发执行。
CMS收集器的三个缺点：
a.CMS收集器对CPU资源非常敏感。在并发阶段，虽然不会导致用户线程停顿，但是会因为占用了一部分CPU资源而导致程序变慢，总的吞吐量降低。
b.CMS收集器无法处理浮动垃圾。由于在并发清理阶段用户线程还在运行着，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好在下一次GC时再清理掉。这一部分垃圾就是浮动垃圾。
c.因为基于标记-清除算法，收集结束时会有大量空间碎片产生。空间碎片过多，将会给大对象分配带来很大麻烦，往往会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。
G1收集器：
四个特点：
1.并行与并发：
2.分代收集：
3.空间整合：与CMS的“标记-清理”算法不同，G1从整体上来看是基于“标记-整理”算法，从局部上看是基于“复制算法”实现的。这两种算法都意味着G1在运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。
4.可预测的停顿：G1相对于CMS收集器的另一大优势，G1可以建立可预测的停顿时间模型。
它的运作过程与CMS相似。
七、内存分配与回收策略
对象的内存分配，往大方向讲，就是在堆上分配（也有可能经过JIT即时编译后被拆散为标量类型并间接地在栈上分配），对象主要分配在新生代的Eden区上，如果启动了本地线程分配缓存，将线程优先在TLAB上分配。少数情况下可可能直接分配在老年代中，分配的规则不是百分之百固定的，其细节取决于当前使用的是哪一种垃圾收集器组合，还有虚拟机中与内存相关的参数的设置。
1.对象优先在Eden分配
大多数情况，对象在新生代Eden区中分配。当Eden区没有足够的空间进行分配时，虚拟机将发起一次Minor GC。Minor GC触发条件：当Eden区满时，触发Minor GC。聊聊jvm的年轻代
Minor GC：在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor区“To”是空的。紧接着进行GC，Eden区中所有存活的对象都会被复制到“To”，而在“From”区中，仍存活的对象会根据他们的年龄值来决定去向。年龄（虚拟机给每个对象定义了一个对象年龄计数器。如果对象在Eden出生并经过一次Minor GC仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间，并且对象年龄设为1。对象在Survivor区中每熬过一次Minor GC， 年龄就增加1岁）达到一定值(年龄阈值，可以通过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中，没有达到阈值的对象会被复制到“To”区域。经过这次GC后，Eden区和From区已经被清空。这个时候，“From”和“To”会交换他们的角色，也就是新的“To”就是上次GC前的“From”，新的“From”就是上次GC前的“To”。不管怎样，都会保证名为To的Survivor区域是空的。Minor GC会一直重复这样的过程，直到“To”区被填满，“To”区被填满之后，会将所有对象移动到老年代中。
2.大对象直接进入老年代
3.长期存活的对象进入老年代
4.动态对象年龄判断
虚拟机并不是永远地要求对象的年龄必须达到了MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有的对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无需达到MaxTenuringThreshold要求的年龄。
5.空间分配担保
在发生Minor GC之前，虚拟机会先检查老年代最大可用连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么Minor GC可以确保是安全的。
如果不成立会根据HandlePromotionFailure的设置值来是否允许担保失败。如果允许，会继续检查老年代最大的可用连续空间是否大于历次晋升到老年代对象的平均大小。如果大于将尝试一次Minor GC，GC失败则会发生Full GC。
老年代GC（Major GC / Full GC）：指发生在老年代的GC，出现了Major GC，经常会伴随着至少一次Minor GC。Major GC的速度一般会比Minor GC慢10倍以上。
Full GC的触发条件：
a. 调用System.gc时，系统建议执行Full GC，但是不必然执行。
b. 老年代空间不足。（大对象的创建，新生代存活的对象转入老年代，具体一点就是From Survivor区域的存活对象年龄达到阈值进入老年代还有就是To 区域装满转入老年代的时候空间不足。）
c. 方法区空间不足。
d. 做Minor GC时，空间分配担保失败。
八、虚拟机的类加载机制
虚拟机把描述类的数据从class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。
在Java语言里面，类型的加载、连接和初始化过程都是在程序运行期间完成的。
九、虚拟机类加载的时机
1.遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有进行初始化，则必须先触发其初始化。生成这4条指令最常见的Java代码场景是：使用new关键字实例化对象、读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。
2.使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则先触发其初始化。
3.初始化一个类的时候，如果发现其父类还没有进行初始化，则需要先触发其父类的初始化。
4.虚拟机启动时，用户需要制定一个执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。
5.使用JDK做动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄对应的类没有进行过初始化，则需要先触发其初始化。
这5种场景中的行为称为对一个类进行主动引用。除此之外，所有引用类的方式都不会触发初始化，称为被动引用。被动引用的三个例子：
1.子类引用父类的静态字段，不会导致子类初始化。
2.通过数组定义引用类，不会触发此类的初始化。
3.常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。
十、虚拟机类加载的过程
包括5个阶段：加载、验证、准备、解析和初始化。验证、准备、解析3个部分统称为连接。
加载：
1.通过一个类的全限定名来获取定义此类的二进制字节流。
2.将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3.在内存中生成一个代表这个类的java.lang.class对象，作为方法区这个类的各种数据访问入口。
验证：
1.文件格式验证
2.元数据验证
3.字节码验证
准备：
正式为类变量分配内存并设置类变量初始值的阶段，这些变量使用的内存都将在方法区中进行分配。这里进行内存分配的变量仅包括类变量而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在java堆中。这里的初始值一般是数据类型的零值，如果有final修饰的话，直接设置为对应的值。
解析：
将常量池中的符号引用替换为直接引用的过程。
初始化：
执行类构造器<clinit>()方法的过程。
<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中语句合并产生的。编译器收集的顺序是由语句在源文件中出现的顺序所决定的。静态语句块只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问。
<clinit>()方法与类的构造函数（或者说实例构造器<init>()方法）不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的 <clinit>()方法执行之前，父类的 <clinit>()方法已经执行完毕。
<clinit>()方法对于类或者接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成 <clinit>()方法。
接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成 <clinit>()方法。但接口与类不同的是，执行接口的 <clinit>()方法不需要先执行父接口的 <clinit>()方法。只有当父接口中定义的变量使用时父接口才会初始化。接口的实现类在初始化时也一样不会执行接口中的 <clinit>()方法。
十一、类加载器与双亲委派模型
类加载器：通过一个类的全限定名来获取描述此类的二进制字节流的代码模块。
三种类加载器：
1.启动类加载器（Bootstrap ClassLoader）
2.扩展类加载器（Extension ClassLoader）
3.应用程序类加载器（Application ClassLoader），系统类加载器，程序默认的类加载器。
双亲委派模型：
除了顶层的类加载器之外，其余的类加载器都应有自己的父类加载器。（类加载器之间的父子关系一般不会以继承的关系来实现，而是都使用组合的关系来复用类加载器的代码。）
双亲委派模型的工作过程：
如果一个类加载器收到了类加载请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父类加载器反馈自己无法完成加载这个请求（他的搜索范围中没有找到所需要的类时），子类加载器才会尝试自己去加载。
使用双亲委派模型的好处：
使用双亲委派模型来组织类加载器之间的关系，可以使Java类随着它的类加载器一起具备了一种带有优先级的层次关系。
十二、Java内存模型JMM
Java内存模型主要目标是定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量的底层细节。这里的变量包括了实例字段，静态字段和构成数组对象的元素，但不包括局部变量与方法参数，因为后者是线程私有的，不会被共享，自然就不存在竞争问题。
Java内存模型：规定所有的变量都存储在主内存中，每条线程还有自己的工作内存，线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存中的变量。不同线程直接也无法直接访问对方工作内存中的变量，线程之间变量值的传递均需要通过主内存来完成。
持续更新！！！！！觉得如果有帮助到你，麻烦评论喜欢加关注哟。
