CMS垃圾回收器详解

最新推荐文章于 2024-07-27 15:57:59 发布
最新推荐文章于 2024-07-27 15:57:59 发布
阅读量1.2k 收藏
点赞数
分类专栏： JVM 文章标签： jvm java linux 算法
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/HoraceDH/article/details/114640067
版权
一、哪些对象可以回收
1、引用计数法

算法过程：每个对象有一个引用计数器，当对象被引用一次计数器就加一，引用失效就减一，对于计数器为0的对象表示为垃圾对象，可以被GC回收。

缺点：无法解决循环引用的问题，例如：A引用了B，B引用了A，但是A和B都没有被其他对象引用，这样就会导致内存泄漏，无法被回收。

2、可达性分析法

算法过程：
通过一系列被称为GC Roots的对象作为起点开始搜索，所经过的路径被称为引用链，当一个对象没有跟任何一个引用链相连接的时候，表示从GC Roots对象到这个对象不可达，意味着这是一个垃圾对象可以被回收。

适用场景：Java虚拟机是采用这种算法对垃圾进行回收，解决了循环引用的问题。

可以作为GC Roots对象有：虚拟机栈，静态成员，常量，本地方法栈引用的对象。

二、垃圾回收算法
1、标记清除

算法过程：首先标记出需要回收的对象，标记完成后统一回收。

缺点：主要有两个缺点，一个是标记和清除两个过程的效率都不算高（据资料显示）。另一个是空间问题，标记清除后，会产生不连续的内存碎片，当需要分配大对象时，无法找到足够连续的内存，导致分配失败提前触发GC。

2、复制算法

算法过程：将内存分为两部分，每次只使用其中一块内存。回收时将存活的对象复制到另一块区域，之后将已使用的内存区域一次性全部清理掉。

优点：解决了空间碎片的问题，存活对象少时，提升了回收效率。

缺点：一个是内存使用率缩小了，因为永远有一块空闲的内存备用。另一个是当存活对象较多时复制效率低下。

3、标记整理

算法过程：标记整理的算法过程跟标记清除的标记过程是一样的，但标记后是将存活的对象都想某一端移动，然后清理边界以外的内存。

优点：解决了内存碎片的问题。

4、分代收集

概念：JVM内存区域是分代的，分为：年轻代、老年代、永久代（元数据区）和两个幸存区。根据不同的算法特点，在不同分代中使用不同的算法进行垃圾回收。

年轻代、幸存区：由于Java对象在很多场景下，都是朝生夕死的，所以在这几个区间适合使用复制算法。

老年代、永久代：永久代或者元数据区用于存储一些类信息、常量池等数据，老年代一般也是存活比较久的对象，因此适合用标记清除和标记整理算法。

三、CMS介绍
1、介绍

老年代收集器，需要配合Serial或者ParNew使用，一般是与ParNew使用。CMS全称Concurrent Mark-Sweep。CMS出现的目标是为了降低延迟，减少回收停顿时间。适合对延迟、停顿时间敏感的应用使用。通过 -XX:+UseConcMarkSweepGC开启。

2、回收阶段

CMS-initial-mark(STW)：通过可达性分析算法，从GC Roots对象开始扫描能够直接关联到的对象，并做标记，需要STW，但是一般会很快完成。

CMS-concurrent-mark：从初始标记的基础上，继续向下搜索并做标记，这个阶段应用线程和GC线程并发执行，不会造成停顿。

CMS-concurrent-preclean：查找并发标记阶段中，新进入老年代的对象，包括晋升到老年代和直接在老年代分配的对象，目的是减少下一个阶段重新标记的时间。

CMS-concurrent-abortable-preclean：可中断的预清理，这个阶段做的事情跟并发预清理的事情一样，目的是为了减少下一个阶段STW的时间，这个阶段有几个个条件控制何时结束。

A、-XX:CMSScheduleRemarkEdenSizeThreshold=2，该阶段在Eden区占用超过2M时启动。

B、-XX:CMSMaxAbortablePrecleanTime=5000，设置一个最大时间最大执行5秒钟。

C、-XX:CMSScheduleRemarkEdenPenetration=50，Eden区使用率超过50就停止该阶段进入remark阶段。

