在不可访问的线程中放置断点会强制它运行

Question

我对这段代码有一个奇怪的问题：

class Test {
    private static boolean test = false;

    public static void main(String[] args) {
        new Thread(() -> {
            while (true) {
                if (test) {
                    System.out.println("Print when breakpoint here!");
                    test = false;
                }
            }
        }, "Thread1").start();

        new Thread(() -> {
            while (true) {
                System.out.println("Print always");
                try {
                    Thread.sleep(2000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                test = true;
            }
        }, " Thread2").start();
    }
}

正如我所料，由于boolean test 不是volatile，线程1 使用test 的本地缓存值，当线程2 将其更改为true 时，线程1 不会做任何事情。但是当我在System.out.println("Prints when put a breakpoint here!"); 行设置断点时，它会到达那里并打印该行！设置断点到底发生了什么？它是否强制程序直接从内存中读取变量的值？还是发生了其他事情？

Answer 1

正如我所料，由于布尔测试不是易失性的，Thread1 使用本地缓存值 test，当 Thread2 将其更改为 true 时，Thread1 不会做任何事情。

你的预期不正确。

根据 Java 语言规范，如果一个线程更新了一个非易失性共享变量，而另一个线程随后在没有适当同步的情况下读取它，那么第二个线程可能看到新值，或者它可能看到较早的值。

所以你看到的都是 JLS 允许的。

---

在实践中，当调试代理附加到 JVM 时，它通常会导致 JIT 编译器在较低的优化级别重新编译部分或所有方法......甚至可能使用字节码解释器执行它们。对于设置了断点的方法以及单步执行¹ 时，可能会发生这种情况。这可能会导致在调试时使用共享变量而没有正确同步的代码出现不同的行为。

这也是同步不充分导致调试问题困难的原因之一。

---

据我所知，断点通过添加一个名为 INT 3 的特殊陷阱来更改代码指令。那么到底发生了什么？

这就是调试 C/C++ 时发生的情况。没有具体说明 JVM 如何处理这个问题，但是典型的 JVM 有其他实现断点的选项……因为字节码和 JIT 编译。

---

当我在 if 语句之前的 Thread1 中添加 sleep(1) 时，它也会打印该行。添加睡眠是否会发生同样的事情？

sleep 将导致当前线程被挂起。 未指定实现级别发生的情况。但是，很可能本机线程机制会将挂起线程的任何未完成的写入（即脏缓存条目）刷新到内存......作为执行线程上下文切换过程的一部分。

同样，如果您使用打印语句，典型的 I/O 堆栈具有内部同步，可以触发缓存刷新等。这也可以改变您尝试调试的代码的行为。

但是，我要强调的是，这些行为并未具体说明。

---

^{1 - 允许 JIT 优化器重新排序分配，前提是这不会改变单线程行为。但是，如果您正在调试一个方法并观察变量的值，则重新排序的效果是可见的（对程序员而言）。去优化/解释避免了这种情况。幸运的是，现代 JVM / 调试代理可以根据需要“即时”执行此操作。}

Answer 2

警告：此答案主要基于 .Net 调试器的工作方式，但我预计两个运行时之间的行为相似。我希望 JVM 允许在运行时按方法重新 JIT，因为它已经可以用 HotSpot JIT 替换方法。

有一些现有的文章和帖子关于关闭了哪些优化以进行调试，例如 AMD: perf when debugging enabled、Side Effects of running the JVM in debug mode、Will Java app slow down by presence of -Xdebug or only when stepping through code?。他们暗示至少在出现异常时代码在调试器下采用明显不同的代码路径，这可能断点是如何实现的。

---

当您调试代码时，许多调试器会关闭优化（如果您允许重新编译代码则为编译时间，如果您调试现有代码则为 JIT 时间）。在 .Net 世界中，影响是全球性的——当附加了调试器时，它可以将所有未来的 JIT 编译切换到非优化路径，我希望 Java/JVM 支持更精细的控制，以允许仅对可能需要在调试器中停止的方法进行反优化。这样做是为了让您清楚地看到所有变量的所有值。否则，有时包括方法调用和局部/成员变量在内的一半信息不可用。

“使用测试的本地缓存值”是优化（可能在 JIT 时间） - 因此当您开始调试代码（或启用某种带断点的单步执行）时，它将关闭优化并每次从内存中读取因此基本上使变量接近volatile（仍然没有必要一直以这种方式表现，但接近）。

根据您使用的调试器，您可以禁用此类行为（但调试会更加困难）。

Answer 3

当您运行代码时，它会经历几个优化阶段。最初它被解释并且您的布尔变量可能始终可见，但是在最高级别的优化中，该值可以被内联（不仅仅是缓存）并且您永远不会看到更改。发生这种情况的时间点取决于代码循环了多少次，以及代码何时在后台编译和替换。

当您添加日志记录或断点或睡眠 (1) 时，您会减慢应用程序的速度，并且需要更长的时间才能达到优化代码的阈值。这意味着您可以避免看到问题，尤其是在竞争条件下。