在Java中导致长旋转和同步时间的原因是什么？ [英] What causes long spin and sync times in Java?

问题描述

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

In Java 8 Update 45, adding these options to the java call:

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

显示了我这样的统计数据：

shows me statistics like these:

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

这里的问题是停止线程。在这个例子中，这是6秒，这对我们的应用程序来说已经是个问题了，但是在一个实例中（虽然没有完整的日志记录），我看到了更大的时间，差不多有一分钟的时间。

The problem here is the long time for Stopping threads. In this example, it is 6 seconds which is already a problem for our application, but I have seen even larger times, in one instance (without full logging, though) amounting to almost a minute.

VM操作（这里： no vm operation ）是变化的。我也见过，例如 RevokeBias ， G1IncCollectionPause 或 GCG_Operation 。此外， page_trap_count 似乎无关紧要。我已经看到它是0的例子，以及其他地方的例子。然而，一致的是，时间总是反映在 spin 和<$ c $的值中c> sync 。

The VM operation (here: no vm operation) is varying. I have also seen, e.g. RevokeBias, G1IncCollectionPause, or GCG_Operation. Also, the page_trap_count seems to be irrelevant. I have seen examples where it was 0, and others where it was 2. Consistent, though, is that the time always is reflected in the values of spin and sync.

我正在寻找对这些时间值 spin 和 sync ，但主要是我感兴趣的是为什么会发生这种情况，以及我可以对付它。我不知道我们的配置中有什么邪恶。在机器上有很多无聊的内核和未使用的内存，我们正在运行纯Java（没有JNI），我们也没有意识到代码中有任何过度的同步。

I am looking for an in-depth explanation of those timing values spin and sync, but mostly I am interested in why this is happening and what I can do against it. I am not aware of anything 'evil' in our configuration. There are plenty of bored cores and unused memory on the machine, we are running pure Java (no JNI), and we are not aware of any excessive synchronization in our code.

推荐答案

这里的问题是它需要很长时间才能达到安全点。 停止线程输出表示在JVM发出安全点请求直到所有线程达到安全点之间花费的时间。

The problem here is that it takes your application a long time to reach a safepoint. The Stopping threads output denotes the time it takes between the JVM issues a safepoint request until all threads have reached a safepoint.

同步值显示了同样的事情 - 这是所有线程到达safeponit所需的时间。

The sync value shows same thing - it is the time it takes for all threads to reach the safeponit.

旋转和块值表示被阻止的时间和旋转（执行代码）线程以达到安全点。

The spin and block values denote the times it takes for blocked and spinning (executing code) threads to reach the safepoint.

知道这一点，我们可以得出结论：因为你是一个线程正在忙着转动，并在几秒钟内无法达到其安全点。

Knowing this we can conclude that the problem for you is that one thread is busy spinning and not able to reach its safepoint in several seconds.

确切的原因很难说。一个例子，如这个问题，答案是JIT编译器可以在没有安全检查的情况下编译重循环。

Exactly why this occurs is hard to say. An example, as illustrated in this question and it's answer is that the JIT compiler can compile heavy loops without safepoint checks.

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

You could try running your JVM with the options -XX:+SafepointTimeout -XX:SafepointTimeoutDelay=500. That will timeout the safepoint syncs after 500 ms and print information about the thread(s) that failed to reach the safepoint.

这篇关于在Java中导致长旋转和同步时间的原因是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！