千万不要在方法上打断点!有坑!
你好呀,我是歪歪。
我上周遇到了一个莫名其妙的搞心态的问题,浪费了我好几个小时。
气死我了,拿这几个小时来敲(摸)代(摸)码(鱼)不香吗?
主要是最后问题的解决方式也让我特别的无语,越想越气,写篇文章吐槽一下。
先说结论,也就是标题:
在本地以 Debug 模式启动项目的时候,千万不要在方法上打断点!千万不要!

首先什么是方法断点呢?
比如这样的,打在方法名这一行的断点:

你点击 IDEA 里面的下面这个图标,View Breakpoints,它会给你弹出一个框。
这个弹框里面展示的就是当前项目里面所有的断点,其中有一个复选框,Java Method Breakpoints,就是当前项目里面所有的“方法断点”:

那么这个玩意到底有什么坑呢?
当项目以 Debug 模式启动的时候,非常非常非常严重的拖慢启动速度。
给你看两个截图。
下面这个是我本地的一个非常简单的项目,没有方法断点的时候,只要 1.753 秒就启动完成了:

但是当我加上一个方法断点的时候,启动时间直接来到了 35.035 秒:

从 1.7 秒直接飙升到 35 秒,启动时间涨幅 2000%。
你说遭不遭得住?
遭不住,对不对。
那么我是怎么踩到这个坑的呢?

一个同事说他项目里面遇到一个匪夷所思的 BUG,想让我帮忙一起看看。
于是我先把项目拉了下来,然后简单的看了一下代码,准备把项目先在本地跑起来调试一下。
然而半个小时过去了,项目还没起来。我问他:这个项目本地启动时间怎么这么长呢?
他答:正常来说半分钟应该就启动起来了呀。
接着他还给我演示了一下,在他那边确实 30 多秒就启动成功了。
很明显,一样的代码,一个地方启动慢,一个地方启动快,首先怀疑环境问题。
于是我准备按照下面的流程走一次。
检查设置 -> 清空缓存 -> 换workspace -> 重启 -> 换电脑 -> 辞职
我检查了所有的配置、启动项、网络连接什么的,确保和他本地的环境是一模一样的。
这一套操作下来,差不多一小时过去了,并没有找到什么头绪。
但是那个时候我一点都不慌,我还有终极绝招:重启。
毕竟我的电脑已经好几个月没有关闭过了,重启一下也挺好的。
果然,重启了电脑之后,还是没有任何改变。
正在焦头烂额之际,同事过来问我啥进度了。
我能怎么说?
我只能说:从时间上来说应该解决了,但是实际上我连项目都还没启动成功。
听到这话,他坐在我的工位,准备帮我看一下。
半分钟之后,一个神奇的场景出现了,他在我的电脑上直接就把项目启动起来了。
一盘问,他并没有以 Debug 的模式启动,而是直接运行的。
用脚趾头想也知道,肯定是 Debug 模式在搞事情。
然后基于面向浏览器编程的原则,我现在有了几个关键词:IDEA debug 启动缓慢。
然后发现有很多人遇到了类似的问题,解决方法就是启动的时候取消项目里面的“方法断点”。
但是,遗憾的是,没有大多数文章都是说这样做就好了。但是并没有告诉我为什么这样做就好了。
我很想知道为什么会有这个坑,因为我用方法断点用的还是很多的,关键是以前在使用的过程中完全没有注意到还有这个坑。
“方法断点”还是非常实用的,比如我随便个例子。
之前写事务相关的文章的时候,提到过这样的一个方法:
java.sql.Connection#setAutoCommit
setAutoCommit 这个方法有好几个实现类,我也不知道具体会走哪一个:

所以,调试的时候可以在下面这个接口打上一个断点:

然后重启程序,IDEA 会自动帮你判断走那个实现类的:

但是需要特别说明的是,不是所有的方法断点都会导致启动缓慢的问题。至少在我本地看起来是这样的。
当我把方法断点加在 Mapper 的接口里面的时候,能稳定复现这个问题:

当把方法断点加在项目的其他方法上的时候,不是必现的,偶尔才会出现这个问题。
另外,其实当你以 Debug 模式启动且带有方法断点的时候,IDEA 是会弹出这个提醒,告诉你方法断点会导致 Debug 缓慢的问题:

