我之前也碰到过这种复杂遗留代码里的诡异问题，分享两个实用的方案，帮你精准定位到目标实例的setValue()调用：

方案一：利用实例的唯一标识（Identity Hash Code） #

这是最快捷的方式，不需要改动太多代码：

1. 先在你拿到目标实例i的代码位置，临时加一行打印，获取它的唯一标识：

   // 拿到i之后立刻执行这行
   System.out.println("目标实例的唯一标识：" + System.identityHashCode(i));
   

   运行代码后，控制台会输出一串数字，比如123456789。
2. 找到父类的setValue()方法，在方法内部打一个断点。右键点击断点图标，选择Breakpoint Properties。
3. 在弹出的窗口里勾选Conditional，然后在条件输入框中填写：

   System.identityHashCode(this) == 123456789
   

   这里的this就是当前调用setValue()的实例，只有当它的标识和你之前打印的目标实例标识完全一致时，断点才会触发。

方案二：通过静态变量绑定目标实例（更可靠） #

如果担心Identity Hash Code出现极低概率的碰撞，或者想要更直观地关联实例，可以用这个方法：

1. 新建一个临时的工具类（或者复用现有类也可以），添加一个静态变量来保存目标实例：

   public class DebugHelper {
       // 排查完成后一定要删掉这个变量，避免内存泄漏
       public static Object TARGET_INSTANCE;
   }
   

2. 在你拿到目标实例i的代码位置，把它赋值给这个静态变量：

   DebugHelper.TARGET_INSTANCE = i;
   

3. 同样在父类setValue()方法里打条件断点，条件填写：

   this == DebugHelper.TARGET_INSTANCE
   

   这种方式直接通过对象引用做比较，完全不会有标识碰撞的问题，精准度拉满。

小提醒 #

• 排查结束后，记得删掉临时添加的打印代码和静态变量，别给代码库留“尾巴”。
• 如果是多线程环境，用静态变量时要注意线程安全，但一般调试阶段单线程排查足够用。
• Eclipse的条件断点会在每次方法调用时判断条件，对于调用特别频繁的方法可能会稍微影响性能，但调试阶段完全可以接受。

备注：内容来源于stack exchange，提问作者TobiasGriese