什么原因导致Java中的长旋转和同步时间？

Question

在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),我们不知道代码中有任何过多的同步.

Answer 1

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

该sync值显示了同样的事情 - 它是所有线程到达安全点所需的时间。

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

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

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

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