但是,真男人,从不看提醒。反正我是直接就忽略了,根本没有关心弹窗的内容。
至于为什么会在 Mapper 的接口上打方法断点?
都怪我手贱,行了吧。

到底为什么
在找答案的过程中,我发现了这个 idea 的官方社区的链接:
https://intellij-support.jetbrains.com/hc/en-us/articles/206544799-Java-slow-performance-or-hangups-when-starting-debugger-and-stepping
这个贴子,是 JetBrains Team 发布的,关于 Debug 功能可能会导致的性能缓慢的问题。

在这个帖子中,第一个性能点,就是 Method breakpoints。
官方是怎么解释这个问题的呢?
我给你翻译一波。
Method breakpoints will slow down debugger a lot because of the JVM design, they are expensive to evaluate.
他们说由于 JVM 的设计,方法断点会大大降低调试器的速度,因为这玩意的 “evaluate” 成本很高。
evaluate,四级单词,好好记一下,考试会考:

大概就是说你要用方法断点的功能,在启动过程中,就涉及到一个关于该断点进行“评估”的成本。成本就是启动缓慢。
怎么解决这个“评估”带来的成本呢?
官方给出的方案很简单粗暴:
不要使用方法断点,不就没有成本了?

所以,Remove,完事:
Remove method breakpoints and consider using the regular line breakpoints.
删除方法断点并考虑使用常规的 line breakpoints。
官方还是很贴心的,怕你不知道怎么 Remove 还专门补充了一句:
To verify that you don't have any method breakpoints open .idea/workspace.xml file in the project root directory (or
.iws file if you are using the old project format) and look for any breakpoints inside the method_breakpoints node.
可以通过下面这个方法去验证你是否打开了方法断点。
就是去 .idea/workspace.xml 文件中,找到 method_breakpoints 这个 Node,如果有就 Remove 一下。
然后我看了一下我项目里面对应的文件,没有找到 method_breakpoints 关键字,但是找到了下面这个。
应该是文档发生了变化,问题不大,反正是一个意思,

其实官方给出的这个方法,虽然逼格稍微高一点,但还是我前面给的这个操作更简单:

针对“到底为什么”这个问题。
在这里,官方给的回答,特别的模糊:because of the JVM design。
别问,问就是由于 JVM 设计如此。
我觉得这不是我想要的答案,但是好在我在这个帖子下面找到了一个“好事之人”写的回复:

这个好事之人叫做 Gabi 老铁,我看到他回复的第一句话 “I made some research”,我就知道,这波稳了,找对地方了,答案肯定就藏在他附上的这个链接里面。
Gabi 老铁说:哥子们,我研究了一下这个方法断点为啥会慢的原因,研究报告在这里:
http://www.smartik.net/2017/11/method-breakpoints-are-evil.html
他甚至还来了一个概要:To make the long story short,长话短时。
他真的很贴心,我哭死。
他首先指出了问题的根本原因:
it seems that the root issue is that Method Breakpoints are implemented by using JDPA's Method Entry & Method Exit feature.
根本问题在于方法断点是通过使用 JDPA 的 Method Entry & Method Exit 特性实现的。
有同学就要问了,JDPA,是啥?
是个宝贝:
https://docs.oracle.com/javase/8/docs/technotes/guides/jpda/index.html

JPDA,全称 Java Platform Debugger Architecture。
IDEA 里面的各种 Debug 功能,就是基于这个玩意来实现的。
不懂也没关系,这个东西面试又不考,在这里知道有这个技术就行。
接着,他用了四个 any 来完成了跳句四押:
This implementation requires the JVM to fire an event each time any thread enters any method and when any thread exits any method.
这个实现,要求 JVM,每次,在任何(any)线程进入任何(any)方法时,以及在任何(any)线程退出任何(any)方法时触发事件。
好家伙,这不就是个 AOP 吗?
这么一说,我就明白为什么方法断点的性能这么差了。要触发这么多进入方法和退出方法的事件,可不得耗费这么多时间吗?
具体的细节,他在前面说的研究报告里面都写清楚了,如果你对细节感兴趣的话,可以咨询阅读一下他的那篇报告。
话说他这个报告的名字也起的挺唬人的:Method Breakpoints are Evil。
我带你看两个关键的地方。
第一个是关于 Method Entry & Method Exit 的:

