Java虚拟机学习笔记（二）——内存回收与内存分配

最新推荐文章于 2025-06-08 14:58:08 发布

零号元素

最新推荐文章于 2025-06-08 14:58:08 发布

阅读量259

点赞数

CC 4.0 BY-SA版权

分类专栏： JAVA 文章标签：内存分配内存回收 JVM

本文链接：https://blog.youkuaiyun.com/weixin_36904568/article/details/90263946

JAVA 专栏收录该内容

21 篇文章

订阅专栏

本文深入探讨Java内存管理机制，包括内存分配策略、垃圾回收算法及不同收集器的特性。解析了对象存活判断标准、内存回收过程及如何选择最适合的垃圾收集器。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一：内存回收

1. 哪些内存需要回收？

本地方法栈、Java方法栈、程序计数器：内存的分配和回收具备确定性，在方法结束或线程结束后，自动回收内存
Java堆、方法区：内存的分配和回收具备动态性，需要GC回收内存

（1）Java堆中的不可用对象

判断对象是否存活的标准——引用

如果reference类型的数据中存储的数值代表的是另外一个内存的起始地址，则这块内存代表一个引用

引用类型	引用对象	特点
强引用	必需的对象	只要强引用还存在，则被引用的对象不会被回收
软引用（SoftReference）	有用不必需的对象	在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围，进行二次回收
弱引用（WeakReference）	不必需对象	在垃圾收集器下一次工作时回收
虚引用（PhantomReference）		不会对生存时间产生影响，也无法获取实例，作用是在对象被回收时获取系统通知

判断对象是否存活的算法

引用计数算法

给对象添加一个引用计数器，每当有一个地方引用时，计数器加1；引用失效时，计数器减1；当计数器为0时，对象不可用

缺点：无法解决对象之间的相互循环引用问题

根搜索算法

通过一系列的名为GC Roots的对象作为起点，从这些结点开始向下搜索，走过的路径为引用链，如果一个对象和GC Roots之间没有任何引用链，则证明该对象不可用

GC Roots：

虚拟机栈（栈帧的本地变量表）中引用的对象
方法区中类静态属性引用的对象
方法区中常量引用的对象
本地方法栈中JNI引用的对象

二次标记对象

第一次标记：对象在根搜索后发现没有与GCRoots相连的引用链，准备死亡
- 没有必要执行finalize()：对象没有覆盖finalize()，虚拟机已经执行finalize() 。（对象死亡，finalize只能执行一次）
- 有必要执行finalize()：对象放置在F-Queue队列中，由虚拟机自动建立的低优先级的线程Finalizer执行（对象还有复活机会）
第二次标记：在F-Queue队列的对象，无法通过finalize()方法重新与引用链上的对象建立关系，对象死亡

（2）方法区中的废弃常量和没有用的类

判断常量是否存活的标准——引用

当前是否有对象或方法引用常量池中的某个常量、方法、符号引用等

判断类是否有用

类的所有实例已经被回收
加载该类的类加载器已经被回收
该类对应的Class对象没有被引用，也无法通过反射访问该类的方法

2. 怎么回收内存？

（1）标记-清除算法

首先标记出所有需要回收的对象，在标记完成后统一回收对象

特点

效率低
产生大量不连续的空间碎片

（2）复制算法（新生代）

将可用内存按容量划分为大小相等的两块，每次只使用其中一块。在内存用完后将可用对象复制到另一块内存，然后清除使用过的内存

特点

不会产生内存碎片，只需要按顺序分配内存
代价大

商业虚拟机的改进

将内存分为一块比较大的Eden空间和两块比较小的Survivor空间，每次使用一块Eden空间和一块Survivor空间。在回收时将所有可用的对象一次性复制到另外一块Survivor空间，然后清除使用过的内存。
假如Survivor内存空间不够，就需要依赖老年代内存进行分配担保

（3）标记-整理算法（老年代）

首先标记出所有需要回收的对象，在标记完成后让所有存活对象向一端移动，再清理掉端边界以外的对象

（4）分代收集算法

根据对象的存活周期将对象划分为几块，根据各个年代的特点选择合适的算法

