【Java常见问题】基础知识（七）内存管理（垃圾回收机制）

分代思想

• 分为年轻代、老年代、永久代。
• 年轻代分为：

• Java8中移除了永久代，转而由MetaSpace代替（一块本地化的堆内存区）

为什么要移除永久代？

• 发现这部分区域的内存经常不够用或发生泄露。
• 虚拟机之一的JRockit没有永久代。

MetaSpace如何进行内存分配？

基本思想：类与类加载器有相同的生命周期

Java中垃圾回收算法的演进

• 串行回收

Java1.3.1之前仅支持Serial（串口）

• 并行回收

利用多核特性

• 并发标记清理回收（CMS,Mostly Concurrenct Mark and Sweep）

垃圾回收与用户程序同时进行

• 并发回收(G1) 清理大的堆内存空间时可满足特定的暂停应用的时间

关于CMS？

在年轻代中使用拷贝算法（会暂停用户线程），在老年代中使用CMS（避免将用户线程暂停太长时间）。

如何实现呢？通过一个空闲链表来管理回收的空间。

具体执行步骤分为如下几个阶段：

• 初始标记：

标记的是老年代中由root直接可达、或被年轻代引用的对象。

• 并发标记：

遍历老年代，从上一步标记的节点开始，标记所有被引用的对象。

• 并发预清理

将上一步中发生了引用关系变化的结点标记为dirty，并对其可达节点进行标记，以防遗漏。

• 并行可被终止预清理

执行部分预清理，减少最终标记阶段导致的暂停时间

• 重标记

暂停用户线程，最终确定并标记老年代中的存活对象

• 并行清理

删除不再被使用的对象并回收相应内存空间

• 并发重置

重置数据结构，为下一次清理做准备

关于G1?

简介

全称为Garbage First,顾名思义，回收的垃圾优先。（由于看不懂网上的文章，笔者去翻了一下官方文档），以下是对关键信息的提炼：

G1会尽最大可能地保证能暂停用户线程；几乎不需要配置；能保证在延迟和高吞吐之间找到平衡。

它适用的应用和环境有如下特点：

• 堆大小达到10GB或以上，50%的Java堆都存在活数据（笔者注：服务器级别的）
• 对象分配和提升的速率可能会随时间发生显著变化。
• 堆中有大量碎片
• 可预测的目标暂停时间不超过几百毫秒。

使用方法

截止java9，它仍 默认 是GC模式（后面的我没看了），如果需要显式指定，就在命令行中加入-XX:+UseG1GC参数。

基础概念

G1是一个分代的、递增的、并行的、主要是并发的、将所有应用线程暂停下来的、疏散的垃圾回收器。它在每一个暂停阶段都能管理目标暂停时间（也就是预测）。

空间重用集中在年轻代，偶尔会发生在老年代。

上图可理解为对上上图的更详细说明。

上图解释了 疏散 的原理：

在选定的内存区域内找到要收集的活动对象并复制到新的内存区域，并在此过程中压缩它们。疏散完成后，活动对象先前占用的空间将重新用于应用程序分配。

注意它不是一个实时的模型，不能绝对保证就是暂停预测时间，只是能保证在相对长的时间之后尽可能地达到目标。

堆分层模型

上图来源于官方文档，显示了G1对于堆元素的划分方式，它们被划分为了一个个大小相同的块。其中灰色的表示空；蓝色的表示老年代；红色的表示年轻代（青春是热情似火的）；“S”字符表示“Survivor”，还存活；“H”表示“humongous”，巨大的（也就是连续占了不止一个小块）

垃圾回收循环

上图源于官方文档，显示了G1算法中的几个阶段。

其他关于G1的实现及设置

• 关于初始堆容量比例的设置

这个数值和老年代的占比息息相关

• 关于标记的问题

  

  笔者认为这一段可以总结为：由于循环的存在，不用过多担心标记错误的问题，它总会在后来的阶段被正确标记。

• 堆资源很紧张的情况下会如何做？

  

  上图指出了几大关键点：

1. 撤离失败发生的背景：应用程序保持活动状态的内存过多，以至于撤离找不到足够的空间进行复制
2. 表现：G1 尝试通过将已移动的任何对象保留在其新位置来完成当前垃圾回收，而不复制任何尚未移动的对象，仅调整对象之间的引用
3. 时机：撤离失败被假定发生在垃圾回收接近尾声时。此时大多数对象都已移动，并且有足够的空间继续运行应用程序
4. 如果还是不行，就会启用full-gc方案（我的理解是全部推倒重来）

• 关于堆中的大对象

  

  上图指出了如下几点：

1. 大对象的存放位置及形式：对象的起始位置就是块的起始区域，序列最后一个区域中的任何剩余空间都将丢失以进行分配。
2. 重回收的时机：在清理暂停期间 标记快结束时、或者Full-gc阶段。
3. 给大对象分配空间有可能导致垃圾回收过早执行
4. 大对象的位置不能动

浅谈JVM调优所使用的常见参数

JVM的管理是一个很重要的问题，比如单就针对OutOfMemoryError Exception这一类报错，官方文档就洋洋洒洒地写了一大段文字，列举了多种情况：

感兴趣的uu可以看看原文： Understand the OutOfMemoryError Exception

那么在实际调优的过程中，可以从哪些方面去考虑呢？可以从JVM机制对应的内容去考虑：（具体参数参考官方文档）

• 堆内存相关
  • 指定最大堆和最小堆的值（建议设为相同的值）
  • 设置MetaSpace的大小
  • 设置年轻代空间的初始大小、最大值、整个年轻代空间的大小（可用于计算老年代空间）
• 将对内存写入文件，便于诊断问题
• 指定垃圾回收算法
• 记录并查看GC日志

常见问题

Java是否存在内存泄露的问题？

内存泄露主要有两种情况：

• 堆中申请的空间没有被释放。垃圾回收机制可以解决这一问题
• 对象不再使用，但仍保留在内存中。Java已有的机制无法保证这一种情况不出现

如下场景可能会导致上述第二种情况的发生：

• 使用静态集合类，比如静态的容器Vector、HashMap等
• 不及时关闭各种连接，如数据库、网络、I/O等
• 释放对象的同时没有删除相应监听器
• 变量定义的作用范围大于其使用范围则有一定风险
• 使用单例模式

Java中堆和栈的区别？

• 栈主要存放基本数据类型和引用变量；堆用于存放运行时创建的对象
• 栈用于执行程序时，变量会通过压栈出栈操作在栈中被回收；堆中的对象由gc自动回收。

作者：逐光而行
链接：https://juejin.cn/post/7218110901551562810