IDE 将断点添加到其内部方法断点 list 中 IDE 告诉前端启用 Method Entry & Method Exit 事件 前端(调试器)通过代理将请求传递给 VM 在每个 Method Entry & Method Exit 事件中,通过整个链将通知转发到 IDE IDE 检查其方法断点 list 是否包含当前的这个方法。 如果发现包含,说明这个方法上有一个方法断点,则 IDE 将向 VM 发送一个 SetBreakpoint 请求,打上断点。否则,VM 的线程将被释放,不会发生任何事情
这里是表明,前面我说的那个类似 AOP 的稍微具体一点的操作。
核心意思就一句话:触发的事件太多,导致性能下降厉害。
第二个关键的地方是这样的:

文章的最后给出了五个结论:
方法断点 IDE 的特性,不是 JPDA 的特性 方法断点是真的邪恶,evil 的一比 方法断点将极大的影响调试程序 只有在真正需要时才使用它们 如果必须使用方法作为断点,请考虑关闭方法退出事件
前面四个点没啥说的了。
最后一个点:考虑关闭方法退出事件。
这个点验证起来非常简单,在方法断点上右键可以看到这个选项,Method Entry & Method Exit 默认都是勾选上了:

所以我在本地随便用一个项目验证了一下。
打开 Method Exit 事件,启动耗时:113.244 秒。
关闭 Method Exit 事件,启动耗时:46.754 秒。
你别说,还真有用。
现在我大概是知道为什么方法断点这么慢了。
这真不是 BUG,而是 feature。
而关于方法断点的这个问题,我顺便在社区搜索了一下,最早我追溯到了 2008 年:

这个老哥说他调试 Web 程序的速度慢到无法使用的程度。他的项目只启用了一行断点,没有方法断点。
请求大佬帮他看看。
然后大佬帮他一顿分析也没找到原因。
他自己也特别的纳闷,说:

我啥也没动,太奇怪了。这玩意有时可以,有时不行。
像不像一句经典台词:

但是问题最后还是解决了。怎么解决的呢?
他自己说:

确实是有个方法断点,他也不知道怎么打上这个断点的,可能和我一样,是手抖了吧。
意外收获
在前面出现的官方帖子的最下面,有这样的两个链接:

它指向了这个地方:
https://www.jetbrains.com/help/idea/debugging-code.html

我把这部分链接都打开看了一遍,经过鉴定,这可真是好东西啊。
这是官方在手摸手教学,教你如何使用 Debug 模式。
我之前看过的一些调试小技巧相关的文章,原来就是翻译自官方这里啊。
我在这里举两个例子,算是一个导读,强烈推荐那些在 Debug 程序的时候,只知道不停的下一步、跳过当前断点等这样的基本操作的同学去仔细阅读,动手实操一把。
首先是这个:

针对 Java 的 Streams 流的调试。
官方给了一个调试的代码示例,我做了一点点微调,你粘过去就能跑:
class PrimeFinder {
public static void main(String[] args) {
IntStream.iterate(1, n -> n + 1)
.limit(100)
.filter(PrimeTest::isPrime)
.filter(value -> value > 50)
.forEach(System.out::println);
}
}
class PrimeTest {
static boolean isPrime(int candidate) {
return candidate == 91 ||
IntStream.rangeClosed(2, (int) Math.sqrt(candidate))
.noneMatch(n -> (candidate % n == 0));
}
}
代码逻辑很简单,就是找 100 以内的,大于 50 的素数。
很明显,在 isPrime 方法里面对 91 这个非素数做了特殊处理,导致程序最终会输出 91,也就是出 BUG 了。
虽然这个 BUG 一目了然,但是不要笑,要忍住,要假装不知道为什么。
现在我们要通过调试的方式找到 BUG。
断点打在这个位置:

以 Debug 的模式运行的时候,有这样的一个图标:

点击之后会有这样的一个弹窗出来:

上面框起来的是对应着程序的每一个方法调用顺序,以及调用完成之后的输出是什么。
下面框起来的这个 “Flat Mode” 点击之后是这样的:

