断点调试技巧：IDE断点类型与多线程调试

调试这事儿，说白了就是跟代码「捉迷藏」。你写了个bug，它藏起来了，你得用工具把它揪出来。断点就是你的「探照灯」。我做了这么多年测试，见过太多人只会用最基础的行断点，然后一行一行地F8按到手指酸。其实，用好断点类型和调试面板，效率能翻好几倍。

1. 行断点：最基础，也最常用

行断点，就是你在某一行代码左边点一下，出现一个红点。程序跑到这一行就会停下来。这没什么好说的，大家都会。但我有个习惯：不要在一行代码上打多个断点。你想想看，同一个位置停两次，除了浪费时间，没任何意义。

我在项目中遇到过一个小伙子，他在一个for循环里打了行断点，然后手动按了50次F8才找到问题。我走过去跟他说：「你换个条件断点，3秒搞定。」他一脸懵。嗯，这就是我们要聊的下一个点。

2. 方法断点：直接跳到函数入口

方法断点，就是在方法名那一行（比如 public void doSomething()）打上断点。程序进入这个方法时就会停下来。好处是：你不用在方法内部找第一行代码在哪，直接就能看到参数值。

我个人习惯在调试接口时，直接在Controller的方法上打方法断点。这样一眼就能看到请求参数对不对，省得在几十行代码里找入口。

3. 条件断点：精准打击，不浪费一次暂停

条件断点，就是给断点加一个条件表达式。只有条件满足时，程序才会停下来。这是我最常用的断点类型，没有之一。

举个例子，你有一个循环1000次的列表，你想看第500次时的数据。用行断点你得按500次F8，用条件断点你只需要写一句：i == 500。

// 假设你在调试这段代码
for (int i = 0; i < 1000; i++) {
    process(list.get(i));
}

// 在 process 这一行打条件断点，条件写：i == 500
// 程序会直接停在第500次循环，前面的499次直接跳过

我曾经调试过一个并发问题，某个线程只在特定数据量下才会出bug。我加了一个条件断点：list.size() > 100 && threadName.contains("worker-3")。嗯，一次就定位到了问题。要是用行断点，我估计得盯屏幕盯到下班。

4. 调试面板使用：不只是「下一步」

很多人调试时只用两个按钮：F8（下一步）和F9（恢复运行）。其实调试面板里还有几个宝贝，我挨个说说。

按钮	快捷键	作用	我什么时候用
Step Over	F8	执行当前行，跳到下一行	大部分时候
Step Into	F7	进入当前行调用的方法内部	想看某个方法的具体逻辑时
Force Step Into	Alt+Shift+F7	强制进入，跳过JDK类库的过滤	怀疑JDK本身有bug时（很少见，但遇到过）
Step Out	Shift+F8	跳出当前方法，回到调用处	不小心Step Into了一个不想看的方法时
Drop Frame	无默认快捷键	回退到当前方法的调用处，重新执行	调试时想重走一遍某个流程

我个人最常用的是 Drop Frame。有一次我调试一个复杂的递归算法，走到一半发现前面有个变量值不对。要是重新跑一遍，得等半天。我直接Drop Frame，回退到上一层，修改变量值，继续往下走。省了至少10分钟。

5. 多线程调试：别让线程「乱跑」

多线程调试是很多人的噩梦。你打个断点，一个线程停了，其他线程还在跑。等你恢复运行，数据已经被别的线程改得面目全非了。怎么办？

IDE里有一个设置叫 「Suspend All」 和 「Suspend Thread」。默认是Suspend All，也就是所有线程都停。但有时候你只想停某一个线程，让其他线程继续跑。

我建议的做法是：

• 如果怀疑是线程安全问题，用 Suspend All，把所有线程都停住，然后一个一个看。
• 如果只是想看某个线程的特定行为，用 Suspend Thread，只停那个线程，其他线程继续跑。

还有一个技巧：给断点加线程过滤。在断点属性里，可以设置只对某个线程生效。比如你开了10个worker线程，只有worker-3会出问题。那你就在断点条件里写：Thread.currentThread().getName().equals("worker-3")。这样其他线程根本不会停，只有worker-3会停下来。

6. 知识体系总览

下面这张图，是我自己总结的断点调试知识体系。你可以把它当成一个「调试地图」，遇到问题的时候，看看自己卡在哪一层。

这张图从下往上看：先选对断点类型，再用好调试面板，最后搞定多线程。每一步都踩实了，调试效率自然就上去了。