源码阅读的方法、误区以及三种境界
在技术职场中普遍存在如下几种现象：
- 对待工作中所使用的技术不需要阅读源码，只需在开发过程中能够熟练运用就行
- 看源码太费时间，而且容易忘记，如果从实际使用过程中出现的问题出发，针对性的阅读源码，其学习效率会更高效，所以平时无需看源码。
对此我有着不同的理解，容我慢慢道来。
本文将从如下4个角度进行剖析：
- 源码阅读的必要性
- 源码阅读技巧
- 源码阅读的三种境界
- 源码阅读的误区
1、源码阅读必要性
1.1 通用型基础技术应该深入源码研究
在 JAVA 领域中笔者认为通用型基础技术包含 JAVA 集合、Java并发(JUC)。这类技术是项目中使用的高频技术，在合适的场景中选用合适的数据结构、选用合适的线程并发模型、合理控制锁粒度等都能显著提高应用程序的可用性、健壮性。
通用型技术正因为其具有普遍性，横向对比更具代表性，职场面试时的可辨别性非常高，如何在高样本中突出自己就显得极为必要，通过阅读源码，深刻理解其内部原理成为我们的不二法宝。
当然通过阅读源码并不是知晓原理的唯一方法，但作为一个名程序员、直面代码，亲自感受代码的魅力或许来的更加直接。
1.2 重点领域应深入源码研究
为了提高辨识度作为职场的我们应该打造自己的专属标签，即**“亮点”**。通常情况我们应该选择在日常工作中使用的技术，在积累了丰富的使用经验、线上故障排查经验的前提下，应该深入研究其源码，成体系掌握该技术，从而对其更具掌控性，做到提前预判线上问题，规避大量线上故障，提升稳定性，助力业务降本增效。
例如笔者所在公司在微服务、消息中间件领域分别采用了 Dubbo、RocketMQ，并且笔者有幸参与到这项技术栈的运用与运维，积累了丰富的使用经验，为此笔者为了突出在这两个领域的优势，详细阅读其源码，并作成专栏发布在『中间件兴趣圈』公众号与CSDN等知识分享平台，由于是成体系剖析的原因被出版社相中，邀请出书，《RocketMQ技术内幕》一书就在这样的背景中应运而生，从而成为笔者职业技能中非常亮眼的标签，助力职场。
源码阅读确实很重要，但一定需要成体系研究，大部分人认为在处理问题时再根据具体问题去看源码，会更有针对性，觉得没必要成体系看。
不可否认这有其正确性的一面，从问题本身出发，看源码效率更快，“投入产出比”更高，随着遇到的问题越来越多，对该技术理解也会越来越深，这个其实就是我们通常讲的**“经验”**。我觉得大部分情况下是可取的，这个过程其实是一个被动的过程，并且如果生产环节由于并发不高等因素，可能一年、两年也不会出现一两次故障，这样就会造成经验的积累会非常慢，从而使得工作了4、5年的朋友其竞争力还不如工作2,3年的重要原因，所以我的观点是如果是想打造成自己的专属亮点的话，我们还是需要主动通过阅读其源码，成体系掌握其设计理念、实现原理，更好的打造自己的专属亮点。
2、如何阅读源码
既然阅读源码非常有必要，那如何阅读源码呢？笔者根据多年的源码阅读经验整理了如下方法论：
- 了解这款中间件的使用场景、以及架构设计中将承担的责任。
- 寻找官方文档，从整体上把握这款中间件的设计理念。
- 搭建自己的开发调试环境，运行官方提供Demo示例，为后续深入研究打下基础。
- 先主干流程再分支流程，注意切割，逐个击破。
- 阅读源码过程中带着思考与质疑思维。
理解了其使用场景后，结合官方文档，尝试理解该中间件需要解决的问题、并思考如何解决，思考过程中并不一定要求我们想出一个具体的答案，只是在真正步入源码阅读时能更快感悟其代码含义。
当然在阅读源码的过程中可能会到难题，遇到无法理解作者的实现意图，特别是遇到一些自己不太熟悉的编程方式(例如位运算)，此时通常有两种解决方案：
- 通过DEBUG，结合运行时数据，方便对代码的理解。
- 从易到难，可以先尝试阅读一下JAVA集合框架的源码，提炼出一套自己的源码研究方法论。
源码阅读其实最难的不是代码本身，也不是无法理解其设计理念，最难的是坚持，故在这里借用笔者的座右铭与大家共勉：越努力越幸运，唯有坚持不懈。
3、源码阅读的三层境界
接下来我想再结合笔者4年源码阅读的历程，谈谈我对源码阅读的一些更深层次的理解，介绍一下笔者在各个阶段阅读源码所处的状态。
-
源码阅读的初级阶段 笔者的老粉丝们应该能感觉到笔者初期的源码阅读文章，基本上是记流水账,其最直观的表现现象是对源码一样一行加注释，只关注底层实现细节，但并未形成更高层次认知，对其设计理念并未提炼与深度领悟。
-
能提问、思考、并提炼 随着技术类文章的持续分享，笔者认识了很多大牛、发现与大牛交流的时候，一开始并不会说细节，而是讲设计理念，这就要求我们在阅读源码的时候多思考，并反问自己如果需要自己实现的话我们该如何着手，如何设计，带着疑问去研究源码，通过对比，思考，会对其背后的理念有了更深刻的理解。
-
思考、质疑、验证 其实无论是哪个开源框架都会存在BUG或者实现并不合理的地方，如果大家在阅读源码的时候能够思考并开始质疑其不合理性，并能通过验证证明自己的观点，然后与官方取得联系，交流，建Isuue，共同促进社区的发展，说明我们的能力、思考得到了极大的提升。
关于这一点，可以参考笔者对 Sentinel 对应熔断实现机制进行的质疑与思考过程。
从Sentinel Dubbo 适配器看限流与熔断（实战思考篇）
4、源码阅读误区
源码阅读是手段，但一定不是目的。
我在面试过程中发现好多候选者在谈到某一项技术时，首先不是介绍其原理，而是一下子具体到某个类啥的，这些类是如何如何工作等等，其实这是不太妥当的，源码阅读的目的是主要是深入理解其设计理念、工作机制，方便我们在实际使用过程中对其成体系的认识，加强对它的驾驭能力，做到提前规避风险。
其次源码阅读非常不建议一上来就直接DEBUG。如果一开始就使用DEBUG，很容易会迷失在代码的各个分支中，缺乏全局视角，从而变得没有头绪，极大的增加了源码理解的难度，很容易让我们半途而废。
最后学习一门技术并一定要深入源码，特别是非主流，非重点打造的领域。对于此类我们通常只需根据阅读官方文档，了解其使用场景、能解决什么问题，理解其设计理念、工作机制，灵活运用解决具体问题即可。
5、总结
源码阅读并不是目的，只是手段。对于通用型基础技术诸如JAVA集合、并发、需重点打造为亮点的领域建议大家阅读其源码，成体系深入细节掌握其工作机制，增强其驾驭能力，拥有提前规避风险的能力。
欢迎关注公众号『中间件兴趣圈』，共同探究源码，交流高并发、架构经验，回复 PDF 更是可获取大量学习资料。 
