写过但没有发现的 bug
我之前还写过一样的一篇文章：
当时这个版本推出之后，我就赶紧去研究了一下对应部分的源码，然后写下这篇自称为全网第一篇解析 Dubbo 2.7.5 里程碑版本中的改进点之一：客户端线程模型优化的文章。
但是前两天我看提交记录的时候，发现了这样的一个提交：
并找到了对应的 issue：
https://github.com/apache/dubbo/issues/7054
根据这个 issue，我去看了一下对应的源码，确实是存在他描述的问题。
于是我就在想，我当时写文章的时候也是深入到源码里面了呀，为什么没有发现这样的问题呢？
我想原因还是在于自己当时思考的深度不够，仅仅是搭建了一个非常简陋的 Demo，而且把心思聚焦到了前后版本差异对比上。
只是摸到了一个大概的样子，被源码牵着走了，并没有跳出源码的包围，带着质疑的眼光去审视它。
所以，对于这种比较深层次的、一环扣一环的问题，自己还是流于表面了一些。
怎么看源码
前面举了三个例子，一个是发现并解决了 bug，一个是仅发现未解决的 bug，一个是有 bug 但没有发现。
前两个 bug 都有一个共性，在简单的 Demo 下就是必现的，只要跑到了对应的地方，就会出现和预期不符的情况，比较容易发现。
最后一个 bug 隐藏的比较深入一点，也许你触发了，但是程序自愈了。
当有一天我能发现并解决这样的 bug 时，我就不会说这是运气了。
但是发现这些 bug 的前提是得动手搭建 Demo 呀。
你不看源码，只是看网上的文章，是永远发现不了问题的，也是潜入不进去的。
分享一下我看源码的方法吧。
我们知道开源框架的设计和理念大多是非常优秀的，但是源码里面的细枝末节特别的多，一不小心就容易在源码里面迷失，直接就是一波劝退。
所以，对于初读源码的同学，首先要做的就是把核心流程梳理出来，边梳理边画图，要多画图，别怕麻烦。
对于几处关键的源码，一定要写上自己的备注。因为你知道的，当时也许你对这个地方为什么这样写门清，但是隔段时间再回来看，就摸不着头脑了。这个时候，备注就显的非常重要了。
对于看不明白的地方，打断点，疯狂的调试，反复的调试。
等待主流程摸清楚之后，再去进入到源码的细节部分。
举个简单的例子，比如你看 Dubbo 源码，先摸清楚它一次请求大概的调用链路之后，再去细致了解其中负载均衡的部分。
然后，就是多复习，多巩固了。
你发现没有，我说的这些其实你也知道，或者其他人也是这样说的。
为什么你看的时候就老是看不进去呢？不得要领呢？
是的，我开始也是这样的。但是，无它，唯反复练习尔。
共勉之。
最后说一句
才疏学浅，难免会有纰漏，如果你发现了错误的地方，可以在后台提出来，我对其加以修改。
感谢您的阅读，我坚持原创，十分欢迎并感谢您的关注。