最右边,也就是经过 filter 之后输出的结果。
里面就包含了 91 这个数:

点击这个 “91”,发现在经过第一个 filter 之后,91 这个数据还在。
说明这个地方出问题了。
而这个地方就是前面提到的对 “91” 做了特殊处理的 isPrime 方法。
这样就能有针对性的去分析这个方法,缩小问题排除范围。
这个功能怎么说呢,反正我的评论是:

总之,以上就是 IDEA 对于 Streams 流进行调试的一个简单示例。
接着再演示一个并发相关的:

官方给了这样的一个示例:
public class ConcurrencyTest {
static final List a = Collections.synchronizedList(new ArrayList());
public static void main(String[] args) {
Thread t = new Thread(() -> addIfAbsent(17));
t.start();
addIfAbsent(17);
t.join();
System.out.println(a);
}
private static void addIfAbsent(int x) {
if (!a.contains(x)) {
a.add(x);
}
}
}
代码里面搞一个线程安全的 list 集合,然后主线程和一个异步线程分别往这个 list 里面塞同一个数据。
按照 addIfAbsent 方法的意思,如果要添加的元素在 list 里面存在了,则不添加。
你说这个程序是线程安全的吗?
肯定不是。
你想想,先判断,再添加,经典的非原子性操作。
但是这个程序你拿去直接跑,又不太容易跑出线程不安全的场景:

怎么办?
Debug 就来帮你干这个事儿了。
在这里打一个断点,然后右键断点,选择 “Thread”:

这样程序跑起来的时候主线程和异步线程都会在这个地方停下来:

可以通过 “Frames” 中的下拉框分别选择 Debug 主线程还是异步线程。
由于两个线程都执行到了 add 方法,所以最终的输出是这样的:

这不就出现线程不安全了吗?
即使你知道这个地方是线程不安全的,但是如果没有 Debug 来帮忙调试,要通过程序输出来验证还是比较困难的。
毕竟多线程问题,大多数情况下都不是每次都能必现的问题。
定位到问题之后,官方也给出了正确的代码片段:

好了,说好了是导读,这都是基本操作。还是那句话,如果感兴趣,自己去翻一下,跟着案例操作一下。
就算你看到有人把 Debug 源码,玩出花来了,也无外乎不过是这样的几个基础操作的组合而已。
回首往事
让我们再次回到官方的“关于 Debug 功能可能会导致的性能缓慢的问题”这个帖子里面:

当我看到方框里面框起来的 “Collections classes” 和 “toString()” 方法的时候,眼泪都快下来了。
我最早开始写文章的时候,曾经被这个玩意坑惨了。
三年前,2019 年,我写了这篇文章《这道Java基础题真的有坑!我也没想到还有续集。》
当时 Debug 调试 ArrayList 的时候遇到一个问题,我一度以为我被质子干扰了:

一句话汇总就是在单线程的情况下,程序直接运行的结果和 Debug 输出的结果是不一样的。
当时我是百思不得其解。
直到 8 个月后,写《JDK的BUG导致的内存溢出!反正我是没想到还能有续集》这篇文章的时候才偶然间找到问题的答案。
根本原因就是在 Debug 模式下,IDEA 会自动触发集合类的 toString 方法。而在某些集合类的 toString 方法里面,会有诸如修改头节点的逻辑,导致程序运行结果和预期的不匹配。
也就是对应这句话:

翻译过来就是:老铁请注意,如果 toString 方法中的代码更改了程序的状态,则在 debug 状态下运行时,这些方法也可以更改应用程序的运行结果。
最后的解决方案就是关闭 IDEA 的这两个配置:

同时,我也在官方文档中找到了这个两个配置的解释:
https://www.jetbrains.com/help/idea/customizing-views.html#renderers

主要是为了在 Debug 的过程中用更加友好的形式显示集合类。
啥意思?
给你看个例子。
这是没有勾选前面说的配置的时候,map 集合在 Debug 模式下的样子:

这是勾选之后,map 集合在 Debug 模式下的样子:

很明显,勾选了之后的样子,更加友好。
最后,我的文章全网首发都在我的公众号里面哦。欢迎关注:

【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· 上周热点回顾(2.17-2.23)
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· 如何使用 Uni-app 实现视频聊天(源码,支持安卓、iOS)