Eclipse调试模式引发非预期同步问题：如何查看线程缓存变量以诊断Java多线程问题？

你的分析完全正确——这是典型的线程本地缓存与主内存不一致导致的可见性问题：由于demo.t没有被volatile修饰，JIT编译器会对t2的循环做优化，把demo.t的值缓存到线程本地寄存器中，即使主内存里t已经被t1更新到100，t2仍然读取本地缓存的旧值，陷入死循环。而调试器的Variables视图默认读取的是主内存中的变量值，所以会出现"视图显示t=100但线程仍卡在循环"的矛盾现象；单步调试时，调试操作会触发内存屏障，强制线程从主内存刷新变量值，因此线程能跳出循环。

针对这类线程缓存相关的调试需求，以下是几个更合适的工具和技巧：

1. IDE高级调试配置（禁用JIT优化） #

主流IDE（IntelliJ IDEA、Eclipse）都支持在调试时禁用JIT编译优化，避免线程缓存变量的情况：

• IntelliJ IDEA：打开Run/Debug Configurations，在VM options中添加-Xint（强制JVM以解释模式运行，不做JIT优化），或者更精准地禁用目标类的优化：-XX:CompileCommand=exclude,fr/fgoux/debugbugdemo/DebugDemoMain.*。这样调试时，线程会每次直接读取主内存的变量值，Variables视图显示的内容和线程感知的状态完全一致。
• Eclipse：在Debug Configuration的VM arguments中添加同样的参数，或者通过Preferences -> Java -> Debug -> Debugger -> JDI Options中配置相关优化禁用选项。

2. 专业性能分析工具（JProfiler/YourKit） #

这类商业工具专门针对Java并发和性能问题，能直接展示线程本地缓存的变量状态：

• JProfiler：在Thread视图中选择目标线程，查看其Local Variables面板，这里会显示线程当前感知到的变量值（包括本地缓存的堆变量副本）。同时，它的Memory Access探针可以跟踪变量的读写操作，清晰展示每个线程对变量的访问情况，以及变量在不同线程中的可见性状态。
• YourKit：类似地，它的Thread Profiler可以查看线程的上下文变量，包括线程本地缓存的内容，还能通过"Force GC"或"Refresh Memory"操作，对比主内存和线程缓存的变量值差异。

3. JDK自带命令行调试器（jdb） #

如果你习惯命令行工具，jdb配合特定参数也能辅助诊断：

• 用jdb -classpath <your-classpath> -Xint fr.fgoux.debugbugdemo.DebugDemoMain启动调试，禁用JIT优化后，使用print demo.t命令可以读取线程当前感知的变量值（而非主内存值）。
• 用info threads查看所有线程状态，dump thread <thread-id>可以导出线程的完整栈帧和本地变量信息，帮助你确认线程是否真的在使用缓存的旧值。

4. 代码层面的临时验证技巧 #

虽然不是工具，但可以快速验证问题根源：

• 在t2的循环中添加System.out.println(demo.t)，因为System.out.println()方法内部是同步的，会触发内存屏障，强制线程刷新主内存的变量值，此时线程会很快退出循环。
• 临时给t字段加上volatile修饰符，运行后如果t2能正常退出，就可以确认是可见性问题导致的循环阻塞。

内容的提问来源于stack exchange，提问作者Fogux