JVM中对java.lang.ref.Reference$Lock上的数组分配的大量锁定

html5 • • 问答 • 167 阅读

我们使用 Java Flight Recorder 分析了我们的应用程序，并在 java.lang.ref.Reference$Lock 对象上发现了大量锁。

我调查了堆栈跟踪中的一些地方，发现在所有情况下 - 都有数组分配

代码示例（图像上的位置 3）：

    public static char[] copyOfRange(char[] original, int from, int to) {
        int newLength = to - from;
        if (newLength < 0)
            throw new IllegalArgumentException(from + " > " + to);

        // stacktrace points on next line 
        char[] copy = new char[newLength];

        System.arraycopy(original, from, copy, 0,
                         Math.min(original.length - from, newLength));
        return copy;
    }

我怀疑这种锁定与 GC 有关系，但找不到任何相关信息。我在哪里可以阅读有关此主题的更多信息？

活动的最终目标：了解在这种情况下发生了什么，影响这一点的巫术因素以及我们如何减少此类操作的锁定时间。

评论中的一些细节：

  1. 爪哇 8
  2. 堆 512Mb
  3. GC-G1
  4. 通过实验我发现，锁定时间随着堆大小的增加而减少。

回答

Java Flight Recorder 的一大缺点是它只显示 Java 堆栈，完全忽略了 native 和 VM 部分。

在这个意义上，async-profiler更准确。如果在lock分析模式下运行它并打开本机堆栈，它将显示获取这些锁在 JVM 中的确切位置。示例命令：

./profiler.sh -d 60 -e lock --cstack fp -f profile.html -o flamegraph=total PID
  • -d 60 运行分析 60 秒
  • -e lock 配置文件锁争用
  • --cstack fp 记录 C（本机）堆栈
  • -f profile.html 输出文件名（async-profiler 2.0 中的 HTML 格式，或 1.x 中的 SVG）
  • -o flamegraph=total 使用总锁等待时间作为计数器构建火焰图
  • PID Java 进程 ID

在此示例中，火焰图突出显示了Reference$Lock实例上的锁争用。堆栈跟踪的 Java 部分以绿色显示。这与您在 JFR 中看到的堆栈跟踪相匹配。与您的情况一样，顶部 Java 框架是Arrays.copyOfRange（该图还显示了其他堆栈，但让我们关注第一个堆栈）。

黄色部分是原生 C++ 代码。让我解释一下那里发生了什么。

  1. Arrays.copyOfRange调用 VM 运行时函数OptoRuntime::new_array_nozero_C。实际的数组分配发生在 JVM 的 C++ 代码中。

  2. JVM 无法从现有线程本地分配缓冲区 (TLAB) 分配数组，然后回退到新 TLAB 的慢速路径分配。

  3. 慢路径分配也不会成功，因为 Java Heap 中没有足够的空闲内存。因此，JVM 同步调用垃圾收集器。

  4. 在 GC 序言中，JVM 尝试获取保护挂起引用列表的锁。这是为了确保ReferenceHandler线程在 GC 开始之前离开临界区。在持有此锁的同时，JVM 可以安全地将新发现的弱引用附加到挂起列表。

  5. 但是，该锁已被另一个线程获取，该线程同时尝试以相同的方式调用垃圾收集器。当前线程被挂起直到 GC 完成。

综上所述，多个Java线程同时尝试从Heap中分配一个对象，但Heap已满。因此，垃圾收集开始，分配线程被阻塞Reference$Lock- 引用挂起列表锁。

争论Reference$Lock本身不是问题。分配线程无论如何都不能继续，直到 GC 回收足够的内存。实际问题是并发垃圾收集跟不上分配率。

要缓解此问题，请尝试以下一种或多种方法：

  • 增加堆大小；
  • 降低分配率；
  • 增加并发 GC 线程的数量 - ConcGCThreads;
  • 降低InitiatingHeapOccupancyPercent以提前启动并发 GC 周期；

增加堆可能是最有效的。

顺便说一句，async-profiler 还有其他有用的模式来诊断 GC 相关问题：

  • -e cpu显示占用最多 CPU 时间的内容。Java 和 VM 线程一起显示在同一图表上，因此您可以了解与应用程序工作相比，GC 活动是否太高。
  • -e alloc显示分配最多的代码。在研究如何降低分配率时，它特别有用。
以上是JVM中对java.lang.ref.Reference$Lock上的数组分配的大量锁定的全部内容。
THE END
分享
二维码
< <上一篇
下一篇>>