手动GC调用的用例？ [英] A use case for a manual GC invocation?
问题描述
我读过为什么不好的做法是调用System.gc（）以及其他许多方法，例如这一描述了真正灾难性滥用 恕我直言，手动调用气相色谱仪（GC）手动调整气相色谱仪在以下常见场景中可以使用： 该算法似乎很简单：定期选择一个服务器，不要让更多的请求发送给它，让它完成它的运行请求，让它完成GC，然后重新激活服务器。 我想知道是否我错过了什么？ 1,2 有哪些选择？ 长时间运行的请求可能是一个问题，但让我们假设没有。或者只是将等待时间限制在与GC所需时间相当的一段时间。 对于低延迟交易系统，我以非典型的方式使用GC。 您想要避免任何收藏品，甚至在交易日的小买卖。一种方法是每秒创建少于300 KB的垃圾。这大约是每小时1 GB，或者每天高达24 GB。当您使用24 GB Eden空间时，这意味着没有小型/主要GC。但为了确保GC在计划和可接受的时间发生，每天早晨在凌晨5点调用 有时候，当您创建比预期更多的垃圾时，例如无法重新连接到数据源，并且您可能会收到少量次要集合。但是，只有在出现问题时才会发生这种情况。 更多详情 http://vanillajava.blogspot.co.uk/2011/06/how-to-avoid-garbage-collection.html p> 通过避免垃圾并不是微不足道，并且使代码难以维护。 完全避免垃圾几乎是不可能的。然而，对于JVM而言，300 KB / s并不那么困难。 （你现在可以在一台机器上有24个以上的Eden空间使用多个JVM） 注意，如果你能保持低于50 KB / s的垃圾，你可以运行所有的每周使用一次GC。 定期选择一台服务器，不要再发送任何请求，让它完成其运行请求，让它执行GC并重新激活服务器。 您可以将GC视为无法满足SLA条件。在这种情况下，您可以在确定即将从您的群集发生这种情况时移除服务器，完全GC并将其返回给群集。 I've read why is it bad practice to call System.gc(), and many others, e.g. this one describing a really disastrous misuse of IMHO calling GC manually is fine in the following common scenario: The algorithm seems to be trivial: Periodically select a server, let no more requests be send to it, let it finished its running requests, let it do its GC, and re-activate the server. I wonder if I am missing something?1,2 What are the alternatives? Long running requests could be a problem, but let's assume there are none. Or simply limit waiting to some period comparable with what GC takes. Making a slow request even slower doesn't sound too bad. An option like
For low latency trading systems I use the GC in an atypical manner. You want to avoid any collection, even minor ones during the trading day. A way to do this is to create less than 300 KB of garbage a second. This is around 1 GB per hour, or up to 24 GB per day. When you use a 24 GB Eden space it means there is no minor/major GCs. However to ensure a GC occurs at a time which is planned and acceptable, a There are times, when you create more garbage than expected e.g. failing to reconnect to a data source, and you might get a small number of minor collections. However this only happens when something is going wrong. For more details http://vanillajava.blogspot.co.uk/2011/06/how-to-avoid-garbage-collection.html by avoiding garbage is not exactly trivial and makes the code harder to maintain. Avoiding garbage entirely is near impossible. However 300 KB/s is not so hard for a JVM. (You can have more than one JVM these days on one machine with 24 GB Eden spaces) Note if you can keep below 50 KB/s of garbage you can run all week with out a GC. Periodically select a server, let no more requests be send to it, let it finished its running requests, let it do its GC, and re-activate the server. You can treat a GC as a failure to meet your SLA condition. In this case you can remove a server when you determine this is about to happen from your cluster, Full GC it and return it to the cluster. 这篇关于手动GC调用的用例？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！ System.gc（）的。但是，有时会出现 GC耗时过长并避免长时间停顿的情况，例如
System.gc（），并且您有一个干净的Eden空间供第二天。
System.gc(). However, there are cases when the GC takes too long and avoiding long pauses, e.g., by avoiding garbage is not exactly trivial and makes the code harder to maintain.
-XX:+DisableExplicitGC could make the algorithm useless, but just don't use it (my use case includes dedicated servers I'm in charge of).System.gc() is called at say 5 AM each morning and you have a clean Eden space for the next day.
