garbage-collection - 我怎么知道谁在 spark streaming 程序中调用了 System.gc()？

Question

我的 Spark Streaming 程序中的 GC 时间太长。在GC日志中，我发现有人在程序中调用了System.gc()。我没有在我的代码中调用 System.gc()。所以调用者应该是我用的api。

我将 -XX:-DisableExplicitGC 添加到 JVM 并解决了这个问题。但是，我想知道是谁调用了 System.gc()。

我尝试了一些方法。

1. 使用jstack。但是GC不是那么频繁，很难dump掉调用方法的线程。
2. 我在 JProfiler 中调用方法 java.lang.System.gc() 时添加了添加线程转储的触发器。但它似乎不起作用。

我如何知道谁在 spark 流程序中调用了 System.gc()？

Answer 1

您不会使用 jstack 捕获 System.gc，因为在 stop-the-world 暂停期间 JVM 不接受来自动态附加工具的连接，包括 jstack 、jmap、jcmd 和类似的。

可以使用 async-profiler 跟踪 System.gc 调用者:

1. 预先开始分析:

   $ profiler.sh start -e java.lang.System.gc <pid>
   

2. 发生一个或多个 System.gc 后，停止分析并打印堆栈跟踪:

   $ profiler.sh stop -o traces <pid>
   

   示例输出:

   --- Execution profile ---
   Total samples       : 6
   
   Frame buffer usage  : 0.0007%
   
   --- 4 calls (66.67%), 4 samples
     [ 0] java.lang.System.gc
     [ 1] java.nio.Bits.reserveMemory
     [ 2] java.nio.DirectByteBuffer.<init>
     [ 3] java.nio.ByteBuffer.allocateDirect
     [ 4] Allocate.main
   
   --- 2 calls (33.33%), 2 samples
     [ 0] java.lang.System.gc
     [ 1] sun.misc.GC$Daemon.run
   

   在上面的例子中，System.gc 从两个地方被调用了 6 次。这两种情况都是 JDK 内部强制垃圾回收的典型情况。

   第一个来自java.nio.Bits.reserveMemory。当没有足够的可用内存来分配新的直接 ByteBuffer 时(由于 -XX:MaxDirectMemorySize 限制)，JDK 强制 full GC 回收无法访问的直接 ByteBuffers。

   第二个来自 GC Daemon 线程。这由 Java RMI 运行时定期调用。例如，如果您使用 JMX 远程，则每小时自动启用一次定期 GC。这可以通过 -Dsun.rmi.dgc.client.gcInterval 进行调整系统属性。