面试-Jvm垃圾回收、性能调优以及类加载

朱雀 2022-04-02 10:30 143阅读 0赞

# 垃圾回收面试问题 #

## 关于垃圾回收我们必须要了解的知识 ##

 垃圾回收主要回收的是堆内存，基于分代的思想  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70]

## 内存怎么样分配 ##

** 对象分配**  
 优先在Eden区分配。当Eden区没有足够空间分配时, VM发起一次Minor GC, 将 Eden区和其中一块Survivor区内尚存活的对象放入另一块Survivor区域。如Minor GC时survivor空间不够，对象提前进入老年代，老年代空间不够时进行Full GC；  
 大对象直接进入老年代，避免在Eden区和Survivor区之间产生大量的内存复制, 此 外大对象容易导致还有不少空闲内存就提前触发GC以获取足够的连续空间.  
** 对象晋级**  
 年龄阈值：VM为每个对象定义了一个对象年龄(Age)计数器, 经第一次Minor GC后 仍然存活, 被移动到Survivor空间中, 并将年龄设为1. 以后对象在Survivor区中每熬 过一次Minor GC年龄就+1. 当增加到一定程度(-XX:MaxTenuringThreshold, 默认 15), 将会晋升到老年代.  
 提前晋升: 动态年龄判定；如果在Survivor空间中相同年龄所有对象大小的总和大 于Survivor空间的一半, 年龄大于或等于该年龄的对象就可以直接进入老年代, 而无 须等到晋升年龄.

## 那些要收回？对象生死判定 ##

 可达性分析算法  
通过一系列的称为 GC Roots 的对象作为起点, 然后向下搜索; 搜索所走过的路径 称为引用链/Reference Chain, 当一个对象到 GC Roots 没有任何引用链相连时, 即该对 象不可达, 也就说明此对象是不可用的;  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 1]  
**在Java, 可作为GC Roots的对象包括:**  
1.方法区: 类静态属性引用的对象;  
2.方法区: 常量引用的对象;  
3.虚拟机栈(本地变量表)中引用的对象  
4.本地方法栈JNI(Native方法)中引用 的对象。

## 怎么回收？方法论？分代收集 ##

 新生代-标记清除法  
该算法分为“标记”和“清除”两个阶段: 首先标记出所有需要回收的对象(可达性 分析), 在标记完成后统一清理掉所有被标记的对象.  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 2]  
 缺点  
 效率问题: 标记和清除过程的效率 都不高;  
 空间问题: 标记清除后会产生大量 不连续的内存碎片, 空间碎片太多,可能会导致在运行过程中需要分配  
较大对象时无法找到足够的连续内  
存而不得不提前触发另一次垃圾收集.

** 新生代-复制算法**  
该算法的核心是将可用内存按容量划分为大小相等的两块, 每次只用其中一块, 当 这一块的内存用完, 就将还存活的对象复制到另外一块上面, 然后把已使用过的内存空 间一次清理掉.  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 3]  
** 优点**  
 由于是每次都对整个半区进行内存 回收，内存分配时不必考虑内存碎 片问题。  
 垃圾回收后空间连续，只要移动堆 顶指针，按顺序分配内存即可；  
 特别适合java朝生夕死的对象特点  
** 缺点**  
 内存减少为原来的一半，太浪费了；  
 对象存活率较高的时候就要执行较 多的复制操作，效率变低；、  
 如果不使用50%的对分策略，老年 代需要考虑的空间担保策略

** 老年代-标记整理算法**  
该算法分为“标记”和“清除”两个阶段: 首先标记出所有需要回收的对象 ( 可达性 分析 ), 在标记完成后让所有存活的对象都向一端移动,然后清理掉端边界以外的 内存；  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 4]  
** 优点**  
 不会损失50%的空间；  
 垃圾回收后空间连续，只要移动堆 顶指针，按顺序分配内存即可；  
 比较适合有大量存活对象的垃圾回 收  
** 缺点**  
 标记/整理算法唯一的缺点就是效率 也不高，不仅要标记所有存活对象， 还要整理所有存活对象的引用地址。 从效率上来说，标记/整理算法要低 于复制算法。

## 实现回收？谁来做？垃圾回收器 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 5]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 6]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 7]

## JVM垃圾回收面试常见面试题 ##

 JVM垃圾回收面试常见面试题  
 垃圾回收常用的算法有哪些？特点是什么？（见垃圾回收算法）  
 哪几种垃圾收集器，各自的优缺点，重点讲下cms（见垃圾回收器）  
 jvm中一次完整的GC流程（从ygc到fgc）是怎样的，重点讲讲对象如何晋升到 老年代等（见内存怎么样分配）  
 JVM垃圾回收机制，何时触发MinorGC或FullGC等操作 答：从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC， 对老年代GC称为Major GC,而Full GC是对整个堆来说； Minor GC触发条件：当Eden区满时，触发Minor GC。 Full GC触发条件：  
 System.gc()  
 老年代空间不足  
 永生区空间不足  
 统计得到的Minor GC晋升

# 性能调优工具问题 #

1.  你常用的调优工具有哪些？
2.  如果碰到应用故障你怎么样排除问题

