0

我在 OSB 中实现的服务中遇到了一些与性能相关的问题（大部分时间都可以正常工作，并且不时会出现从 100 毫秒到 4/5 秒的响应时间峰值，没有明显的原因）。解释这种情况的假设之一是 JVM 可能在这些峰值期间执行 Full GC，我们正在使用任务控制监视 JVM。

管理员告诉我，jvm 正在使用 G1GC 禁用完整 gc 运行，我可以在启动命令中看到：

-XX:+DisableExplicitGC  
-XX:+UseG1GC 
-XX:MaxGCPauseMillis=500 -verbosegc 
-XX:+PrintGCDetails 
-XX:+PrintGCDateStamps

此外，当我分析 gc 日志时，没有执行 Full GC 的日志记录，我只能找到（根据这些配置，这很有意义）：

2017-05-02T04:46:10.916-0700: 39228.353: [GC pause (G1 Evacuation Pause) (young), 0.0173177 secs]

但是，当我在 jmc 中打开飞行记录器并开始一些负载测试时，我立即注意到正在执行 Full GC

完整的 GC 示例

我可以在日志中看到它：

2017-05-02T05:41:31.297: 548.719: [Full GC (Heap Inspection Initiated GC) 1780->705M(2048M), 3.040 secs]

一旦我禁用飞行记录器，我就可以一遍又一遍地运行完全相同的负载测试，并且日志中不会记录 Full GC。

我在这里遗漏了什么，还是 Flight Recorder 真的强迫 JVM 执行 Full GC？

问候

4

3 回答 3

2

文档说了这么多：

启用堆统计生成的飞行记录将以旧 GC 开始和结束。在 GC 列表中选择旧 GC，然后选择 General 选项卡以查看 GC Reason 为 - Heap Inspection Initiated GC。这些 GC 通常需要比其他 GC 稍长的时间。

于 2017-05-03T17:23:27.613 回答
0

如果您在记录向导中启用堆统计，JVM 将停止应用程序并扫描堆以收集有关它的信息。如果您想确保低开销 (1%)，请使用默认录制模板（无需修改）。

于 2017-05-03T22:43:13.533 回答
-1

是的，JFR 记录确实会定期运行 Full GC。最初我们也想知道同样的问题，但下面的文档给出了正确的细节。

https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr005.html

The flight recording generated with Heap Statistics enabled will start and end with an old GC. Select that old GC in the list of GCs, and then choose the General tab to see the GC Reason as - Heap Inspection Initiated GC. These GCs usually take slightly longer than other GCs.

基本上，这个想法是查看即使在指向内存泄漏的 GC 之后也没有被收集的对象。

如果您只想查看整个堆以了解堆中的所有对象，那么 JFR 不是正确的方法。只需使用 java 的可视化 vm 或任何其他免费提供的工具进行堆转储并查看它。在进行堆转储的同时还要验证命令的文档以确保堆转储命令不会运行 GC。有可用的选项，需要搜索。

更新：另外关于您问题中的 GC 假设，最好的方法是通过 JVM args 打印 GC 日志。有一些可用的工具将 GC 日志作为输入并显示带有可读统计数据的漂亮图表。因此，只需启用 GC 日志并进行测试。然后，当您看到问题/缓慢等时，请使用工具查看 GC 日志并查看 GC 发生了多长时间以及清除了多少内存等。

于 2017-07-21T04:50:14.480 回答