手动GC调用的用例？

Question

我已经读过为什么调用System.gc（）以及许多其他方法是一种不好的做法，例如，这描述了确实造成了灾难性的滥用System.gc()。但是，在某些情况下，GC花费的时间太长，避免了长时间的停顿，例如，避免垃圾并不是一件容易的事，并且使代码难以维护。

在以下常见情况下，恕我直言，手动调用GC很好：

• 有多个可互换的Webserve，它们前面都有一个故障转移。
• 每个服务器使用几GB的堆，STW暂停花费的时间比平均请求长得多。
• 故障转移不知道何时发生GC。
• 根据提示，故障转移可以免除服务器。

该算法似乎很简单：定期选择服务器，不要再向它发送任何请求，让它完成其正在运行的请求，让它执行其GC，然后重新激活服务器。

我想知道我是否想念什么？1,2

有哪些选择？

1. 长时间运行的请求可能是一个问题，但让我们假设没有请求。或者只是将等待时间限制在与GC相当的时间。发出缓慢的请求甚至变得更慢听起来并不坏。

2. 诸如此类的选项-XX:+DisableExplicitGC可能会使算法无用，但不要使用它（我的用例包括我负责的专用服务器）。

Answer 1

对于低延迟交易系统，我以非典型方式使用GC。

您要避免在交易日收集任何款项，即使是次要款项也是如此。一种方法是每秒创建少于300 KB的垃圾。每小时大约1 GB，或者每天最多24 GB。当您使用24
GB
Eden空间时，这意味着没有次要/主要GC。但是，为确保GC在计划的可接受时间内发生，System.gc()每天早上5点叫a，第二天您将有一个干净的伊甸园空间。

有时，您创建的垃圾多于预期，例如无法重新连接到数据源，并且可能会获得少量的次要收集。但是，只有在出现问题时才会发生这种情况。

有关更多详细信息，请访问http://vanillajava.blogspot.co.uk/2011/06/how-to-avoid-garbage-
collection.html

通过避免垃圾并不完全是琐碎的事情，并使代码难以维护。

完全避免垃圾几乎是不可能的。但是，对于JVM而言，300 KB / s并不难。（如今，在一台具有24 GB Eden空间的计算机上，您可以拥有多个JVM）

请注意，如果您可以将垃圾保持在50 KB / s以下，则可以在没有GC的情况下运行整周。

定期选择服务器，不让其他请求发送给它，让它完成正在运行的请求，让它执行其GC，然后重新激活该服务器。

您可以将GC视为无法满足SLA条件。在这种情况下，您可以在确定将要从群集中删除服务器时将其删除，并对其进行Full GC并将其返回到群集中。