Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

标记-清除法中被标记的对象 #82

Closed
huangsansui opened this issue Dec 13, 2018 · 4 comments
Closed

标记-清除法中被标记的对象 #82

huangsansui opened this issue Dec 13, 2018 · 4 comments
Labels
enhancement New feature or request or suggestion

Comments

@huangsansui
Copy link

huangsansui commented Dec 13, 2018

搞定JVM垃圾回收就是这么简单 中 标记-清除法的描述为:

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

我在网上搜索了一些资料,有的写的是 标记可回收对象,有的写的是 标记不可回收对象。

之后找到一个issues可供参考:

crossoverJie/JCSprout#131

参考维基百科里的说法:

The first stage is the mark stage which does a tree traversal of the entire 'root set' and marks each object that is pointed to by a root as being 'in-use'.

被标记的应为 在用(不可回收)对象

https://en.wikipedia.org/wiki/Tracing_garbage_collection#Na.C3.AFve_mark-and-sweep

CMS收集器这部分内容中描述有前后矛盾的地方:

初始标记: 暂停所有的其他线程,并记录下直接与root相连的对象,速度很快 ;
并发标记: 同时开启GC和用户线程,用一个闭包结构去记录可达对象。但在这个阶段结束,这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域,所以GC线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。
重新标记: 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录,这个阶段的停顿时间一般会比初始标记阶段的时间稍长,远远比并发标记阶段时间短
并发清除: 开启用户线程,同时GC线程开始对为标记的区域做清扫

标记阶段对不可回收对象标记,在清除时对标记区域清扫。不就是把不可回收对象清除掉了?

@Snailclimb
Copy link
Owner

嗯嗯 这段描述是我参考《深入理解Java虚拟机》第2版的 我再看看

@Snailclimb Snailclimb added the enhancement New feature or request or suggestion label Mar 14, 2019
@wangxuanni
Copy link

我看的时候也对这个问题产生了困惑,如果是标记可回收对象,标记整理算法不就不太合理了吗,标记的可回收对象,然而移动的是存活对象,这样的话就要绕一个弯了。因此《深入理解Java虚拟机》第2版那本书可能表述有误。

@carlos19960601
Copy link

《深入理解Java虚拟机 》这本书有很多地方是有误的,学习者建议结合知乎上R大的回答来学习

@Corey956
Copy link

Corey956 commented Jul 19, 2019 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request or suggestion
Projects
None yet
Development

No branches or pull requests

5 participants