以下代码片段执行两个线程，一个是每秒记录一次的简单计时器，第二个是执行余数操作的无限循环：
public class TestBlockingThread {
private static final Logger LOGGER = LoggerFactory.getLogger(TestBlockingThread.class);
public static final void main(String[] args) throws InterruptedException {
Runnable task = () -> {
int i = 0;
while (true) {
i++;
if (i != 0) {
boolean b = 1 % i == 0;
}
}
};
new Thread(new LogTimer()).start();
Thread.sleep(2000);
new Thread(task).start();
}
public static class LogTimer implements Runnable {
@Override
public void run() {
while (true) {
long start = System.currentTimeMillis();
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
// do nothing
}
LOGGER.info("timeElapsed={}", System.currentTimeMillis() - start);
}
}
}
}
这给出了以下结果：
[Thread-0] INFO c.m.c.concurrent.TestBlockingThread - timeElapsed=1004
[Thread-0] INFO c.m.c.concurrent.TestBlockingThread - timeElapsed=1003
[Thread-0] INFO c.m.c.concurrent.TestBlockingThread - timeElapsed=13331
[Thread-0] INFO c.m.c.concurrent.TestBlockingThread - timeElapsed=1006
[Thread-0] INFO c.m.c.concurrent.TestBlockingThread - timeElapsed=1003
[Thread-0] INFO c.m.c.concurrent.TestBlockingThread - timeElapsed=1004
[Thread-0] INFO c.m.c.concurrent.TestBlockingThread - timeElapsed=1004
我不明白为什么无限任务会阻塞所有其他线程13.3秒。我试图改变线程优先级和其他设置，没有任何效果。
如果您有任何解决此问题的建议（包括调整操作系统上下文切换设置），请告诉我们。
答案 0 :(得分：93)
在这里完成所有解释之后（感谢Peter Lawrey）我们发现这个暂停的主要来源是循环内部的安全点很少到达所以需要很长时间来停止JIT编译的所有线程代码替换。
但我决定更深入地找到 为什么 很少达到安全点。我觉得有点混乱为什么在这种情况下while循环的后跳不是“安全”。
所以我召唤-XX:+PrintAssembly一切荣耀来帮助
-XX:+UnlockDiagnosticVMOptions \
-XX:+TraceClassLoading \
-XX:+DebugNonSafepoints \
-XX:+PrintCompilation \
-XX:+PrintGCDetails \
-XX:+PrintStubCode \
-XX:+PrintAssembly \
-XX:PrintAssemblyOptions=-Mintel
经过一番调查后，我发现在第三次重新编译lambda C2后，编译器完全抛弃了内部循环中的安全点轮询。
<强>更新
在分析阶段，变量i从未被视为等于0.这就是为什么C2推测性地优化了这个分支，以便将循环转换为类似
for (int i = OSR_value; i != 0; i++) {
if (1 % i == 0) {
uncommon_trap();
}
}
uncommon_trap();
请注意，最初的无限循环被重新整形为带有计数器的常规有限循环！由于JIT优化消除了有限计数循环中的安全点轮询，因此在此循环中也没有安全点轮询。
一段时间后，i回到0，并且采取了不常见的陷阱。该方法被去优化并在解释器中继续执行。在重新编译期间，使用新知识C2识别出无限循环并放弃编译。该方法的其余部分在解释器中以适当的安全点进行。
"Safepoints: Meaning, Side Effects and Overheads"有一篇关于安全点和此特定问题的必读文章Nitsan Wakart。
已知非常长的计数循环中的安全点消除是一个问题。错误JDK-5014723（感谢Vladimir Ivanov）解决了这个问题。
在最终修复错误之前，可以使用解决方法。
-XX:+UseCountedLoopSafepoints（将导致整体性能下降，可能导致JVM崩溃 JDK-8161147）。使用它之后C2编译器继续保持后跳的安全点，原始暂停完全消失。您可以使用
明确禁用有问题的方法的编译
-XX:CompileCommand='exclude,binary/class/Name,methodName'
或者您可以通过手动添加安全点来重写代码。例如，{@ 1}}在周期结束时调用，甚至将Thread.yield()更改为int i（谢谢，Nitsan Wakart）也会解决暂停问题。
答案 1 :(得分：64)
简而言之，除了达到i == 0之外，你所拥有的循环内部没有安全点。编译此方法并触发要替换的代码时，需要将所有线程都置于安全点，但这需要很长时间，不仅要锁定运行代码的线程，还要锁定JVM中的所有线程。
我添加了以下命令行选项。
-XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime -XX:+PrintCompilation
我还修改了使用浮点的代码，这似乎需要更长的时间。
boolean b = 1.0 / i == 0;
我在输出中看到的是
timeElapsed=100
Application time: 0.9560686 seconds
41423 280 % 4 TestBlockingThread::lambda$main$0 @ -2 (27 bytes) made not entrant
Total time for which application threads were stopped: 40.3971116 seconds, Stopping threads took: 40.3967755 seconds
Application time: 0.0000219 seconds
Total time for which application threads were stopped: 0.0005840 seconds, Stopping threads took: 0.0000383 seconds
41424 281 % 3 TestBlockingThread::lambda$main$0 @ 2 (27 bytes)
timeElapsed=40473
41425 282 % 4 TestBlockingThread::lambda$main$0 @ 2 (27 bytes)
41426 281 % 3 TestBlockingThread::lambda$main$0 @ -2 (27 bytes) made not entrant
timeElapsed=100
注意：对于要替换的代码，必须在安全点停止线程。但是，这里似乎很少达到这样一个安全点（可能仅在i == 0将任务更改为
Runnable task = () -> {
for (int i = 1; i != 0 ; i++) {
boolean b = 1.0 / i == 0;
}
};
我看到了类似的延迟。
timeElapsed=100
Application time: 0.9587419 seconds
39044 280 % 4 TestBlockingThread::lambda$main$0 @ -2 (28 bytes) made not entrant
Total time for which application threads were stopped: 38.0227039 seconds, Stopping threads took: 38.0225761 seconds
Application time: 0.0000087 seconds
Total time for which application threads were stopped: 0.0003102 seconds, Stopping threads took: 0.0000105 seconds
timeElapsed=38100
timeElapsed=100
小心地将代码添加到循环中会导致更长的延迟。
for (int i = 1; i != 0 ; i++) {
boolean b = 1.0 / i / i == 0;
}
得
Total time for which application threads were stopped: 59.6034546 seconds, Stopping threads took: 59.6030773 seconds
但是，更改代码以使用始终具有安全点的本机方法（如果它不是内在的）
for (int i = 1; i != 0 ; i++) {
boolean b = Math.cos(1.0 / i) == 0;
}
打印
Total time for which application threads were stopped: 0.0001444 seconds, Stopping threads took: 0.0000615 seconds
注意：将if (Thread.currentThread().isInterrupted()) { ... }添加到循环中会增加一个安全点。
注意：这发生在16核计算机上，因此不缺CPU资源。
答案 2 :(得分：26)
找到了为什么的答案。它们被称为安全点，最出名的是由于GC而发生的Stop-The-World。
请参阅此文章：Logging stop-the-world pauses in JVM
不同的事件可能导致JVM暂停所有应用程序线程。这种暂停被称为世界各地（STW）暂停。触发STW暂停的最常见原因是垃圾收集（github中的示例），但不同的 JIT操作（示例），偏向锁撤销（示例），某些JVMTI操作等等要求停止申请。
应用程序线程可以安全停止的点称为惊讶，安全点。该术语也常用于指代所有STW暂停。
启用GC日志或多或少是常见的。但是，这不会捕获有关所有安全点的信息。要完成所有操作，请使用以下JVM选项：
-XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime如果您想知道明确引用GC的命名，请不要惊慌 - 打开这些选项会记录所有安全点，而不仅仅是垃圾收集暂停。如果您使用上面指定的标志运行以下示例（github中的源代码）。
阅读HotSpot Glossary of Terms，它定义了这个：
<强>还原点
程序执行期间的所有GC根已知且所有堆对象内容一致的点。从全局的角度来看，所有线程必须在GC运行之前在安全点阻塞。 （作为一种特殊情况，运行JNI代码的线程可以继续运行，因为它们只使用句柄。在安全点期间，它们必须阻塞而不是加载句柄的内容。）从本地的角度来看，安全点是一个区别点在执行线程可能阻止GC的代码块中。 大多数呼叫站点都有资格作为安全点。强大的不变量在每个安全点都适用，在非安全点可能会被忽略。编译的Java代码和C / C ++代码都在安全点之间进行了优化，但在安全点之间却不那么好。 JIT编译器在每个安全点发出GC映射。 VM中的C / C ++代码使用程式化的基于宏的约定（例如，TRAPS）来标记潜在的安全点。
使用上面提到的标志运行，我得到了这个输出：
Application time: 0.9668750 seconds
Total time for which application threads were stopped: 0.0000747 seconds, Stopping threads took: 0.0000291 seconds
timeElapsed=1015
Application time: 1.0148568 seconds
Total time for which application threads were stopped: 0.0000556 seconds, Stopping threads took: 0.0000168 seconds
timeElapsed=1015
timeElapsed=1014
Application time: 2.0453971 seconds
Total time for which application threads were stopped: 10.7951187 seconds, Stopping threads took: 10.7950774 seconds
timeElapsed=11732
Application time: 1.0149263 seconds
Total time for which application threads were stopped: 0.0000644 seconds, Stopping threads took: 0.0000368 seconds
timeElapsed=1015
注意第三次STW事件：
停止的总时间： 10.7951187秒
停止线程： 10.7950774秒
JIT本身几乎没有时间，但是一旦JVM决定执行JIT编译，它就进入了STW模式，但是由于要编译的代码（无限循环）没有调用站点< / em>，没有达到安全点。
当JIT最终放弃等待并结束代码处于无限循环时，STW结束。
答案 3 :(得分：5)
在我自己关注注释线程和一些测试后，我认为暂停是由JIT编译器引起的。为什么JIT编译器花了这么长时间超出了我的调试能力。
但是，由于您只询问如何防止这种情况，我有一个解决方案：
将无限循环拉入可以从JIT编译器中排除的方法
public class TestBlockingThread {
private static final Logger LOGGER = Logger.getLogger(TestBlockingThread.class.getName());
public static final void main(String[] args) throws InterruptedException {
Runnable task = () -> {
infLoop();
};
new Thread(new LogTimer()).start();
Thread.sleep(2000);
new Thread(task).start();
}
private static void infLoop()
{
int i = 0;
while (true) {
i++;
if (i != 0) {
boolean b = 1 % i == 0;
}
}
}
使用此VM参数运行程序：
-XX：CompileCommand = exclude，PACKAGE.TestBlockingThread :: infLoop（用包信息替换PACKAGE）
你应该得到一条这样的消息来表明方法何时被JIT编译：
###排除编译：static blocking.TestBlockingThread :: infLoop
你可能会注意到我把这个类放到一个名为blocking