我需要一个关于完整垃圾收集的最长时间的经验法则。其动机是能够区分错误的JVM进程和GC之下的进程。什么是大堆近似最糟糕的垃圾收集时间
假设我有一个常规的通用服务器硬件HotSpot JVM 8，堆大小为20G-40G，没有设置特定的GC和内存选项。什么是GC完成的合理时限？是5分钟，20分钟还是几小时？
更新： 我的应用程序是一个处理大数据结构的内存密集型脱机作业。我根本不需要调整GC。如果知道这个限制，10秒和10分钟的停顿是很好的。
这是很难量化GC多久“应该”接受，因为这取决于很多因素：
有一对夫妇的病理情况，可能会导致过多的GC时间：
如果堆快满时，GC使用的时间比例增加试图夺回自由的最后一位空间。
如果您有一个大于可用物理内存的堆，您可以进入虚拟内存“抖动”行为。这在主要或全面的GC期间最为明显。
如果你需要选择一个号码，我建议你使用一个“感觉”给你的权利，并使其配置参数，这样很容易调整。另外，打开GC日志记录并查看在那里报告的典型 GC时间的。 （特别是当服务器负载很高。）
首先，gc暂停时间在大部分时间为毫秒。如果一个gc需要多个秒，我认为您的应用必须无论如何调整。
然后就像评论说的那样，gc暂停时间取决于您的应用程序的特征。所以，如果你想要一个关于你的应用程序的完整垃圾收集的最大时间的经验法则，我建议你收集gc.log和对它做统计，那么你会知道多久停顿时间一个糟糕的gc。
对于那些等待时间没多大关系有比暂停时间更好的措施，批作业：
一）垃圾收集/时间/ CPU核心的MB
低收集率通常表明某些病理性病例，如交换，透明的巨大页面合并或GC中的某些边缘病例，例如正在扫描的大型参考阵列。 b）应用程序吞吐量 - 应用程序代码花费的壁挂时间与花费在GC上的壁挂时间的比率。
如果它们不经常发生，则长GC不是一个大问题。
两者都可以通过运行GC日志通过GCViewer
我的建议获得的是： 1.configure在JVM参数，打开GC日志，检查GC日志，你会看到GC需要多长时间 2 GC不会是几分钟，我看到了大约13秒的暂停时间，哪个客户受到了非常严重的影响。
5或20分钟？这对你来说听起来合理吗，你的程序会停留很长时间？ – alfasin
如果你真的需要在这里考虑“分钟”，我会非常惊讶。我希望*在最多几秒钟内*。除此之外：这仍然取决于您的应用程序的特征。 – GhostCat
我记得遇到了一个18秒GC的例子，它被认为是*真的很差* ... – alfasin