blocks|key|2883525|text|典型的现代JVM使用几种不同类型的垃圾收集器。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2883526|一种经常用于已存在一段时间的对象的类型称为Mark-and-Sweep。它基本上涉及从已知的“活动”对象(所谓的垃圾收集根)开始，遵循所有对象引用链，并将每个可到达的对象标记为“活动的”。|offset|length|2883527|一旦完成此操作，清除阶段就可以回收那些未标记为“活动”的对象。|2883528|要使此过程正常工作，JVM必须知道每个对象引用在内存中的位置。这是垃圾收集器成为+(Java的是)的必要条件。|2883529|entityMap|0|LINK|mutability|MUTABLE|url|http://www.brpreiss.com/books/opus5/html/page424.html^0|0|L|E|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

A typical modern JVM uses several different types of garbage collectors.

One type that's often used for objects that have been around for a while is called <a href="http://www.brpreiss.com/books/opus5/html/page424.html">Mark-and-Sweep</a>. It basically involves starting from known "live" objects (the so-called garbage collection roots), following all chains of object references, and marking every reachable object as "live".

Once this is done, the sweep stage can reclaim those objects that haven't been marked as "live".

For this process to work, the JVM has to know the location in memory of every object reference. This is a necessary condition for a garbage collector to be <a href="http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Precise_vs._conservative_and_internal_pointers">precise</a> (which Java's is).

blocks|key|230173|text|GC将知道可以尽可能快地删除对象。您不需要管理此流程。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|230174|但您可以非常礼貌地要求GC使用System.gc()运行。这只是对系统的一个提示。因为GC是大老板，而我们(Java程序员)只是它的从属……:(|offset|length|style|CODE|230175|entityMap^0|0|F|B|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

GC will know that object can be removed as quickly as it is possible. You are not expected to manage this process.

But you can ask GC very politely to run using <code>System.gc()</code>. It is just a tip to the system. GC does not have to run at that moment, it does not have to remove your specific object etc. Because GC is the BIG boss and we (Java programmers) are just its slaves... :(

blocks|key|2883590|text|Java有各种不同的垃圾收集策略，但它们基本上都是通过跟踪已知的活动对象可以到达的对象来工作的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2883591|在文章How+Garbage+Collection+works+in+Java中可以找到一个很好的总结，但是对于真正的细节，您应该看看Tuning+Garbage+Collection+with+the+5.0+Java[tm]+Virtual+Machine|offset|length|2883592|2883593|当运行中的程序中的任何指针都不能再到达一个对象时，它被认为是垃圾。最直接的垃圾收集算法只是遍历每个可到达的对象。剩下的任何对象都会被认为是垃圾。这种方法所需的时间与活动对象的数量成正比，这对于维护大量活动数据的大型应用程序来说是禁止的。|blockquote|2883594|2883595|从J2SE+Platform+V1.2开始，虚拟机合并了许多不同的垃圾收集算法，这些算法使用分代收集进行组合。虽然朴素的垃圾收集检查堆中的每个活动对象，但分代收集利用了大多数应用程序的几个经验上观察到的属性来避免额外的工作。|2883596|在这些观察到的属性中，最重要的是婴儿死亡率。..。|2883597|2883598|也就是说，许多像迭代器这样的对象只存在很短的时间，所以较年轻的对象比较老的对象更有可能被垃圾回收。|2883599|有关更多最新的优化指南，请查看：|2883600|2883601|Java+SE+6+HotSpot[tm]+Virtual+Machine+Garbage+Collection+Tuning|unordered-list-item|2883602|+Java+Platform,+Standard+Edition+HotSpot+Virtual+Machine+Garbage+Collection+Tuning+Guide+(Java+8)|2883603|2883604|顺便说一句，要小心地猜测你的垃圾收集策略，我知道许多程序的性能会因为过度热衷于使用System.gc()或不适当的-XX选项而变得垃圾。|style|CODE|2883605|entityMap|0|LINK|mutability|MUTABLE|url|http://javarevisited.blogspot.co.uk/2011/04/garbage-collection-in-java.html|1|http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html|2|http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html|3|http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/index.html^0|0|3|10|0|1V|1R|1|0|0|0|0|0|0|0|0|0|0|0|1R|2|0|0|2G|3|0|0|15|B|1L|3|0^^$0|@$1|2|3|4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1J|8|@]|9|@$D|1K|E|1L|1|1M]|$D|1N|E|1O|1|1P]]|A|$]]|$1|F|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|1R|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|1S|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|1T|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1U|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1W|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1X|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|U|3|V|5|W|7|1Z|8|@]|9|@$D|20|E|21|1|22]]|A|$]]|$1|X|3|Y|5|W|7|23|8|@]|9|@$D|24|E|25|1|26]]|A|$]]|$1|Z|3|-4|5|6|7|27|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|28|8|@$D|29|E|2A|12|13]|$D|2B|E|2C|12|13]]|9|@]|A|$]]|$1|14|3|-4|5|6|7|2D|8|@]|9|@]|A|$]]]|15|$16|$5|17|18|19|A|$1A|1B]]|1C|$5|17|18|19|A|$1A|1D]]|1E|$5|17|18|19|A|$1A|1F]]|1G|$5|17|18|19|A|$1A|1H]]]]

Java has a variety of different garbage collection strategies, but they all basically work by keeping track which objects are reachable from known active objects.
A great summary can be found in the article <a href="http://javarevisited.blogspot.co.uk/2011/04/garbage-collection-in-java.html" rel="nofollow noreferrer">How Garbage Collection works in Java</a> but for the real low-down, you should look at <a href="http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html" rel="nofollow noreferrer">Tuning Garbage Collection with the 5.0 Java[tm] Virtual Machine</a>
<blockquote>
An object is considered garbage when it can no longer be reached from any pointer in the running program. The most straightforward garbage collection algorithms simply iterate over every reachable object. Any objects left over are then considered garbage. The time this approach takes is proportional to the number of live objects, which is prohibitive for large applications maintaining lots of live data.
Beginning with the J2SE Platform version 1.2, the virtual machine incorporated a number of different garbage collection algorithms that are combined using generational collection. While naive garbage collection examines every live object in the heap, generational collection exploits several empirically observed properties of most applications to avoid extra work.
The most important of these observed properties is infant mortality. ...
</blockquote>
I.e. many objects like iterators only live for a very short time, so younger objects are more likely to be eligible for garbage collection than much older objects.
For more up to date tuning guides, take a look at:
<ul>
<li><a href="http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html" rel="nofollow noreferrer">Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning</a></li>
<li><a href="http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/index.html" rel="nofollow noreferrer"> Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide</a> (Java SE 8)</li>
</ul>
Incidentally, be careful of trying to second guess your garbage collection strategy, I've known many a programs performance for be trashed by over zealous use of <code>System.gc()</code> or inappropriate <code>-XX</code> options.

blocks|key|230233|text|没有有效的方法-它仍然需要遍历堆，但有一种棘手的方法:当堆被分成更小的部分时(因此不需要扫描整个堆)。这就是我们使用分代垃圾收集器的原因，以便扫描花费更少的时间。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|230234|当您的整个应用程序停止时，这是相对“容易”的回答，并且您可以分析对象的图形。这一切都是从GC+roots开始的(我会让您找到这些是什么的文档)，但基本上这些都是GC没有收集到的“根”。|offset|length|style|CODE|230235|从这里开始一个特定的扫描，分析“活动”对象:与这些根有直接(或传递)连接的对象，因此是不可回收的。在图论中，我们知道通过使用3种颜色来“着色/遍历”你的图形:黑色，灰色和白色。White意味着它没有连接到根，grey意味着它的子图还没有被遍历，black意味着遍历并连接到根。所以基本上，要知道现在到底什么是死的/活的-你只需要把所有最初是白色的堆都涂成黑色。所有的white都是垃圾。有趣的是，“垃圾”实际上是由GC通过知道什么是活的来标识的。例如，有一些图形可以可视化这个here。|230236|但这是一个简单的场景:当您的应用程序完全停止时(有时是几秒钟)，您可以扫描堆。这就是所谓的STW+-停止世界事件，人们通常讨厌这些事件。这就是并行收集器所做的事情:停止一切，做任何GC必须做的事情(包括查找垃圾)，让应用程序线程在那之后启动。|230237|当你的应用程序运行时，当你在扫描堆的时候会发生什么？Concurrently？G1/CMS会这样做。想想看:当你的应用程序可以通过不同的线程更改树叶时，你如何推断图表中的叶子是活动的还是不活动的。|230238|例如，Shenandoah通过“拦截”图形上的更改来解决这个问题。在与应用程序并发运行时，它将捕获所有更改并将这些更改插入到一些称为SATB+Queues+(请求队列处的快照)的线程本地特殊队列中；而不是直接更改堆。当该操作完成时，将发生一个非常短的STW事件，这些队列将被排空。仍然在STW下，计算该排出所“引起”的内容，即:对图进行额外着色。这非常简单，仅供参考。G1和CMS的做法是不同的。|230239|230240|因此，从理论上讲，这个过程并不是那么复杂，但同时实现它是最具挑战性的部分。|230241|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/58924737/could-increase-gc-time-short-lived-object-that-has-references-to-old-lived-objec/58984342#58984342^0|0|18|8|28|2|0|2G|5|2W|4|3E|5|53|5|5R|2|6M|4|0|0|19|3|0|Q|C|13|6|0|3|A|1U|B|3H|3|3Z|3|54|2|57|3|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@$D|12|E|13|F|G]|$D|14|E|15|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|16|8|@$D|17|E|18|F|G]|$D|19|E|1A|F|G]|$D|1B|E|1C|F|G]|$D|1D|E|1E|F|G]|$D|1F|E|1G|F|G]]|9|@$D|1H|E|1I|1|1J]]|A|$]]|$1|J|3|K|5|6|7|1K|8|@$D|1L|E|1M|F|G]]|9|@]|A|$]]|$1|L|3|M|5|6|7|1N|8|@$D|1O|E|1P|F|G]|$D|1Q|E|1R|F|G]]|9|@]|A|$]]|$1|N|3|O|5|6|7|1S|8|@$D|1T|E|1U|F|G]|$D|1V|E|1W|F|G]|$D|1X|E|1Y|F|G]|$D|1Z|E|20|F|G]|$D|21|E|22|F|G]|$D|23|E|24|F|G]]|9|@]|A|$]]|$1|P|3|-4|5|6|7|25|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|26|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|27|8|@]|9|@]|A|$]]]|T|$U|$5|V|W|X|A|$Y|Z]]]]

There is no efficient way - it will still require traversal of the heap, but there is a hacky way: when the heap is divided into smaller pieces (thus no need to scan the entire heap). This is the reason we have generational garbage collectors, so that the scanning takes less time. 

This is relatively "easy" to answer when your entire application is stopped and you can analyze the graph of objects. It all starts from <code>GC roots</code> (I'll let you find the documentation for what these are), but basically these are "roots" that are not collected by the <code>GC</code>. 

From here a certain scan starts that analyzes the "live" objects: objects that have a direct (or transitive) connection to these roots, thus not reclaimable. In graph theory this is know to "color/traverse" your graph by using 3 colors: black, grey and white. <code>White</code> means it is not connected to the roots, <code>grey</code> means it's sub-graph is not yet traversed, <code>black</code> means traversed and connected to the roots. So basically to know what exactly is dead/alive right now - you simply need to take all your heap that is white initially and color it to black. Everything that is <code>white</code> is garbage. It is interesting that "garbage" is really identified by a <code>GC</code> by knowing what is actually alive. There are some drawings to visualize this <a href="https://stackoverflow.com/questions/58924737/could-increase-gc-time-short-lived-object-that-has-references-to-old-lived-objec/58984342#58984342">here</a> for example. 

But this is the simple scenario: when your application is entirely stopped (for seconds at times) and you can scan the heap. This is called a <code>STW</code> - stop the world event and people hate these usually. This is what parallel collectors do: stop everything, do whatever GC has to (including finding garbage), let the application threads start after that. 

What happens when you app is running and you are scanning the heap? <code>Concurrently</code>? <code>G1/CMS</code> do this. Think about it: how can you reason about a leaf from a graph being alive or not when your app can change that leaf via a different thread.

<code>Shenandoah</code> for example, solves this by "intercepting" changes over the graph. While running concurrently with your application, it will catch all the changes and insert these to some thread local special queues, called <code>SATB Queues</code> (snapshot at the begging queues); instead of altering the heap directly. When that is finished, a very short <code>STW</code> event will occur and these queues will be drained. Still under the <code>STW</code> what that drain has "caused" is computed, i.e. : extra coloring of the graph. This is far simplified, just FYI. <code>G1</code> and <code>CMS</code> do it differently AFAIK. 

<hr>

So in theory, the process is not really that complicated, but implementing it concurrently is the most challenging part.

blocks|key|2883754|text|事实是，垃圾收集器通常不会很快知道哪些对象不再有任何传入的引用。事实上，即使有传入的引用，对象也可能是垃圾对象。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2883755|垃圾回收器使用遍历对象图来查找可访问的对象。在此遍历中未到达的对象被视为垃圾，即使它们是引用循环的一部分。对象不可达和垃圾回收器实际收集对象之间的延迟可以是任意长的。|2883756|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The truth is that the garbage collector does not, in general, quickly know which objects no longer have any incoming references. And, in fact, an object can be garbage even when there are incoming references it.
The garbage collector uses a traversal of the object graph to find the objects that are reachable. Objects that are not reached in this traversal are deemed garbage, even if they are part of a cycle of references. The delay between an object being unreachable, and the garbage collector actually collecting the object, could be arbitrarily long.

I understand that in Java, if an object doesn't have any references to it any more, the garbage collector will reclaim it back some time later.

But how does the garbage collector know that an object has or has not references associated to it?

Is garbage collector using some kind of hashmap or table?

<hr>

Edit:

Please note that I am not asking how generally gc works. really, I am not asking that. 

I am asking specifically that How gc knows which objects are live and which are dead, with efficiencies. 

That's why I say in my question that is gc maintain some kind of hashmap or set, and consistently update the number of references an object has?

java - How can Garbage Collector quickly know which objects do not have references to them any more?

虚拟机

Java

我知道在Java中，如果一个对象不再有任何对它的引用，垃圾回收器会在一段时间后回收它。但是垃圾收集器如何知道对象是否有关联的引用呢？垃圾收集器是否使用了某种hashmap或表？编辑：请注意，我并不是问gc一般是如何工作的。真的，我不是在问这个问题。我特别问，gc如何高效地知道哪些对象是活动的，哪些是死亡的。这就是为什么...

问java -垃圾收集器如何快速知道哪些对象不再有对它们的引用？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问java -垃圾收集器如何快速知道哪些对象不再有对它们的引用？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问java -垃圾收集器如何快速知道哪些对象不再有对它们的引用？
EN