目录
一、JVM内存模型
1、程序计数器（Program Counter Register）
2、Java虚拟机栈（Java Virtual Machine Stack）
3、本地方法栈（Native Method Stack）
4、Java堆（Java Heap）
5、运行时常量池（Runtime Constant Pool）
6、直接内存（Direct Memory）
7、方法区（Method Area）
二、内存常见问题
1、共享内存区划分
2、常见参数的配置
堆栈相关
垃圾收集器参数
怎么打出线程栈信息。
堆栈日志信息分析
3、JVM中一次完整的GC流程是怎样的，对象如何晋升到老年代
4、几种垃圾收集器：
jdk1.7或1.8 默认垃圾收集器
5、CMS收集器和G1收集器的区别
6、FullGC
7、GC roots
8、GC Roots对象
9、什么原因导致了连续的FullGC？
10、如何来解决连续的FullGC？
1.增加JVM的堆内存
2.增加Perm或者Metaspace内存
3.增加更多的JVM实例
11、JVM内存模型的相关知识了解多少，比如重排序，内存屏障，happen-before，主内存，工作内存。
12、java内存模型中堆和栈的区别
13、指令重排
14、内存屏障
一、JVM内存模型
jvm--Java堆、方法区、Java虚拟机栈、本地方法栈、程序计数器
1、程序计数器（Program Counter Register）
它是一块较小的内存空间，它的作用可以看做是当先线程所执行的字节码的信号指示器。
每一条JVM线程都有自己的PC寄存器，各条线程之间互不影响，独立存储，这类内存区域被称为“线程私有”内存
在任意时刻，一条JVM线程只会执行一个方法的代码。该方法称为该线程的当前方法（Current Method）
如果该方法是java方法，那PC寄存器保存JVM正在执行的字节码指令的地址
如果该方法是native，那PC寄存器的值是undefined。
此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。
2、Java虚拟机栈（Java Virtual Machine Stack）
与PC寄存器一样，Java虚拟机栈也是线程私有的。每一个JVM线程都有自己的java虚拟机栈，这个栈与线程同时创建，它的生命周期与线程相同。
虚拟机栈描述的是Java方法执行的内存模型：每个方法被执行的时候都会同时创建一个栈帧（Stack Frame）用于存储局部变量表、操作数栈、动态链接、方法出口等信息。
每一个方法被调用直至执行完成的过程就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。
JVM stack 可以被实现成固定大小，也可以根据计算动态扩展。
如果采用固定大小的JVM stack设计，那么每一条线程的JVM Stack容量应该在线程创建时独立地选定。JVM实现应该提供调节JVM Stack初始容量的手段；
如果采用动态扩展和收缩的JVM Stack方式，应该提供调节最大、最小容量的手段。
如果线程请求的栈深度大于虚拟机所允许的深度将抛出StackOverflowError；
如果JVM Stack可以动态扩展，但是在尝试扩展时无法申请到足够的内存时抛出OutOfMemoryError。
3、本地方法栈（Native Method Stack）
本地方法栈与虚拟机栈作用相似，后者为虚拟机执行Java方法服务，而前者为虚拟机用到的Native方法服务。
虚拟机规范对于本地方法栈中方法使用的语言，使用方式和数据结构没有强制规定，甚至有的虚拟机（比如HotSpot）直接把二者合二为一。
这玩意儿抛出的异常跟上面的虚拟机栈一样。
4、Java堆（Java Heap）
虚拟机管理的内存中最大的一块，同时也是被所有线程所共享的，它在虚拟机启动时创建，这货存在的意义就是存放对象实例，几乎所有的对象实例以及数组都要在这里分配内存。
这里面的对象被自动管理，也就是俗称的GC（Garbage Collector）所管理。用就是了，有GC扛着呢，不用操心销毁回收的事儿。
Java堆的容量可以是固定大小，也可以随着需求动态扩展（-Xms和-Xmx），并在不需要过多空间时自动收缩。
Java堆所使用的内存不需要保证是物理连续的，只要逻辑上是连续的即可。
JVM实现应当提供给程序员调节Java 堆初始容量的手段，对于可动态扩展和收缩的堆来说，则应当提供调节其最大和最小容量的手段。
如果堆中没有内存完成实例分配并且堆也无法扩展，就会抛OutOfMemoryError。
这里有一个小例子，来说明堆，栈和方法区之间的关系的
public class Test2 {
public static void main(String[] args) {
public Test2 t2 = new Test2();
//JVM将Test2类信息加载到方法区,new Test2()实例保存在堆区,Test2引用保存在栈区
}
}
5、运行时常量池（Runtime Constant Pool）
它是方法区的一部分。Class文件中除了有类的版本、字段、方法、接口等描述等信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译期生成的各种字面量和符号引用，
这部分内容将在类加载后存放到方法区的运行时常量池中。
Java虚拟机对Class文件的每一部分（自然也包括常量池）的格式都有严格的规定，每一个字节用于存储哪种数据都必须符合规范上的要求，这样才会被虚拟机认可、装载和执行。但对于运行时常量池，
Java虚拟机规范没有做任何细节的要求，不同的提供商实现的虚拟机可以按照自己的需要来实现这个内存区域。
不过，一般来说，除了保存Class文件中描述的符号引用外，还会把翻译出来的直接引用也存储在运行时常量池中。
运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性，Java语言并不要求常量一定只能在编译期产生，也就是并非预置入Class文件中常量池的内容才能进入方法区运行时常量池，
运行期间也可能将新的常量放入池中，这种特性被开发人员利用得比较多的便是String类的intern()方法。
既然运行时常量池是方法区的一部分，自然会受到方法区内存的限制，当常量池无法再申请到内存时会抛出OutOfMemoryError异常。
6、直接内存（Direct Memory）
直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域，但是这部分内存也被频繁地使用，而且也可能导致OutOfMemoryError异常出现。
JDK1.4加的NIO中，ByteBuffer有个方法是allocateDirect(int capacity) ，这是一种基于通道（Channel）与缓冲区（Buffer）的I/O方式，它可以使用Native函数库直接分配堆外内存，
然后通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。
显然，本机直接内存的分配不会受到Java堆大小的限制，但是，既然是内存，则肯定还是会受到本机总内存（包括RAM及SWAP区或者分页文件）的大小及处理器寻址空间的限制。
服务器管理员配置虚拟机参数时，一般会根据实际内存设置-Xmx等参数信息，但经常会忽略掉直接内存，使得各个内存区域的总和大于物理内存限制（包括物理上的和操作系统级的限制），
从而导致动态扩展时出现OutOfMemoryError异常。
7、方法区（Method Area）
跟堆一样是被各个线程共享的内存区域，用于存储以被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然这个区域被虚拟机规范把方法区描述为堆的一个逻辑部分，
但是它的别名叫非堆，用来与堆做一下区别。
方法区在虚拟机启动的时候创建。
方法区的容量可以是固定大小的，也可以随着程序执行的需求动态扩展，并在不需要过多空间时自动收缩。
方法区在实际内存空间中可以是不连续的。
Java虚拟机实现应当提供给程序员或者最终用户调节方法区初始容量的手段，对于可以动态扩展和收缩方法区来说，则应当提供调节其最大、最小容量的手段。
当方法区无法满足内存分配需求时就会抛OutOfMemoryError。
二、内存常见问题
1、共享内存区划分
共享内存区 = 持久带 + 堆
持久带 = 方法区 + 其他
Java堆 = 老年代 + 新生代
新生代 = Eden + S0 + S1
默认的，新生代 ( Young ) 与老年代 ( Old ) 的比例的值为 1:2 ，可以通过参数 –XX:NewRatio 配置。
默认的，Edem : from : to = 8 : 1 : 1 ( 可以通过参数 –XX:SurvivorRatio 来设定)
Survivor区中的对象被复制次数为15(对应虚拟机参数 -XX:+MaxTenuringThreshold)
为什么要分为Eden和Survivor?为什么要设置两个Survivor区？
如果没有Survivor，Eden区每进行一次Minor GC，存活的对象就会被送到老年代。老年代很快被填满，触发Major GC.老年代的内存空间远大于新生代，进行一次Full GC消耗的时间比Minor GC长得多,所以需要分为Eden和Survivor。
Survivor的存在意义，就是减少被送到老年代的对象，进而减少Full GC的发生，Survivor的预筛选保证，只有经历16次Minor GC还能在新生代中存活的对象，才会被送到老年代。
设置两个Survivor区最大的好处就是解决了碎片化，刚刚新建的对象在Eden中，经历一次Minor GC，Eden中的存活对象就会被移动到第一块survivor space S0，Eden被清空；等Eden区再满了，就再触发一次Minor GC，Eden和S0中的存活对象又会被复制送入第二块survivor space S1（这个过程非常重要，因为这种复制算法保证了S1中来自S0和Eden两部分的存活对象占用连续的内存空间，避免了碎片化的发生）
2、常见参数的配置
堆栈相关
-Xmx3550m： 最大堆大小为3550m。
-Xms3550m： 设置初始堆大小为3550m。
-Xmn2g： 设置年轻代大小为2g。
-Xss128k： 每个线程的栈大小为128k。
-XX:MaxPermSize： 设置持久代大小为16m
-XX:NewRatio=4: 设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。
-XX:SurvivorRatio=4： 设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6
-XX:MaxTenuringThreshold=0： 设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。
垃圾收集器参数
-XX:+UseParallelGC： 选择垃圾收集器为并行收集器。
-XX:ParallelGCThreads=20： 配置并行收集器的线程数
-XX:+UseConcMarkSweepGC： 设置年老代为并发收集。
-XX:CMSFullGCsBeforeCompaction：由于并发收集器不对内存空间进行压缩、整理，所以运行一段时间以后会产生“碎片”，使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。
-XX:+UseCMSCompactAtFullCollection： 打开对年老代的压缩。可能会影响性能，但是可以消除碎片
怎么打出线程栈信息。
思路： 可以说一下jps，top ，jstack这几个命令，再配合一次排查线上问题进行解答。
我的答案：
输入jps，获得进程号。
top -Hp pid 获取本进程中所有线程的CPU耗时性能
jstack pid命令查看当前java进程的堆栈状态
或者 jstack -l > /tmp/output.txt 把堆栈信息打到一个txt文件。
可以使用fastthread 堆栈定位，fastthread.io/
例如：
1、jps:查看本地正在运行的java进程和进程ID（pid）
2、jinfo pid，查看指定pid的所有JVM信息
1）jinfo -flags pid 查询虚拟机运行参数信息。
2）jinfo -flag name pid，查询具体参数信息，如jinfo -flag UseSerialGC 42324，查看是否启用UseSerialGC
3、jmap
1）jmap -heap pid：输出堆内存设置和使用情况（JDK11使用jhsdb jmap --heap --pid pid）
2）jmap -histo pid：输出heap的直方图，包括类名，对象数量，对象占用大小
3）jmap -histo:live pid：同上，只输出存活对象信息
4）jmap -clstats pid：输出加载类信息
5）jmap -help：jmap命令帮助信息
4、jstat：Java虚拟机统计工具，全称“Java Virtual Machine statistics monitoring tool”。可以用于监视JVM各种堆和非堆内存大小和使用量
1）jstat -class pid：输出加载类的数量及所占空间信息。
2）jstat -gc pid：输出gc信息，包括gc次数和时间，内存使用状况（可带时间和显示条目参数）
其他命令不一一列举。
堆栈日志信息分析
-XX:+PrintGC 输出形式:
[GC 118250K->113543K(130112K), 0.0094143 secs] [Full GC 121376K->10414K(130112K), 0.0650971 secs]
-XX:+PrintGCDetails 输出形式:
[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs] [GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs
YoungGC:
FullGC:
3、JVM中一次完整的GC流程是怎样的，对象如何晋升到老年代
思路： 先描述一下Java堆内存划分，再解释Minor GC，Major GC，full GC，描述它们之间转化流程。
我的答案：
Java堆 = 老年代 + 新生代
新生代 = Eden + S0 + S1
当 Eden 区的空间满了， Java虚拟机会触发一次 Minor GC，以收集新生代的垃圾，存活下来的对象，则会转移到 Survivor区。
大对象（需要大量连续内存空间的Java对象，如那种很长的字符串）直接进入老年态；
如果对象在Eden出生，并经过第一次Minor GC后仍然存活，并且被Survivor容纳的话，年龄设为1，每熬过一次Minor GC，年龄+1，若年龄超过一定限制（15），则被晋升到老年态。即长期存活的对象进入老年态。
老年代满了而无法容纳更多的对象，Minor GC 之后通常就会进行Full GC，Full GC 清理整个内存堆 – 包括年轻代和年老代。
Major GC 发生在老年代的GC，清理老年区，经常会伴随至少一次Minor GC，比Minor GC慢10倍以上。
5.你知道哪几种垃圾收集器，各自的优缺点，重点讲下cms和G1，包括原理，流程，优缺点。
思路： 一定要记住典型的垃圾收集器，尤其cms和G1，它们的原理与区别，涉及的垃圾回收算法。
我的答案：
4、几种垃圾收集器：
Serial收集器： 单线程的收集器，收集垃圾时，必须stop the world，使用复制算法。
ParNew收集器： Serial收集器的多线程版本，也需要stop the world，复制算法。
Parallel [ˈpærəlel] Scavenge [ˈskævɪndʒ] 收集器： 新生代收集器，复制算法的收集器，并发的多线程收集器，目标是达到一个可控的吞吐量。如果虚拟机总共运行100分钟，其中垃圾花掉1分钟，吞吐量就是99%。
Serial Old收集器： 是Serial收集器的老年代版本，单线程收集器，使用标记整理算法。
Parallel Old收集器： 是Parallel Scavenge收集器的老年代版本，使用多线程，标记-整理算法。
CMS(Concurrent Mark Sweep) 收集器： 是一种以获得最短回收停顿时间为目标的收集器，标记清除算法，运作过程：初始标记，并发标记，重新标记，并发清除，收集结束会产生大量空间碎片。
G1收集器： 标记整理算法实现，运作流程主要包括以下：初始标记，并发标记，最终标记，筛选标记。不会产生空间碎片，可以精确地控制停顿。
jdk1.7或1.8 默认垃圾收集器
使用参数打印日志
java -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -version 或者 java -XX:+PrintFlagsFinal
结论：
1.8或1.7默认的是 UseParallelGC
ParallelGC 默认的是 Parallel Scavenge（新生代）+ Parallel Old（老年代）
在JVM中是+XX配置实现的搭配组合：
UseSerialGC 表示 “Serial” + "Serial Old"组合
UseParNewGC 表示 “ParNew” + “Serial Old”
UseConcMarkSweepGC 表示 “ParNew” + “CMS”. 组合，“CMS” 是针对旧生代使用最多的
UseParallelGC 表示 “Parallel Scavenge” + "Parallel Old"组合
UseParallelOldGC 表示 “Parallel Scavenge” + "Parallel Old"组合
在实践中使用UseConcMarkSweepGC 表示 “ParNew” + “CMS” 的组合是经常使用的
5、CMS收集器和G1收集器的区别
CMS收集器是老年代的收集器，可以配合新生代的Serial和ParNew收集器一起使用；
G1收集器收集范围是老年代和新生代，不需要结合其他收集器使用；
CMS收集器以最小的停顿时间为目标的收集器；
G1收集器可预测垃圾回收的停顿时间
CMS收集器是使用“标记-清除”算法进行的垃圾回收，容易产生内存碎片
G1收集器使用的是“标记-整理”算法，进行了空间整合，降低了内存空间碎片
6、FullGC
1.CPU利用率飙升
2.由于应用暂停导致应用的响应时间变长，这会影响服务的可用性和用户体验。
7、GC roots
GC管理的主要区域是Java堆，一般情况下只针对堆进行垃圾回收。方法区、栈和本地方法区不被GC所管理,因而选择这些区域内的对象作为GC roots,被GC roots引用的对象不被GC回收。
常说的GC(Garbage Collector) roots，特指的是垃圾收集器（Garbage Collector）的对象，GC会收集那些不是GC roots且没有被GC roots引用的对象。
一个对象可以属于多个root，GC root有几下种：
Class - 由系统类加载器(system class loader)加载的对象，这些类是不能够被回收的，他们可以以静态字段的方式保存持有其它对象。我们需要注意的一点就是，通过用户自定义的类加载器加载的类，除非相应的java.lang.Class实例以其它的某种（或多种）方式成为roots，否则它们并不是roots。
Thread - 活着的线程
Stack Local - Java方法的local变量或参数
JNI Local - JNI方法的local变量或参数
JNI Global - 全局JNI引用
Monitor Used - 用于同步的监控对象
Held by JVM - 用于JVM特殊目的由GC保留的对象，但实际上这个与JVM的实现是有关的。可能已知的一些类型是：系统类加载器、一些JVM知道的重要的异常类、一些用于处理异常的预分配对象以及一些自定义的类加载器等。然而，JVM并没有为这些对象提供其它的信息，因此需要去确定哪些是属于"JVM持有"的了。
8、GC Roots对象
- 虚拟机栈(栈桢中的本地变量表)中的引用的对象
- 方法区中的类静态属性引用的对象
- 方法区中的常量引用的对象
- 本地方法栈中JNI的引用的对象
9、什么原因导致了连续的FullGC？
导致连续的FullGC主要只有一个原因：JVM的堆内存不够用或者是Perm、Metaspace内存不够用，说明应用需要比你分配的内存更多的内存。通俗地说就是小马拉大车。
所以JVM必须要努力的去清理垃圾来给存活的对象分配空间。
你可能会想，我的应用已经好好的跑了很长时间了，为什么忽然就发生连续的FullGC了？这是个好问题，可能是因为以下原因：
1.可能是自从上次调优JVM的内存以后，应用的流量忽然变大了！可能是业务量增加了，用户数量变多了。
2.在业务峰值期间应用创建了比平时更多的对象，可能你并没有对峰值时候的应用内存做调优，或者是说应用峰值时候的流量变大了。
10、如何来解决连续的FullGC？
1.增加JVM的堆内存
因为连续的FullGC主要是由于内存不足引起的，增加JVM的堆内存可以解决这个问题。比如之前给应用分配的是2.5G的堆内存，现在增加到3G看能否解决问题，
通过给JVM传递-Xmx参数可以设置JVM的最大堆内存。-Xmx3G就设置了JVM的最大堆内存是3G。如果还是没解决问题，一点点的继续增加JVM的堆内存。
不要给JVM分配过多的堆内存，因为这会增加GC的停顿时间。
2.增加Perm或者Metaspace内存
如果Perm区或者是Metaspace太小也会导致连续的FullGC，这种情况下就需要增大Perm或者是Metaspace的内存。
3.增加更多的JVM实例
另一个解决此问题的办法就是增加更多的JVM实例。当有更多的JVM实例以后，应用流量就会分摊到这些实例上，单个JVM承担的流量就降低了，
那么它上面需要创建的对象随之也变少了，此时可能就不会有连续的FullGC了。
11、JVM内存模型的相关知识了解多少，比如重排序，内存屏障，happen-before，主内存，工作内存。
思路： 先画出Java内存模型图，结合例子volatile ，说明什么是重排序，内存屏障，最好能给面试官写以下demo说明。
Java内存模型规定了所有的变量都存储在主内存中，每条线程还有自己的工作内存，线程的工作内存中保存了该线程中是用到的变量的主内存副本拷贝，
线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存。不同的线程之间也无法直接访问对方工作内存中的变量，
线程间变量的传递均需要自己的工作内存和主存之间进行数据同步进行。
12、java内存模型中堆和栈的区别
1，管理方式，堆需要GC，栈自动释放
2.大小不同，堆比栈大
3.碎片相关：栈产生的碎片远小于堆，因为GC不是实时的
4.分配方式：栈支持静态分配内存和动态分配，堆只支持动态分配
5.效率：栈的效率比堆高
13、指令重排
代码指令可能并不是严格按照代码语句顺序执行的。大多数现代微处理器都会采用将指令乱序执行（out-of-order execution，简称OoOE或OOE）的方法，在条件允许的情况下，
直接运行当前有能力立即执行的后续指令，避开获取下一条指令所需数据时造成的等待3。通过乱序执行的技术，处理器可以大大提高执行效率。而这就是指令重排。
14、内存屏障
也叫内存栅栏，是一种CPU指令，用于控制特定条件下的重排序和内存可见性问题。
LoadLoad屏障：对于这样的语句Load1; LoadLoad; Load2，在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕。
StoreStore屏障：对于这样的语句Store1; StoreStore; Store2，在Store2及后续写入操作执行前，保证Store1的写入操作对其它处理器可见。
LoadStore屏障：对于这样的语句Load1; LoadStore; Store2，在Store2及后续写入操作被刷出前，保证Load1要读取的数据被读取完毕。
StoreLoad屏障：对于这样的语句Store1; StoreLoad; Load2，在Load2及后续所有读取操作执行前，保证Store1的写入对所有处理器可见。它的开销是四种屏障中最大的。 在大多数处理器的实现中，这个屏障是个万能屏障，兼具其它三种内存屏障的功能