经常有人问我：源码到底该怎么读？我一般会先反问一句：你为什么要读它？
这不是抬杠。因为这三种目的的读法完全不一样，混在一起就会变成「打开仓库、从第一个文件开始看、看两天放弃」的经典失败流程。我自己重复过至少五次。
目的一：解决一个具体的问题
这是最常见也最容易成功的情况，因为你有一个天然的入口。
我的做法是从调用栈进入，不从入口文件进入。比如我怀疑某个连接池在高并发下会拿到已关闭的连接，我不会去看它的初始化代码，而是直接在获取连接的方法上打个断点，然后看它往下走到哪里、栈上有谁。一次断点带来的信息，胜过读半天代码，因为它告诉你的是实际执行路径，而不是所有可能路径。
如果是异常，那更简单：堆栈本身就是一张地图，从最深的那一层往上读，读到第一个你能看懂的位置，问题往往就在这一层和下一层之间。
目的二：学习设计
这种没有天然入口，最容易迷失。我的几个笨办法：
- 先读测试。测试文件是最好的使用文档，因为它是可执行的、被维护的、而且是作者自己写的最小可运行例子。我读一个网络库的时候，测试目录给我的信息量比文档大得多。
- 只读一条主干路径。选一个最典型的场景，从头跟到尾，中间遇到的所有分支、边界处理、兼容旧版本的代码，一律跳过并且在心里标记「这里有个坑，以后再说」。第一遍求的是连贯性，不是完整性。
- 画时序图。不用工具，纸上画就行。几个对象、几条箭头、标上方法名。画不出来说明没读懂，这个检验很硬。
- 读提交历史。这条我强烈推荐。找到那个让你困惑的函数，看它是哪次提交加进来的，读提交说明和关联的问题单。很多看起来莫名其妙的判断条件，历史里都写着当初是为了修哪个 bug。我曾经看到一段带三重判空的代码，觉得非常啰嗦，翻历史才知道那是三次不同的线上事故各自留下的一层。
目的三：为了显得懂
我说的直白一点：为了面试或者为了在讨论里能接上话而读源码，效率极低，而且忘得极快。我背过某个容器类的扩容因子和阈值计算，三个月后忘光了。真正留在我脑子里的，都是我拿它解决过实际问题的部分。
一个具体的例子
去年我们遇到一个诡异现象：某个客户端在网络抖动后会有几秒钟完全无响应，然后突然恢复。文档里没有相关说明。
我的路径是这样的：先在应用层加日志确认卡在哪个调用；然后在那个调用上打条件断点，只在耗时超过一秒时命中；断点命中后看栈，发现卡在一个锁上；再找持有这个锁的线程，发现它在做重连并且带指数退避；最后翻到退避的实现，看到最大间隔的默认值是 30 秒，而且重连期间会持有全局锁。
整个过程大概两小时，我总共认真读了不到 200 行代码。如果一开始就从项目入口开始通读，两天也走不到这里。
最后一点
读源码最大的收益，其实不是学会某个技巧，而是祛魅。你会发现那些被奉为经典的项目里也有临时补丁、也有语焉不详的变量名、也有作者自己在注释里写「这里我也不确定，先这样」。知道这一点之后，你面对自己的代码会宽容一些，面对别人的框架会大胆一些——它不是黑盒，它只是别人写的代码。