如果在16gb内存环境中发生完全gc，需要多长时间？
在这样的小堆上，大概是10秒左右。
但这不是你应该考虑的。
在设置系统内存时，应该检查什么级别的完全gc（垃圾收集）时间？
任何时候。无论何时发生完全gc，都应该检查您的应用程序是否延迟严重。这是你应该考虑的。
完全gc失败。多层次的失败。
寻址应用程序可用的内存大小
要解决您使用的gc类型
处理工作负载类型
以解决负载下的优雅退化问题
名单还在继续
并发gc隐式地依赖于一个简单的事实，即它可以比应用程序分配更快地收集数据。当分配压力变得压倒性时，gc有两种选择：减缓分配或完全停止分配。
当它停止的时候，你知道，地狱开始松动，未来超时，集群崩溃，工程师们害怕并厌恶大堆的东西，直到他们的余生。。。
这是一种常见的应用程序场景，这些应用程序经过多年的发展，复杂性和负载不断增加，并且缺乏全面的检查以适应不断变化的世界。
但不一定要这样。
当您从头开始构建新的应用程序时，您可以在设计时考虑性能和延迟，使用可伸缩性和优雅的降级，而不是堆大小和gc时间。
您可以将不是延迟关键但内存很重的工作负载拆分到不同的vm，并在良好的并行gc下运行，它在吞吐量和内存开销方面都将优于任何并发gc。如果不介意30%的内存开销和相当大的cpu开销，您可以在现代最先进的gc（如shenandoah）下运行延迟关键型任务，并在数tb的堆上有次秒级的收集暂停。
让应用程序和需求决定堆的大小，而不是工程师。

您可能会担心（您的“架构师”）一些对您的吞吐量来说可能不是问题的东西。在java-9之前，默认收集器是 ParallelGC 还有几十个应用程序没有改变它，并且对暂停时间很满意（而且收集器每次都暂停世界）。所以唯一真正的答案是：衡量。启用gc日志并查看它。
另一方面，如果选择并发收集器（应该从 G1 )在堆里有足够的呼吸空间是至关重要的。这对我来说更重要 Shenandoan 以及 ZGC ，因为他们同时做每件事。每次gc启动 concurrent 阶段，它通过所谓的“屏障”工作，这些屏障基本上是堆中对象的拦截器。这些屏障使用的这些结构需要储存。如果你要缩小这个存储空间，gc是不会高兴的。
简单地说，堆中的“空闲”空间越多，gc的性能就越好。
在设置系统内存时，应该检查什么级别的完全gc（垃圾收集）时间？
这不是正确的问题。如果您对目标响应时间感到满意，这并不重要。如果你不是-你开始分析gc日志，并了解是什么导致了你的延迟（尽管这不会是微不足道的）。
如果在16gb内存环境中发生完全gc，需要多长时间？
这取决于收集器、java版本以及要收集的对象的类型，没有简单的答案。 Shenandah 以及 ZGC -这是无关紧要的，因为他们不关心要扫描的堆的大小。为了 G1 它很可能在“几秒钟”的范围内。但是，如果您有弱引用和终结器，并且已知的java版本处理得不太好，那么收集的时间将会非常长。