(转)GC ROOTS

还是英文的技术博客更给力,更清楚,本人懒,没有翻译。

In your specific example, in any managed environment, Person is not a GC root; the GC root is the thingwhich holds the reference to Person. The difference is subtle, but important in the context of this question. Although my answer is specific to Java it is in general correct for any managed language. Your last paragraph is actually correct, but conflicts with the example given.

The GC (Garbage Collector) roots are objects special for garbage collector. The Garbage Collector collects those objects that are not GC roots and are not accessible by references from GC roots.

There are several kinds of GC roots. One object can belong to more than one kind of root. The root kinds are:

  • Class - class loaded by system class loader. Such classes can never be unloaded. They can hold objects via static fields. Please note that classes loaded by custom class loaders are not roots, unless corresponding instances of java.lang.Class happen to be roots of other kind(s).
  • Thread - live thread
  • Stack Local - local variable or parameter of Java method
  • JNI Local - local variable or parameter of JNI method
  • JNI Global - global JNI reference
  • Monitor Used - objects used as a monitor for synchronization
  • Held by JVM - objects held from garbage collection by JVM for its purposes. Actually the list of such objects depends on JVM implementation. Possible known cases are: the system class loader, a few important exception classes which the JVM knows about, a few pre-allocated objects for exception handling, and custom class loaders when they are in the process of loading classes. Unfortunately, JVM provides absolutely no additional detail for such objects. Thus it is up to the analyst to decide to which case a certain "Held by JVM" belongs.
 

If you think of the objects in memory as a tree, the "roots" would be the root nodes - every object immediately accessible by your program.

Person p = new Person();
p.car = new Car(RED);
p.car.engine = new Engine();
p.car.horn = new AnnoyingHorn();

There are four objects; a person, a red car, its engine and horn. Draw the reference graph:

     Person [p]
        |
     Car (red)
   /           Engine    AnnoyingHorn

And you‘ll end up with Person at the "root" of the tree. It‘s live because it‘s referenced by a local variable, p, which the program might use at any time to refer to the Person object. This also goes for the other objects, through p.carp.car.engine, etc.

Since Person and all other objects recursively connected to it are live, there would be trouble if the GC collected them.

Consider, however, if the following is run after a while:

p.car = new Car(BLUE);

And redraw the graph:

     Person [p]
        |
     Car (blue)       Car (red)
                    /                           Engine    AnnoyingHorn

Now the Person is accessible through p and the blue car through p.car, but there is no way the red car or its parts can ever be accessed again - they are not connected to a live root. They can be safely collected.

So it‘s really a matter of taking every starting point (every local variable, globals, statics, everything in other threads and stack frames) — every root — and recursively following all the references to make up a list of all the "live" objects: objects which are in use and unsuitable for deletion. Everything else is garbage, waiting to be collected.

时间: 2024-07-28 22:23:28

(转)GC ROOTS的相关文章

GC roots 总结

previous      content      next GC roots The so-called GC (Garbage Collector) roots are objects special for garbage collector. Garbage collector collects those objects that are not GC roots and are not accessible by references from GC roots. There ar

什么是GC Roots

GC Root 2012年11月28日  ? 综合 ? 共 625字 ? 字号  小 中 大  ? 评论关闭 常说的GC(Garbage Collector) roots,特指的是垃圾收集器(Garbage Collector)的对象,GC会收集那些不是GC roots且没有被GC roots引用的对象. 一个对象可以属于多个root,GC root有几下种: Class - 由系统类加载器(system class loader)加载的对象,这些类是不能够被回收的,他们可以以静态字段的方式保存

枚举GC Roots的实现

枚举根节点 从可达性分析中从GC Roots节点找引用链这个操作为例,可作为GC Roots的节点主要在全局性的引用(例如常量或类静态属性)与执行上下文(例如栈帧中的本地变量表)中,现在很多应用仅仅方法区就有数百兆,如果要逐个检查这里面的引用,那么必然会消耗很多时间.另外,可达性分析对执行时间的敏感还体现在GC停顿上,因为这项分析工作必须在一个能确保一致性的快照中进行--这里"一致性"的意思是指在整个分析期间整个执行系统看起来就像被冻结在某个时间点上,不可以出现分析过程中对象引用关系还

