千万千万不要在方法上打断点!太坑了!

来源 | why技术

作者 | why技术

上周遇到了一个莫名其妙的搞心态的问题,浪费了我好几个小时。

主要是最后问题的解决方式也让我特别的无语,真的是越想越气。

先说结论,也就是标题:

在本地以 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 源码玩出花来了,也无外乎不过是这样的几个基础操作的组合而已。

 – END –

5 1 投票
文章评分

本文转载自why技术,原文链接:https://mp.weixin.qq.com/s/CL7gX5baeeIvgjRIySmN-w。

(1)
上一篇 2022-08-20 21:25
下一篇 2022-08-20 21:30

相关推荐

订阅评论
提醒
guest
0 评论
内联反馈
查看所有评论
0
希望看到您的想法,请您发表评论x