千万不要在方法上打断点、有大坑

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

气死我了，拿这几个小时来敲（摸）代（摸）码（鱼）不香吗？

主要是最后问题的解决方式也让我特别的无语，越想越气，写篇文章吐槽一下。

先说结论，也就是标题：

在本地以 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 的接口里面的时候，能稳定复现这个问题：