你好呀，我是歪歪。
我上周遇到了一个莫名其妙的搞心态的问题，浪费了我好几个小时。
气死我了，拿这几个小时来敲（摸）代（摸）码（鱼）不香吗？
主要是最后问题的解决方式也让我特别的无语，越想越气，写篇文章吐槽一下。
先说结论，也就是标题：
在本地以Debug模式启动项目的时候，千万不要在方法上打断点！千万不要！
首先什么是方法断点呢？
比如这样的，打在方法名这一行的断点：
你点击IDEA里面的下面这个图标，ViewBreakpoints，它会给你弹出一个框。
这个弹框里面展示的就是当前项目里面所有的断点，其中有一个复选框，JavaMethodBreakpoints，就是当前项目里面所有的“方法断点”：
那么这个玩意到底有什么坑呢？
当项目以Debug模式启动的时候，非常非常非常严重的拖慢启动速度。
给你看两个截图。
下面这个是我本地的一个非常简单的项目，没有方法断点的时候，只要1.秒就启动完成了：
但是当我加上一个方法断点的时候，启动时间直接来到了35.秒：
从1.7秒直接飙升到35秒，启动时间涨幅%。
你说遭不遭得住？
遭不住，对不对。
那么我是怎么踩到这个坑的呢？
一个同事说他项目里面遇到一个匪夷所思的BUG，想让我帮忙一起看看。
于是我先把项目拉了下来，然后简单的看了一下代码，准备把项目先在本地跑起来调试一下。
然而半个小时过去了，项目还没起来。我问他：这个项目本地启动时间怎么这么长呢？
他答：正常来说半分钟应该就启动起来了呀。
接着他还给我演示了一下，在他那边确实30多秒就启动成功了。
很明显，一样的代码，一个地方启动慢，一个地方启动快，首先怀疑环境问题。
于是我准备按照下面的流程走一次。
检查设置-清空缓存-换workspace-重启-换电脑-辞职
我检查了所有的配置、启动项、网络连接什么的，确保和他本地的环境是一模一样的。
这一套操作下来，差不多一小时过去了，并没有找到什么头绪。
但是那个时候我一点都不慌，我还有终极绝招：重启。
毕竟我的电脑已经好几个月没有关闭过了，重启一下也挺好的。
果然，重启了电脑之后，还是没有任何改变。
正在焦头烂额之际，同事过来问我啥进度了。
我能怎么说？
我只能说：从时间上来说应该解决了，但是实际上我连项目都还没启动成功。
听到这话，他坐在我的工位，准备帮我看一下。
半分钟之后，一个神奇的场景出现了，他在我的电脑上直接就把项目启动起来了。
一盘问，他并没有以Debug的模式启动，而是直接运行的。
用脚趾头想也知道，肯定是Debug模式在搞事情。
然后基于面向浏览器编程的原则，我现在有了几个关键词：IDEAdebug启动缓慢。
然后发现有很多人遇到了类似的问题，解决方法就是启动的时候取消项目里面的“方法断点”。
但是，遗憾的是，没有大多数文章都是说这样做就好了。但是并没有告诉我为什么这样做就好了。
我很想知道为什么会有这个坑，因为我用方法断点用的还是很多的，关键是以前在使用的过程中完全没有注意到还有这个坑。
“方法断点”还是非常实用的，比如我随便个例子。
之前写事务相关的文章的时候，提到过这样的一个方法：
java.sql.Connection#setAutoCommit
setAutoCommit这个方法有好几个实现类，我也不知道具体会走哪一个：
所以，调试的时候可以在下面这个接口打上一个断点：
然后重启程序，IDEA会自动帮你判断走那个实现类的：
但是需要特别说明的是，不是所有的方法断点都会导致启动缓慢的问题。至少在我本地看起来是这样的。
当我把方法断点加在Mapper的接口里面的时候，能稳定复现这个问题：
当把方法断点加在项目的其他方法上的时候，不是必现的，偶尔才会出现这个问题。
另外，其实当你以Debug模式启动且带有方法断点的时候，IDEA是会弹出这个提醒，告诉你方法断点会导致Debug缓慢的问题：
但是，真男人，从不看提醒。反正我是直接就忽略了，根本没有关心弹窗的内容。
至于为什么会在Mapper的接口上打方法断点？
都怪我手贱，行了吧。
到底为什么
在找答案的过程中，我发现了这个idea的官方社区的链接：