是什么导致 Java 中的自旋和同步时间过长？答案

【问题标题】：What causes long spin and sync times in Java?是什么导致 Java 中的自旋和同步时间过长？
【发布时间】：2015-05-22 09:45:48
【问题描述】：

在 Java 8 Update 45 中，将这些选项添加到 java 调用中：

-XX:+PrintGCApplicationStoppedTime
-XX:+PrintSafepointStatistics
-XX:PrintSafepointStatisticsCount=1

显示如下统计数据：

vmop [threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count
3679.229: no vm operation [ 72 1 2 ] [ 6016 0 6016 0 0 ]  1
2015-05-22T11:25:27.519+0200: Total time for which application threads were stopped: 6.0168551 seconds, Stopping threads took: 6.0164099 seconds

这里的问题是Stopping threads 的时间很长。在这个例子中，6 秒对我们的应用程序来说已经是个问题了，但我看到的时间甚至更长，在一个实例中（虽然没有完整的日志记录）将近一分钟。

VM 操作（此处为：no vm operation）是变化的。我也见过，例如RevokeBias、G1IncCollectionPause 或 GCG_Operation。此外，page_trap_count 似乎无关紧要。我已经看到它为 0 的示例，以及其他为 2 的示例。但一致的是，时间始终反映在 spin 和 sync 的值中。

我正在寻找对这些计时值 spin 和 sync 的深入解释，但我最感兴趣的是为什么会发生这种情况以及我可以做些什么来解决它。我不知道我们的配置中有任何“邪恶”。机器上有很多无聊的内核和未使用的内存，我们运行的是纯 Java（没有 JNI），我们不知道代码中有任何过度同步。

【问题讨论】：

您可以提供更多具体用例的详细信息，以便人们知道如何提供帮助。
实际上，我不仅在我们的一个应用程序中看到了这一点，而且我也全面看到了这一点。所以实际上并没有一个特定的用例。如果我知道要寻找什么，我可以去寻找相似之处。然而，我有点怀疑，很多人有同样的问题，但还没有注意到。指向我的日志记录“停止线程占用：”是相当新的。

标签： java garbage-collection g1gc

【解决方案1】：

这里的问题是您的应用程序需要很长时间才能到达安全点。 Stopping threads 输出表示从 JVM 发出安全点请求到所有线程都到达安全点之间的时间。

sync 值显示相同的内容 - 它是所有线程到达安全点所需的时间。

spin 和 block 值表示 blocked 和 spinning（执行代码）线程到达安全点所需的时间。

知道了这一点，我们可以得出结论，您的问题是一个线程忙于旋转，并且无法在几秒钟内到达其安全点。

究竟为什么会发生这种情况很难说。一个示例，如this 问题所示，其答案是 JIT 编译器可以在没有安全点检查的情况下编译繁重的循环。

您可以尝试使用选项-XX:+SafepointTimeout -XX:SafepointTimeoutDelay=500 运行您的JVM。这将使安全点同步在 500 毫秒后超时，并打印有关未能到达安全点的线程的信息。

【讨论】：

谢谢！我会试试这个并报告。
附加选项确实会给我线程名称（没有堆栈，但目前似乎没有办法得到它）。查看显示问题的应用程序之一，线程大部分时间都是相同的。看起来需要努力才能找到实际问题，但我现在知道从哪里开始，而且问题肯定得到了回答！
@malamut 既然您知道线程，也许常规线程转储 (jstack <pid>) 会有所帮助。他们也在等待安全点，因此即使有这种帮助也可能很难说出问题所在。一旦你发现问题，我很想听听问题所在。这是一个有趣的问题。
我会报告有趣的发现。可悲的是，这并不容易，因为它可能不止一个原因。我目前正在寻找的一个特定于单个应用程序。禁用 JIT 时它会消失，所以我会先按照您链接问题中的轨迹进行操作。
我确定了我们自己的一种方法，当从编译中排除时，它可以解决问题。我不太相信方法本身就是问题所在。排除它可能会隐藏实际问题。无论如何，我有能力排除它，所以现在我只是这样做，不再问任何问题。 :) 列表中的下一个是消除 G1 暂停时异常长的复制时间。不过，这个还没有准备好在这里提出问题。需要先在那里进行一些额外的研究。 :)