这是我刚刚想到的一个理论问题。
通常在运行 JMeter 负载测试时，我发现默认堆设置就足够了。
有时，当运行密集的 JMeter 负载测试时，JMeter 会抛出 OutOfMemory 异常，表明它需要更多堆(通常情况下)。
我担心这两起案件之间的情况。如果 JMeter 确实没有抛出 OutOfMemory，有什么方法可以让自己确信垃圾收集(在 JMeter 方面)不会对结果产生不利影响？每次运行 JMeter 时都必须监视 gc 日志吗？
我认为更实际的一面是；我可以比较两个单独的 JMeter 测试的输出，其中 Jmeter 使用不同的堆大小吗？
编辑:我注意到的一件事是，Jmeter UI 有一个图标表明 GC 开销限制已被违反。但这来自 JVM，并且在 98% 的 CPU 时间用于执行 GC 时触发，我认为在达到这一点之前我的结果就会出现偏差。
最佳答案
If JMeter does not throw an OutOfMemory, is there any way to reassure myself that garbage-collecting (on JMeter's side) did not adversely affect the results? Do I have to monitor the gc logs everytime I run JMeter?
确定堆大小是否影响结果的简单方法是使用更大的堆大小再次运行测试，看看是否有任何差异。这同样适用于您正在测试的应用程序和 JMeter JVM。
如果您确实有证据表明存在问题，您可以更改 JMeter JVM 设置以使用低暂停收集器。这可能会减少明显的“异常”请求时间的数量……如果它们是由 JMeter 端 GC 暂停引起的。但它(理论上)也会降低 JMeter JVM 的整体吞吐量，从而降低发出请求的平均速率。
如果应用程序和 JMeter 在同一硬件上运行，您可以尝试的另一件事是调整进程优先级，以确保 JMeter 进程不会出现 CPU 不足的情况。
关于java - 如何判断 JMeter 是否需要更多堆才能生成 "Correct"结果？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/16103056/