Thinking in java-4 Java内存管理之垃圾回收Garbage Collection_garbagecollector copy: accumulated time spent in c

作者：程序代码艺术家 | 2024-01-30 20:43:25

踩

garbagecollector copy: accumulated time spent in collection

1. 垃圾回收机制

1.1. 自动垃圾回收

Java编程语言的一个特色就是其自动垃圾回收机制，不像C/C++那样，内存的分配和释放都是程序员手动操作的。

有人认为，碎片化(not GC)是影响java程序性能的主要原因。当前主流（并不一定是最新的）的处理堆内存碎片化问题的解决方式是分代GC&紧致（Generational GC & compaction)。

1.2. GC的运行原则和机制

Garbage Collector垃圾回收器，是在后台运行的程序，它照看所有内存中的对象，找到没被程序中任何其他部分所引用的对象。所有这些未被引用的对象被删除，其空间被释放用来分配给其他对象。

当我们命令行运行一个程序时，如果设置命令行参数java -Xmx:2g MyApp , 则表示分配了2g的内存给该java进程，即heap内存。在程序运行时，总有堆内存耗尽的时刻，这时新的线程因为没有连续内存空间而无法被创建。这个时候JVM决定开始进行garbage collection，当然我们也可以显式地调用Sys tem.gc()来建议JVM进行垃圾回收 (之所以说是建议，因为JVM并不一定保证会进行垃圾回收)。

GC的进行需要有2个条件满足：1). 绝不回收当前依然存活的对象--有活跃引用的对象。2). 成为垃圾的对象dead objects也不是保证被立即回收的。这取决于回收策略：是保证足够的内存使用还是保证系统整体的延迟和吞吐量的考量。

1.3. 2类垃圾回收方案：

a). Referencing Counting collectors: 引用计数垃圾回收器

思想：记录下指向每一个对象的引用数量，一旦一个对象的引用数为0则将其回收。

优点：可以立即对称为垃圾的对象进行回收，速度快；且算法简单。

缺点：其一，当对象过多时，开销大；其二，主要原因--无法解决循环引用对象问题Circular referencing.\

b). Tracing collectors: 跟踪回收器

思想：所有活的 live对象可以在当前已知的活的对象（root object 存在于 registers, global fields, stack frames）中找到其引用。

优点：解决了循环结构问题（本文之后所有内容都是针对于Tracing collectors而言的）。

缺点：对大部分跟踪收集器而言，在标记阶段--在回收未被引用的垃圾对象时需要等待。

1.4. 2大类Tracing Collector

1.4.1 复制回收器Coping Collectors

原理：在堆上有2块单独定义的地址from-space & to-space，在垃圾回收时，from-space的存活的对象被复制到to-space中，然后from-space中进行垃圾回收。

优点：在 to-space中对象在内存中很紧致地放在一起，完全没有了内存碎片化的烦恼。

缺点：复制回收器是一种 stop-the-world collector，意味着在垃圾回收循环中，其他应用不能执行，这对于需要高响应速度的应用而言无法容忍；而且，当from-space中的所有对象都不是垃圾--都是live对象时，to-space需要有很大空间存放from-space内容，这也使得其效率很差。

1.4.2 标记-清理回收器Mark-and-sweep collector

大部分商业JVM是使用mark-and-sweep 垃圾收集器的，因为它没有copy-collector的负面性能缺点。一些最著名的回收策略包括：CMS, G1, GenPar( link)都是采用mark-and-sweep策略的！

原理：mark-and-sweep 垃圾回收器跟踪并标记每个live对象用一个'live'标志位。在所有的live对象都已被mark之后，进行的将是sweep操作；sweep将遍历整个heap空间，找到未被标记的内存空间地址，收集器将这些未被标

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/article/detail/49346