JVM 堆内存模型镇楼。
读《深入理解Java 虚拟机》第三章GC算法,关于 GC Roots 枚举的段落没说透彻,理解上遇到困惑。因此对这点进行扩展并记录,发现国内各种博客写来写去都是几乎相同的分析,还是没厘清困惑:GC Roots 究竟是如何枚举的,其中用到的 OopMap 是一个什么样的数据结构?
1、标记清除算法(Mark-Sweep)
2、复制算法(Copying)
3、标记整理算法(Mark-Compact)
三种算法都用到了 可达性分析 方法来对对象进行标记清除。
找到瓜藤的根。
从根节点出发,顺藤摸瓜,每次摸到一个瓜,就打上标记--这瓜还没熟,别摘!
瓜熟蒂落,那些没被标记上的瓜自然就是熟了的瓜,统统收走拿去吃掉。
以上过程对应的伪代码如下:
Void GC() { HaltAllProcessing(); ObjectCollection roots = GetRoots(); for(int i=0; i<roots.Count(); ++i) { Mark(roots[i]); } Sweep(); } 复制代码
For your application code to reach an object, there should be a root object which is connected to your object as well as capable of accessing from outside the heap. Such root objects that are accessible from outside the Heap are called Garbage Colllection (GC) roots. There are several types of GC roots such as Local variables, Active Java threads, Static variables, JNI References etc. (Just take the ideology here, if you do a quick google search, you may find many conflicting classifications of GC roots)
对于一个 Java 程序而言,对象都位于堆内存块中,存活的那些对象都被根节点引用着,即根节点 GC Roots 是一些引用类型,自然不在堆里,那它们位于哪呢?它们能放在哪呢?
答案是放在栈里,包括:
Local variables 本地变量
Static variables 静态变量
JNI References JNI引用等
GC Roots are objects that are themselves referenced by the JVM and thus keep every other object from being garbage-collected.
1、笨方法:遍历栈里所有的变量,逐一进行类型判断,如果是 Reference 类型,则属于 GC Roots。
2、高效方法:从外部记录下栈里那些 Reference 类型变量的类型信息,存成一个映射表 -- 这就是 OopMap 的由来 。
“在解释执行时/JIT时,记录下栈上某个数据对应的数据类型,比如地址1上的”12344“值是一个堆上地址引用,数据类型为com.aaaa.aaa.AAA)
现在三种主流的高性能JVM实现,HotSpot、JRockit和J9都是这样做的。其中,HotSpot把这样的数据结构叫做 OopMap ,JRockit里叫做livemap,J9里叫做GC map。”
GC 时,直接根据这个 OopMap 就可以快速实现根节点枚举了。
参考链接:
Understanding Java Garbage Collection
JVM中的OopMap