D、-XX:+CMSScavengeBeforeRemark，控制remark阶段前进行一次minor gc，来提高remark的效率，减少时间。

CMS-remark(STW)：重新标记，处理上几次以来可能引用关系发生变化的部分，并重新进行标记，这个阶段会停止应用线程

CMS-concurrent-sweep：真正的清理阶段，将以上几个步骤标记的无法访问的对象进行并发清理，并将清理的空间回收到空闲列表中

CMS-concurrent-reset：调整堆大小，重置一些内部的数据结构，为下一次回收做准备

3、缺点

A、无法处理浮动垃圾，因为这是一款并发的收集器，程序运行和收集的同时都会产生垃圾，所以回收时不能向其他收集器一样等到满了的时候再收集，通过-XX:CMSInitiatingOccupancyFraction=65设置触发的百分比，留出一定的空间给并发收集的时候使用，当CMS运行期间无法满足程序的需要，则会出现，此时会临时使用Serial Old作为临时方案进行一次标记整理的回收，这样就会使得出现较为长期的停顿，所以-XX:CMSInitiatingOccupancyFraction=65不能设置太高。

B、由于是使用标记清除算法的收集器，因此会产生内存碎片，为了解决这个问题，垃圾收集器提供了一个-XX:+UseCMSCompactAtFullCollection的开关参数，表示再一次FGC时进行一次内存整理的过程，这个过程是无法并发的，会拉长停顿时间，收集器还提供另一个参数，-XX:CMSFullGCsBeforeCompaction=5表示FGC几次后进行一次内存整理。

4、优化措施

优化目标：减少STW停顿时间

优化手段：

A、降低触发CMS回收的百分比，给并发收集时留出一定的空间，避免Concurrent Mode Failure，通过-XX:CMSInitiatingOccupancyFraction=65配置

B、开启内存压缩，避免碎片问题无法分配大内存对象，通过-XX:+UseCMSCompactAtFullCollection和-XX:CMSFullGCsBeforeCompaction=5，具体数值可以按需调配。

C、减少CMS-remark(STW)阶段的时间，通过-XX:+CMSScavengeBeforeRemark、-XX:CMSMaxAbortablePrecleanTime=5000、-XX:CMSScheduleRemarkEdenPenetration=50进行微调。

5、相关参数
参数说明
-Xloggc:/dev/shm/xxx_gc.log设置GC日志路径
-XX:+PrintGCDateStamps打印GC时间
-XX:+PrintGCDetails打印GC详细信息
-XX:+PrintGCApplicationStoppedTime打印应用停顿时间
-XX:+PrintGCApplicationConcurrentTime打印应用当前时间
-XX:+PrintSafepointStatistics打印安全点统计信息
-XX:+UnlockDiagnosticVMOptions解锁诊断型参数
-XX:-DisplayVMOutput禁用控制台输出VM信息，例如安全点日志
-XX:+LogVMOutput启用日志输出VM日志
-XX:LogFile=/dev/shm/safepoint.log设置VM日志输出路径
-XX:CMSScheduleRemarkEdenPenetration=20设置Eden区使用率超过20%就进入remark阶段
-XX:CMSMaxAbortablePrecleanTime=1500设置可中断预清理阶段最大执行时间
-XX:+CMSScavengeBeforeRemark设置期望进入remark阶段前进行一次MinorGC
-XX:+PrintReferenceGC打印引用处理信息
-XX:+UseConcMarkSweepGC使用CMS收集器
-XX:+UseParNewGC使用ParNew收集器
-XX:+CMSParallelRemarkEnabledremark阶段采用并行多线程模式
-XX:+UseCMSCompactAtFullCollection开启压缩整理功能
-XX:CMSFullGCsBeforeCompaction=0设置CMS多少次后进行一次压缩
-XX:+CMSClassUnloadingEnabled开启回收永久代
-XX:+UseCMSInitiatingOccupancyOnly设置CMS回收时机一直按照Fraction配置进行
-XX:CMSInitiatingOccupancyFraction=60设置老年代内存使用率超过60时开始CMS回收
-XX:+AlwaysPreTouch启动时申请所需内存，避免系统调用延迟
6、日志分析