## java常用调优工具 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 8]

## 堆dump分析 ##

 堆dump分析：堆dump分析主要目的是定位OOM异常的原因；解决oom问题四 部曲：  
1.分析OOM异常的原因，堆溢出？栈溢出？本地内存溢出？  
2.如果是堆溢出，导出堆dump，并对堆内存使用有个整体了解； 3.找到最有可能导致内存泄露的元凶，通常也就是消耗内存最多的对象；  
4.使用辅助工具对dump文件进行分析；

##  注意其他几类造成OOM异常的原因 ##

1.Direct Memory  
2.线程堆栈：  
单线程：StackOverflowError  
多线程：OutOfMemoryError：unable to create new native thread  
3. Socket 缓冲区：IOException：Too many open files

## 线程dump分析 ##

 线程dump分析：线程dump分析主要目的是定位线程长时间停顿的原因  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 9]

## 应用故障你怎么样排除问题？ ##

** 应用故障一般指应用运行缓慢、用户体验差或者周期性的出现卡顿,排除的思路：**  
1.检查应用所在的生产环境的软硬件以及网络环境，排除外围因素；  
2.确定是否为OOM异常，这类异常影响最恶劣，但是比较容易排查；  
3.确定是否有大量长时间停顿的应用线程，非常占用cpu资源；  
4.周期性的卡顿很可能是垃圾回收造成，web后端系统建议使用cms垃圾回收器

# 类加载机制问题 #

## 类的完整生命周期 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 10]

## 什么时候出发类加载？ ##

1.使用new关键字实例化对象，读取或者设置一个类的静态变量的 时候，调用类 的静态方法的时候；  
2.对类进行反射调用的时候；  
3.初始化子类时，父类会先被初始化；  
4.对类使用动态代理的时候需要先被初始化；

## 谈下你对双亲委派模型理解？ ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 11]  
 双亲委派模型过程 某个特定的类加载器在接到加 载类的请求时，首先将加载任 务委托给父类加载器，依次递 归，如果父类加载器可以完成 类加载任务，就成功返回；只 有父类加载器无法完成此加载 任务时，才自己去加载

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 12]  
 双亲委派模型好处  
Java类随着它的类加载器一起具备了带有优先级的层次关系，保证java程序稳定运行

## tomcat类加载机制 ##

**同一个tomcat容器下的两个应用以及lib目录中都有UserServiceImpl类，tomcat怎 么样保证类的隔离性？**  
类加载器与类的唯一性：类加载器虽然只用于实现类的加载动作，但是对于任意一个类， 都需要由加载它的类加载器和这个类本身共同确立其在Java虚拟机中的唯一性。通俗的 说，JVM中两个类是否“相等”，首先就必须是同一个类加载器加载的，否则，即使这 两个类来源于同一个Class文件，被同一个虚拟机加载，只要类加载器不同，那么这两 个类必定是不相等的  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 13]

## tomcat类加载机制 ##

 Tomcat目录结构中，有三组目录（“/common/*”,“/server/*”和“shared/*”） 可以存放公用Java类库，此外还有第四组Web应用程序自身的目录“/WEB-INF/*”， 把java类库放置在这些目录中的含义分别是：  
 放置在common目录中：类库可被Tomcat和所有的Web应用程序共同使用。  
 放置在server目录中：类库可被Tomcat使用，但对所有的Web应用程序都不可见。  
 放置在shared目录中：类库可被所有的Web应用程序共同使用，但对Tomcat自己 不可见。  
 放置在/WebApp/WEB-INF目录中：类库仅仅可以被此Web应用程序使用，对 Tomcat和其他Web应用程序都不可见。  
 注意：tomcat的类加载机制是违反了双亲委托原则的，对于一些未加载的非基础 类(Object,String等)，各个web应用自己的类加载器(WebAppClassLoader)会优 先加载，加载不到时再交给commonClassLoader走双亲委托

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70]: /images/20220402/8ed5af5458494faeafb9efcd46228eae.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 1]: /images/20220402/70cce6310d6d44fdad170da837d13e02.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 2]: /images/20220402/2ed0e33b86364a829c06ee93f6423376.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 3]: /images/20220402/c9c6aa77318f40c2a33c186b6ff5d39c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 4]: /images/20220402/858e347717af4da2ae6eed151ddea117.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 5]: /images/20220402/affbee5b8e0f4c598b27da665e51231c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 6]: /images/20220402/977c4750a6744744b7a90aeadbd01138.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 7]: /images/20220402/bdf7a00ce42d4ae299820aa16b80cadf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 8]: /images/20220402/7ddd409baee6477ab45720845675d0cc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 9]: /images/20220402/79ab0c46ba5b4773b203e95a1957d9f7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 10]: /images/20220402/41dbdc60b76745e18a2b38ca47d00751.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 11]: /images/20220402/4be748489dea43ed9b90bfea39603b39.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 12]: /images/20220402/8ee3b8c8dd4843bc9062eaa78aeec2d5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 13]: /images/20220402/d9b6b0183a5f4cd5bc6b7e6dd2edd139.png