1. 描述一下jvm内存模型，以及这些空间的存放的内容 ？
2.堆内存划分的空间，如何回收这些内存对象，有哪些回收算法？
垃圾回收算法： 标记清除、复制（多为新生代垃圾回收使用）、标记整理
3.如何解决线上gc频繁的问题？
查看监控，以了解出现问题的时间点以及当前FGC的频率（可对比正常情况看频率是否正常）
了解该时间点之前有没有程序上线、基础组件升级等情况。
了解JVM的参数设置，包括：堆空间各个区域的大小设置，新生代和老年代分别采用了哪些垃 圾收集器，然后分析JVM参数设置是否合理。
再对步骤1中列出的可能原因做排除法，其中元空间被打满、内存泄漏、代码显式调用gc方法 比较容易排查。
针对大对象或者长生命周期对象导致的FGC，可通过 jmap -histo 命令并结合dump堆内存文件作进一步分析，需要先定位到可疑对象。
通过可疑对象定位到具体代码再次分析，这时候要结合GC原理和JVM参数设置，弄清楚可疑 对象是否满足了进入到老年代的条件才能下结论。
4.描述一下class初始化过程？
一个类初始化就是执行clinit()方法，过程如下：
父类初始化
static变量初始化/static块（按照文本顺序执行）
Java Language Specification中，类初始化详细过程如下（最重要的是类初始化是线程安全的）：
每个类都有一个初始化锁LC，进程获取LC（如果没有获取到，就一直等待）
如果C正在被其他线程初始化，释放LC并等待C初始化完成
如果C正在被本线程初始化，即递归初始化，释放LC
如果C已经被初始化了，释放LC
如果C处于erroneous状态，释放LC并抛出异常NoClassDefFoundError
否则，将C标记为正在被本线程初始化，释放LC；然后， 初始化那些final且为基础类型的类成员变量
初始化C的父类SC和各个接口SI_n（按照implements子句中的顺序来） ；如果SC或SIn初始化过程中抛出异常，则获取LC，将C标记为erroneous，并通知所有线程，然后释放LC，然后 再抛出同样的异常。
从classloader处获取assertion是否被打开
接下来， 按照文本顺序执行类变量初始化和静态代码块，或接口的字段初始化，把它们当作是一个个单独的代码块。
如果执行正常，获取LC，标记C为已初始化，并通知所有线程，然后释放LC
否则，如果抛出了异常E。若E不是Error，则以E为参数创建新的异常ExceptionInInitializerError作为E。如果因为OutOfMemoryError导致无法创建ExceptionInInitializerError，则将OutOfMemoryError作为E。
获取LC，将C标记为erroneous，通知所有等待的线程，释放LC，并抛出异常E
5.简述一下内存溢出的原因，如何排查线上问题？
内存溢出的原因
java.lang.OutOfMemoryError: …java heap space. 堆栈溢出，代码问题的可能性极大
java.lang.OutOfMemoryError: GC over head limit exceeded 系统处于高频的GC状态，而且回收的效果依然不佳的情况，就会开始报这个错误，这种情况一般是产生了很多不可以被释放 的对象，有可能是引用使用不当导致，或申请大对象导致，但是java heap space的内存溢出有可能提前不会报这个错误，也就是可能内存就直接不够导致，而不是高频GC.
java.lang.OutOfMemoryError: PermGen space jdk1.7之前才会出现的问题 ，原因是系统的代码非常多或引用的第三方包非常多、或代码中使用了大量的常量、或通过intern注入常量、 或者通过动态代码加载等方法，导致常量池的膨胀
java.lang.OutOfMemoryError: Direct buffer memory 直接内存不足，因为jvm垃圾回收不会回收掉直接内存这部分的内存，所以可能原因是直接或间接使用了ByteBuffer中的allocateDirect方法的时候，而没有做clear
java.lang.StackOverflowError - Xss设置的太小了
java.lang.OutOfMemoryError: unable to create new native thread 堆外内存不足，无法为线程分配内存区域
java.lang.OutOfMemoryError: request {} byte for {}out of swap 地址空间不够
6.jvm有哪些垃圾回收器，实际中如何选择？
图中展示了7种作用于不同分代的收集器，如果两个收集器之间存在连线，则说明它们可以搭配使用。虚 拟机所处的区域则表示它是属于新生代还是老年代收集器。
新生代收集器（全部的都是复制算法）：Serial、ParNew、Parallel Scavenge
老年代收集器：CMS（标记-清理）、Serial Old（标记-整理）、Parallel Old（标记整理） 整堆收集器： G1（一个Region中是标记-清除算法，2个Region之间是复制算法）
同时，先解释几个名词：
并行（Parallel）：多个垃圾收集线程并行工作，此时用户线程处于等待状态
并发（Concurrent）：用户线程和垃圾收集线程同时执行
吞吐量：运行用户代码时间／（运行用户代码时间＋垃圾回收时间）
1.Serial收集器是最基本的、发展历史最悠久的收集器。
特点： 单线程、简单高效（与其他收集器的单线程相比），对于限定单个CPU的环境来说，Serial收集器 由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程手机效率。收集器进行垃圾回收 时，必须暂停其他所有的工作线程，直到它结束（Stop The World）。
应用场景： 适用于Client模式下的虚拟机。
Serial / Serial Old收集器运行示意图：
2.ParNew收集器其实就是Serial收集器的多线程版本。
除了使用多线程外其余行为均和Serial收集器一模一样（参数控制、收集算法、Stop The World、对象分配规则、回收策略等）。
特点： 多线程、ParNew收集器默认开启的收集线程数与CPU的数量相同，在CPU非常多的环境中，可以 使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。
和Serial收集器一样存在Stop The World问题
应用场景： ParNew收集器是许多运行在Server模式下的虚拟机中首选的新生代收集器，因为它是除了
Serial收集器外，唯一一个能与CMS收集器配合工作的。
ParNew/Serial Old组合收集器运行示意图如下：
3.Parallel Scavenge 收集器与吞吐量关系密切，故也称为吞吐量优先收集器。
特点： 属于新生代收集器也是采用复制算法的收集器，又是并行的多线程收集器（与ParNew收集器类 似）。
该收集器的目标是达到一个可控制的吞吐量。还有一个值得关注的点是：GC自适应调节策略（与
ParNew收集器最重要的一个区别）
GC自适应调节策略： Parallel Scavenge收集器可设置-XX:+UseAdptiveSizePolicy参数。当开关打开时不需要手动指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRation）、晋升老年代 的对象年龄（-XX:PretenureSizeThreshold）等，虚拟机会根据系统的运行状况收集性能监控信息，动 态设置这些参数以提供最优的停顿时间和最高的吞吐量，这种调节方式称为GC的自适应调节策略。
Parallel Scavenge收集器使用两个参数控制吞吐量：
XX:MaxGCPauseMillis 控制最大的垃圾收集停顿时间
XX:GCRatio 直接设置吞吐量的大小。
4.Serial Old是Serial收集器的老年代版本。
特点： 同样是单线程收集器，采用标记-整理算法。
应用场景： 主要也是使用在Client模式下的虚拟机中。也可在Server模式下使用。
Server模式下主要的两大用途（在后续中详细讲解···）：
在JDK1.5以及以前的版本中与Parallel Scavenge收集器搭配使用。
作为CMS收集器的后备方案，在并发收集Concurent Mode Failure时使用。
Serial / Serial Old收集器工作过程图（Serial收集器图示相同）：
5.Parallel Old是Parallel Scavenge收集器的老年代版本。
特点： 多线程，采用标记-整理算法。
应用场景： 注重高吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge+Parallel Old 收集器。
6.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。