以下是一次完整的CMS回收日志，需要配置以下参数

2019-07-17T21:54:50.216+0800: 190007.616: [GC [1 CMS-initial-mark: 1258440K(2097152K)] 1294890K(3984640K), 0.0365050 secs] [Times: user=0.04 sys=0.01, real=0.04 secs]
2019-07-17T21:54:50.253+0800: 190007.654: Total time for which application threads were stopped: 0.0455330 seconds
2019-07-17T21:54:50.254+0800: 190007.654: [CMS-concurren
t-mark-start]
2019-07-17T21:54:50.413+0800: 190007.813: [CMS-concurrent-mark: 0.159/0.159 secs] [Times: user=0.91 sys=0.02, real=0.16 secs]
2019-07-17T21:54:50.413+0800: 190007.814: [CMS-concurrent-preclean-start]
2019-07-17T21:54:50.413+0800: 190007.814: [Preclean SoftReferences, 0.0005560 secs]2019-07-17T21:54:50.414+0800: 190007.814: [Preclean WeakReferences, 0.0011690 secs]2019-07-17T21:54:50.415+0800: 190007.815: [Preclean FinalReferences, 0.0000350 secs]2019-07-17T21:54:50.415+0800: 190007.815: [Preclean PhantomReferences, 0.0000070 secs]2019-07-17T21:54:50.425+0800: 190007.825: [CMS-concurrent-preclean: 0.011/0.011 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
2019-07-17T21:54:50.425+0800: 190007.826: [CMS-concurrent-abortable-preclean-start]
 CMS: abort preclean due to time 2019-07-17T21:54:51.938+0800: 190009.338: [CMS-concurrent-abortable-preclean: 1.508/1.512 secs] [Times: user=2.46 sys=0.16, real=1.51 secs]
2019-07-17T21:54:51.938+0800: 190009.338: Application time: 1.6846120 seconds
2019-07-17T21:54:51.946+0800: 190009.346: [GC[YG occupancy: 351451 K (1887488 K)]2019-07-17T21:54:51.946+0800: 190009.347: [GC2019-07-17T21:54:51.949+0800: 190009.350: [ParNew2019-07-17T21:54:51.979+0800: 190009.379: [SoftReference, 2284 refs, 0.0002550 secs]2019-07-17T21:54:51.979+0800: 190009.379: [WeakReference, 5 refs, 0.0000150 secs]2019-07-17T21:54:51.979+0800: 190009.379: [FinalReference, 679 refs, 0.0002280 secs]2019-07-17T21:54:51.979+0800: 190009.380: [PhantomReference, 0 refs, 0.0000120 secs]2019-07-17T21:54:51.979+0800: 190009.380: [JNI Weak Reference, 0.0000100 secs]: 351451K->23085K(1887488K), 0.0330260 secs] 1609892K->1282310K(3984640K), 0.0370030 secs] [Times: user=0.26 sys=0.01, real=0.04 secs]
2019-07-17T21:54:51.984+0800: 190009.384: [Rescan (parallel) , 0.0272010 secs]2019-07-17T21:54:52.011+0800: 190009.411: [weak refs processing2019-07-17T21:54:52.011+0800: 190009.411: [SoftReference, 5341 refs, 0.0020150 secs]2019-07-17T21:54:52.013+0800: 190009.413: [WeakReference, 0 refs, 0.0000220 secs]2019-07-17T21:54:52.013+0800: 190009.413: [FinalReference, 80 refs, 0.0002020 secs]2019-07-17T21:54:52.013+0800: 190009.414: [PhantomReference, 0 refs, 0.0000120 secs]2019-07-17T21:54:52.013+0800: 190009.414: [JNI Weak Reference, 0.0000230 secs], 0.0023470 secs]2019-07-17T21:54:52.013+0800: 190009.414: [class unloading, 0.0198310 secs]2019-07-17T21:54:52.033+0800: 190009.434: [scrub symbol table, 0.0100610 secs]2019-07-17T21:54:52.043+0800: 190009.444: [scrub string table, 0.0011130 secs] [1 CMS-remark: 1259224K(2097152K)] 1282310K(3984640K), 0.1204410 secs] [Times: user=0.48 sys=0.02, real=0.12 secs]
2019-07-17T21:54:52.067+0800: 190009.468: Total time for which application threads were stopped: 0.1293860 seconds
2019-07-17T21:54:52.068+0800: 190009.468: [CMS-concurrent-sweep-start]
2019-07-17T21:54:52.747+0800: 190010.147: [CMS-concurrent-sweep: 0.679/0.679 secs] [Times: user=1.24 sys=0.09, real=0.68 secs]
2019-07-17T21:54:52.747+0800: 190010.147: [CMS-concurrent-reset-start]
2019-07-17T21:54:52.753+0800: 190010.153: [CMS-concurrent-reset: 0.006/0.006 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]

通用字段解析

日志内容含义
2019-07-17T21:54:50.216+0800GC发生的时间，系统当前时间
190007.616虚拟机从启动到现在经过的时间
[Times: user=0.04 sys=0.01, real=0.04 secs]当前过程耗时情况，user表示运行用户代码时间，sys表示系统调用以及系统级等待的时间，real表示实际时间

CMS-initial-mark

日志内容含义
1258440K(2097152K) 1258440K回收前老年代占用大小，2097152K：老年代总大小
1294890K(3984640K) 1294890K整堆内存占用大小，3984640K：堆内存总大小

CMS-concurrent-mark

日志内容含义
[Preclean SoftReferences, 0.0005560 secs]该阶段处理软引用的时间
[Preclean WeakReferences, 0.0011690 secs]该阶段处理弱引用的时间
[Preclean FinalReferences, 0.0000350 secs]该阶段处理最终引用的时间
[Preclean PhantomReferences, 0.0000070 secs]该阶段处理虚引用的时间
[CMS-concurrent-preclean: 0.011/0.011 secs]预清理阶段耗费的时间

CMS-concurrent-abortable-preclean

日志内容含义
[CMS-concurrent-abortable-preclean: 1.508/1.512 secs]可中断预清理阶段耗费的时间，该阶段并行，不会STW

YG occupancy

日志内容含义
GC[YG occupancy: 351451 K (1887488 K)表示该阶段是MinorGC，351451表示年轻代占用大小，1887488年轻代总大小
351451K->23085K(1887488K), 0.0330260 secs351451K年轻代回收前大小，23085K年轻代回收后大小，1887488K年轻代总大小，耗时0.0330260

CMS-remark

日志内容含义
[Rescan (parallel) , 0.0272010 secs]重新标记花费的时间
[class unloading, 0.0198310 secs]类卸载花费的时间
[scrub symbol table, 0.0100610 secs]刷新符号表耗费的时间
[scrub string table, 0.0011130 secs]刷新常量池耗费的时间？
[1 CMS-remark: 1259224K(2097152K)]1282310K(3984640K), 0.1204410 secs] 1259224K老年代占用大小，2097152K老年代总大小，1282310K堆内存占用大小，3984640K堆内存总大小，耗时0.1204410s
四、实战
1、测试代码
/**
 * 堆溢出测试
 * -Xms100m -Xmx100m -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/dump.hprof
 *
 * @author Horace
 */
public class HeapOOMTest {
    private static Logger logger = LoggerFactory.getLogger(HeapOOMTest.class);

    public static void main(String[] args) {
        int _1M = 1024 * 1024;
        List<byte[]> bytes = new ArrayList<>();
        while (true) {
            bytes.add(new byte[_1M]);
            LockSupport.parkNanos(TimeUnit.MILLISECONDS.toNanos(1000));
        }
    }
}
2、查看GC情况

本地环境界面查看工具 jvisualvm
每1秒输出一次GC情况
jstat -gccause pid 1s

以下是GC情况

 S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT    LGCC                 GCC
 89.83   0.00  42.05  37.10  94.37  90.41      2    0.025     0    0.000    0.025 Allocation Failure   No GC
 89.83   0.00  46.58  37.10  94.37  90.41      2    0.025     0    0.000    0.025 Allocation Failure   No GC
 89.83   0.00  51.00  37.10  94.37  90.41      2    0.025     0    0.000    0.025 Allocation Failure   No GC
 89.83   0.00  54.74  37.10  94.37  90.41      2    0.025     0    0.000    0.025 Allocation Failure   No GC
 89.83   0.00  58.49  37.10  94.37  90.41      2    0.025     0    0.000    0.025 Allocation Failure   No GC
 89.83   0.00  63.69  37.10  94.37  90.41      2    0.025     0    0.000    0.025 Allocation Failure   No GC
 89.83   0.00  67.44  37.10  94.37  90.41      2    0.025     0    0.000    0.025 Allocation Failure   No GC
 89.83   0.00  71.19  37.10  94.37  90.41      2    0.025     0    0.000    0.025 Allocation Failure   No GC
 89.83   0.00  75.71  37.10  94.37  90.41      2    0.025     0    0.000    0.025 Allocation Failure   No GC
 89.83   0.00  79.46  37.10  94.37  90.41      2    0.025     0    0.000    0.025 Allocation Failure   No GC
 89.83   0.00  83.98  37.10  94.37  90.41      2    0.025     0    0.000    0.025 Allocation Failure   No GC
 89.83   0.00  87.72  37.10  94.37  90.41      2    0.025     0    0.000    0.025 Allocation Failure   No GC
 89.83   0.00  92.14  37.10  94.37  90.41      2    0.025     0    0.000    0.025 Allocation Failure   No GC

各个字段表示的含义可以查看：

https://docs.oracle.com/javase/8/docs/technotes/tools/unix/jstat.html#BEHHGFAE
命令行dump内存快照
jmap -heap dump:live,format=b,file=/tmp/dump.hprof
dump出来的内存可以通过jprofile、mat、jhat等工具进行分析
五、如何看JVM源码
1、源码下载地地址
http://jdk.java.net/java-se-ri/8
2、下载之后导入到IDEA中，cms垃圾收集器源码路径
hotspot/src/share/vm/gc_implementation/concurrentMarkSweep 包中
3、核心文件
hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
在这个文件的4550行，可以看到关于abortable_preclean阶段的实现 void CMSCollector::abortable_preclean()
HoraceDH
关注
专栏目录
CMS垃圾回收器介绍
Deronn的博客
09-05 7325
CMS
CMS垃圾回收期详解
note__book的博客
09-11 516
CMS 1.CMS ​ CMS是一种已获取最短回收停顿时间为目标的收集器。出发点是java应用集中在互联网网址或者基于浏览器的B/S系统 的服务器上，这类应用通常关注服务的响应速度，希望系统停顿时间尽可能短，已给用户更好的交互体验 ​ CMS在名称中就包含了其垃圾回收的理念，MS（Mark Sweep）标记清除算法。 1.1 cms的处理过程 初始标记：仅仅标记一些GCROOTS直接关联的对象，STW（停顿时间），很短 并发标记：从GCROOTS的直接关联对象开始，遍历整个对象图的过程 重新标记：修正在并
CMS 垃圾回收器
weixin_44981707的博客
05-29 5242
CMS 垃圾回收器1. cms 回收过程分析1.1 初始标记（initial-mark）1.2 并发标记（concurrent-mark）1.3.1 Card Table1.3.2 mod-union table1.3 并发预清理 （concurrent-preclean）1.4 可中断预清理（concurrent-abortable-preclean）1.5 重新标记（remark）1.6 并发清除（concurrent-sweep）1.7 并发重置（concurrent reset）2. cms 日志解
JVM 性能分析—— 一文带你读懂 CMS 垃圾收集器收集流程
最新发布
longool的博客
07-27 923
在详细讲解 CMS 与 G1 垃圾收集器之前，先介绍其中的一些知识点，方便后续理解。
CMS垃圾回收器
程序媛的一生
03-05 1329
刚才转了关于cms回收期的文章，但是还是不太理解，又重新读了一下书，终于懂了，分享一下，强迫症太可怕，一点了，不记录博客睡不着 与parallelGC和paralleloldGC不同，CMS回收期主要关注于系统停顿时间，cms cocurrent mark sweep的缩写，意味并发标记清除，从名称上就可以得知，它使用的是标记清楚算法，同时他又是一个使用多线程并行回收的垃圾回收器
CMS垃圾回收
han_dada的博客
06-14 455
内存分代 算法 标记-清除 特点 并发收集器，以最短的停顿时间为目标的收集器 不足 对CPU资源敏感，GC线程占用CPU资源高影响吞吐量 需要预留一些空间，保证触发后台垃圾回收而不是fullgc 标记-清除会产生内存碎片，虽然可以设置执行多少次不压缩的GC来一次压缩的GC，但是由于整理过程无法并发所以这时停顿时间会较长 回收过程 1. 初始标记(STW) 标记与GCRoots直接关联的对象...
Java 垃圾回收机制详解及实例代码
08-31
此外，JVM提供了多种垃圾收集器，如Serial、Parallel、CMS（并发标记扫描）、G1（垃圾优先）等，它们在性能、停顿时间、吞吐量等方面各有特点，开发者可以根据应用程序的需求选择合适的垃圾收集器。 总结起来，Java...
JVM之垃圾回收器：CMS垃圾回收器
xylitolz的博客
04-11 1004
文章目录CMS工作原理总结CMS变化Reference CMS垃圾回收器 简介 JDK1.5时期，HotSpot推出了一款在强交互应用中有划时代意义的垃圾收集器：CMS(Concurrent-Mark-Sweep)收集器，这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程同时工作 回收方式 标记-清除算法、并发回收和"Stop-the-world"机制 回收区域 老年代 应用场景 CMS收集器的关注点是尽可能缩短垃圾收集时用
Java垃圾回收器详解
m0_56085369的博客
06-30 2445
垃圾回收器 类型 本文涉及的垃圾回收器主要有以下的四种: 串行垃圾回收器 吞吐量优先的垃圾回收器 响应时间优先的垃圾回收器 G1垃圾回收器 JDK8默认使用的是吞吐量优先的垃圾回收器，JDK9默认使用的是G1垃圾回收器 串行垃圾回收器 特点 单线程(仅仅指垃圾回收线程，用户线程可以是多个的) 堆内存较少，适合个人电脑 相关的VM参数 -XX:+UseSerialGC 开启串行垃圾回收器 工作流程 串行垃圾回收器的工作分为了两个部分，分别称为Serial和SerialOld。 Seria
聊一聊CMS垃圾回收器
ln82799的博客
01-16 3390
CMS垃圾回收器的名字是（Ccrrent Mark Sweep并发标记清除），是一款采用标记清理算法回收老年代的垃圾回收器！ 并发性 cms与其他回收器的不同是cms只有在根节点枚举阶段的时候会stop the world，其他阶段可以和用户线程并发执行，极大的降低了用户线程的暂停时间。特别适用于互联网网站或者B/S系统的服务端上，这类重视服务响应速度的，给用户良好的体验的情况。 清理过程 cms回收垃圾分为四个步骤： 初始标记：根节点枚举，枚举全部的GC Roots对象。此阶段会stw，但是耗时极短。
JVM --并发垃圾回收器CMS
yushui的笔记本
07-14 1655
1.总体介绍：CMS(Concurrent Mark-Sweep)是以牺牲吞吐量为代价来获得最短回收停顿时间的垃圾回收器。对于要求服务器响应速度的应用上，这种垃圾回收器非常适合。在启动JVM参数加上-XX:+UseConcMarkSweepGC ，这个参数表示对于老年代的回收采用CMS。CMS采用的基础算法是：标记—清除。 2.CMS过程：初始标记(STW initial mark) 并发标记(C
CMS 回收器——低延迟
实践求真知
07-30 281
一点睛 在 JDK1.5 时期，Hotspot 推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器：CMS（Concurrent-Mark-Sweep）收集器，这款收集器是 HotSpot 虚拟机中第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程同时工作。 CMS 收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间。停顿时间越短（低延迟）就越适合与用户交互的程序，良好的响应速度能提升用户体验。 目前很大一部分的 Java 应用集中在互联网站或者 B/S 系统的服务端上.
Java JVM垃圾回收机制详解
"JVM垃圾回收机制探讨，包括对象的可达性判断、常见垃圾收集算法以及各种垃圾收集器的介绍。" 在Java虚拟机（JVM）中，垃圾回收（Garbage Collection, GC）是一项关键功能，它自动管理内存，释放不再使用的对象所...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值