新年代：只有少量对象存活，使用复制算法
老年代：对象存活率高，使用标记-整理算法或标记-清除算法

3. 垃圾收集器

并发：用户线程与收集线程同时执行（可能交替进行）
并行：用户线程等待，多个收集线程并行工作

（1）Serial收集器

最基本、历史最悠久的收集器，也是虚拟机运行在Client模式下的默认收集器

特点

是单线程的，在它进行垃圾收集时必须暂停其他所有的工作线程
简单而高效，在单CPU环境中没有线程交互的开销

（2）ParNew收集器

多线程版本的Serial收集器，也是虚拟机运行在Server模式下的首选新生代收集器

特点

使用多线程进行垃圾收集
除了Serial收集器以外，唯一能与CMS收集器合作
在多CPU环境下，默认开启的线程数与CPU数相同（通过-XX:ParallelGCThreads参数限制线程数）

（3）Parallel Scavenge收集器

并行的多线程收集器，也是使用复制算法的新生代收集器

特点

目的是控制吞吐量，适合在后台运算，不需要太大交互的任务
- -XX:MaxGCPauseMills：设置最大垃圾收集的停顿时间
- -XX:GCTimeRatio ：垃圾收集时间占总时间的比率，是吞吐量的倒数
- -XX:UseAdaptiveSizePolicy：GC自适应调节策略

（4）Serial Old收集器

老年代版本的Serial收集器，也是使用标记-整理算法的单线程收集器。

特点

主要是在Client模式下的虚拟机使用
如果是在Server模式下，可以与Parallel Scavenge收集器配合，也可以作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure使用

（5）Parallel Old收集器

老年代版本的Parallel Scavenge收集器，也是使用标记-整理算法的多线程收集器。

特点

在注重吞吐量和CPU资源敏感的场合，不考虑以前单线程下的组合（Parallel Scavenge收集器+Serial Old收集器），而是优先考虑多线程组合（Parallel Scavenge收集器+Parallel Old收集器）

（6）CMS（并发低停顿）收集器

以一种获取最短回收停顿时间为目标的收集器，基于标记-清除算法的收集器

过程

总体来说，CMS的回收过程与用户线程并发执行

初始标记：标记GC Roots能直接关联的对象
并发标记：根搜索算法的二次标记
重新标记：修正因为用户程序继续运作导致标记变动的对象的标识记录
并发清除：清除标记的对象

特点

注重垃圾收集的停顿时间，适合在前台运算，需要交互的任务
对CPU资源非常敏感：可能会占用一部分CPU资源导致程序变慢，总吞吐量降低
- 增量式并发收集器I-CMS：在并发标记和并发清理的时候，GC线程和用户程序交替运行，减少GC占用资源的时间
无法处理浮动垃圾：在并发清除阶段产生的新垃圾，CMS无法等待垃圾产生的差不多再收集，因为需要预留内存空间给用户程序运行。
- 如果预留空间不足以运行用户程序，可能出现Concurrent Mode Failure，导致另一次Full GC的产生（启动后备方案Serial Old收集器）
- 可以通过-XX:CMSInitiatingOccupancyFraction，设置老年代空间被使用N%后开始收集
产生大量空间碎片
- 通过-XX:+UseCMSCompactAtFullCollection，进行碎片整理（增加停顿时间）
- 通过-XX:CMSFullGCsBeforeCompaction，设置回收N次后进行碎片整理

（7）G1收集器

最前沿的收集器，基于标记-整理算法的收集器

特点

没有空间碎片
精确控制停顿
不牺牲吞吐量的前提下完成低停顿回收。将整个Java堆划分为多个区域，每次只回收垃圾最多的区域

（8）使用组合

命令	收集器
-XX:UseSerialGC	使用Serial收集器
-XX:UseParNewGC	使用ParNew+Serial Old收集器
-XX:UseConcMarkSweepGC	使用ParNew+Serial Old+CMS收集器
-XX:UseParallelGC	使用Parallel Scavenge+Serial Old收集器
-XX:UseParallelOldGC	使用Parallel Scavenge+Parallel Old收集器