枚举GC Roots根节点

引言 判断对象是否被回收的算法有引用计数算法和可达性分析算法.其中可达性分析算法是根据GC Roots根节点作为起始点向下搜索引用链,找不到引用链则判定对象可回收. 可作为GC Roots根节点的对象主要是在全局性的引用(如常量.类静态属性)和执行上下文中(如栈帧中的本地变量表),现在的很多应用仅方法区就有数百兆,逐个检查里边的引用显然很耗费时间. 枚举GC Roots根节点 在HotSpot实现中,利用了空间换取时间,是使用一组OopMap的数据结构来完成的.类加载完成后,会把对象内什么偏移量

Java 内存区域和GC机制

目录 Java垃圾回收概况 Java内存区域 Java对象的访问方式 Java内存分配机制 Java GC机制 垃圾收集器 Java垃圾回收概况 Java GC(Garbage Collection,垃圾收集,垃圾回收)机制,是Java与C++/C的主要区别之一,作为Java开发者,一般不需要专门编写内存回收和垃圾清理代 码,对内存泄露和溢出的问题,也不需要像C程序员那样战战兢兢.这是因为在Java虚拟机中,存在自动内存管理和垃圾清扫机制.概括地说,该机制对 JVM(Java Virtual M

Java内存区域划分和GC机制

Java 内存区域和GC机制 目录 Java垃圾回收概况 Java内存区域 Java对象的访问方式 Java内存分配机制 Java GC机制 垃圾收集器 Java垃圾回收概况 Java GC(Garbage Collection,垃圾收集,垃圾回收)机制,是Java与C++/C的主要区别之一,作为Java开发者,一般不需要专门编写内存回收和垃圾清理代 码,对内存泄露和溢出的问题,也不需要像C程序员那样战战兢兢.这是因为在Java虚拟机中,存在自动内存管理和垃圾清扫机制.概括地说,该机制对 JVM

JVM GC算法 垃圾回收器

JVM的垃圾回收算法有三种: 1.标记-清除(mark-sweep):啥都不说,直接上图 2.标记-整理(mark-compact) 3.复制(copy) 分代收集算法                                                    目前的垃圾回收都采用分代收集算法.也就衍生了很多垃圾收集器 "分代收集"(Generational Collection)算法,把Java堆分为新生代和老年代,这样就可以根据各个年代的特点采用最适当的收集算法. 在新生

简单谈谈JVM中的GC(中)

书接上文,在了解JVM的分代模型后,接着来简单聊聊JVM中GC算法和不同的GC收集器[求关注] GC回收算法 一个GC回收算法通常会做这么几件事: 1.遍历内存,找到被引用的对象 2.清理掉这些未被标记对象的内存 3.被清理掉的内存放回内存中,供其他地方使用 上文也提及过,目前JVM中的搜索引用对象是用的根搜索方式,再重复引用下: 所有的Java对象构成一颗近似"搜索树"的结构,有一个root根节点,每次从root出发向下搜索,当整个树遍历完成后,那些不在其中的变量则视为"垃

JAVA-虚拟机(2)-GC算法&回收器

垃圾回收主要内容: 1. 那些内存需要回收? 2. 什么时候回收? 3. 如何回收? 垃圾回收主要针对运行时数据区那些区域? 运行时数据区的线程私有区域有:虚拟机栈,本地方法栈,程序计数器等: 栈中的栈帧随着方法的进入和退出执行入栈和出栈,每个栈帧的内存分配在编译期就已经确定: 随着线程或方法的结束,内存也随着回收: 运行时数据区的线程共享区域有:方法区,堆: 方法区和堆只有程序处于运行期才能确定创建那些对象,因此这部分内存分配和回收都是动态的: 垃圾回收的重点区域: 一,对象存活判断 1,引用