为什么我的对象被 IntelliJ IDEA 悄悄修改了？

背景

最近，在复习JUC的时候调试了一把ConcurrentLinkedQueue的offer方法，意外的发现Idea在debug模式下竟然会 “自动修改” 已经创建的Java对象，当时觉得这个现象很是奇怪，现在把问题的原因以及解决过程记录下来，希望你在调试的时候不要踩坑。

调试代码

调试的代码很简单，就是多次调用offer方法，然后观察ConcurrentLinkedQueue的head和tail属性。

import java.lang.reflect.Field;
import java.util.concurrent.ConcurrentLinkedQueue;public class ConcurrentLinkedQueueTest {public static void main(String[] args) {ConcurrentLinkedQueue<String> queue = new ConcurrentLinkedQueue<>();print(queue);queue.offer("aaa");print(queue);queue.offer("bbb");print(queue);queue.offer("ccc");print(queue);}/*** 打印并发队列head属性的identityHashCode* @param queue*/private static void print(ConcurrentLinkedQueue queue) {Field field = null;boolean isAccessible = false;try {field = ConcurrentLinkedQueue.class.getDeclaredField("head");isAccessible = field.isAccessible();if (!isAccessible) {field.setAccessible(true);}System.out.println("head: " + System.identityHashCode(field.get(queue)));} catch (Exception e) {e.printStackTrace();} finally {field.setAccessible(isAccessible);}}
}

调试过程

上述代码在Idea中debug模式下head属性会无缘无故的被修改（run模式下正常，debug模式下关闭所有断点也正常），检查ConcurrentLinkedQueue的源码发现，head属性只有在构造器和反序列化的readObject共3处地方才会被直接赋值（不是cas修改），我也仔细检查了offer方法，确实没有修改head的地方。而Idea在debug时，把head属性修改为第一次offer的Node节点，这个现象就很奇怪了。

在run模式下的输出结果，多次调用offer方法，head属性都是同一个对象（debug模式下关闭所有断点也是同样的效果）
在offer方法中断点，然后debug并单步调试（Step over）
在offer方法中断点，然后debug并直接运行到下一个断点（Resume program）

由上可见，在debug进入offer方法之后head属性确实被修改了（对象已经不是同一个），而且这不是偶尔出现，而是一直可以复现的，Step over和Resume program也表现出了修改head属性不同的时机，这让人很费解。更费解的是就算不在offer方法体里断点，在main方法中断点也会出现head被修改的现象。

转战到Eclipse，同样的环境，同样的操作，在run和debug模式下都不会出现head被修改的情况

分析

了解到Idea在debug模式下默认开启了toString预览特性（Settings>>Build,Execution,Deployment>>Debugger>>Data Views>>Java>>Enable 'toString()' object view），可是调用toString方法也不至于把对象本身都修改了啊，也专门看了下ConcurrentLinkedQueue的内部类Node，并没有复写toString方法（事后回顾，当时在这里疏忽了，下文会再介绍），但还是关掉特性再测试一遍，然而还是同样的结果，head属性任然被悄悄的修改了。第二天来到公司在同事的环境（IntelliJ IDEA 2019.1）上验证了下，还是同样的问题，排除Idea版本的因素。

郁闷了一会儿，就向"网友"提问了链接，不久就得到了IntelliJ IDEA的产品经理yole的回复，他的意思还是Idea 的 Data Views 的 toString 在作怪，上文已经说过关掉toString特性还是有这个问题，但是他给了我一个重要的思路就是：在debug模式下，ConcurrentLinkedQueue的对象也会被调用toString方法的，在队列的toString方法中会获取队列的迭代器，而创建迭代器时会调用first方法，first方法里就会cas修改head属性。（之前确实没考虑到队列本身的toString方法，而是去看Node是否重写了toString，手动哭脸?）
这里需要注意的是，尽管关掉toString特性上面问题还是存在，原因就在于ConcurrentLinkedQueue是一个Collection，Data Views 还有一个选项“Enable alternative view for Collections classes” （平时没注意...）所以也会在debug时造成队列迭代器的遍历。把这个特性也一并关掉，则上面的问题就不会再出现了。