这篇文章其实并没有什么技术性的分享，从我的角度而言，更多是记录和思考。
把我对于源码和之前写的部分文章反哺给我的一些东西，带来的一点点思考分享给大家。
一行源码
我很长时间没打开我的 Outlook 邮箱了。
前两天打开的时候发现我之前给 Dubbo 提交的 pr 居然已经被合并到 master 了：
这是第一次，我提交的 pr 被合并了。
这个 pr 是修复 LFU 缓存策略在 Dubbo 中即使配置了，也不起作用的 bug。
于是我也算是为开源项目贡献过源码的人了。
什么你问我贡献了多少代码？
一行，是的，就一行！
而且，说起来，这次提交真的是没有什么技术含量的事情。因为这是一个必现的 bug，只是很少有人用到这个功能而已。
你知道的，当一个 bug 能稳定复现的时候，其实它已经就不算是一个 bug 了。
但是我想聊聊这次提交背后的一些东西。
发现与解决
从宿命论的角度来说，当我写下面这篇文章的第一个字的时候，这个 bug 就注定是等着我去发现并修复了：
而这篇文章我敲下第一个字的时间是 2020 年 12 月的下旬，这是我 2020 年的最后一篇技术原创文章。
当我写 LRU 的时候，我就知道 LFU 肯定也是需要专门写一篇的。
于是 2021 年的第一篇技术原创文章，我就选题了 LFU。
产生了这篇文章：
写这篇文章的时候，我想起之前看 Dubbo 的版本，好像是提到了一下 LFU。
于是我翻到了 2.7.7 版本的发布内容：
果然是支持了 LFU 缓存策略，于是翻出了提交的代码记录：
虽然他的实现逻辑没有问题，Test 类也跑过去了。
但是毫不夸张的说，我看了一眼这个提交记录，就发现了这里势必是有问题的。
他仅仅是把 LFU 缓存策略集合到了 Dubbo 代码中，但是却没有给使用者提供使用的入口。
因为这里是基于 SPI 实现的，他没有在对应的配置文件中加入配置。
这个问题非常容易验证，我们可以看一下。
其源码的位置是：org.apache.dubbo.common.utils.LFUCache
No such extension org.apache.dubbo.cache.CacheFactory by name lfu
没有 lfu 这个策略。
这不是玩我吗？
再看一下具体的原因：
在 org.apache.dubbo.common.extension.ExtensionLoader#getExtensionClasses 处只获取到了 4 个缓存策略，并没有我们想要的 LFU。
所以，在这里抛出了异常：
为什么没有找到我们想要的 LFU 呢？
那就得看你熟不熟悉 SPI 了。
在 SPI 文件中，确实没有 LFU 的配置：
经过上面的分析，其实你也发现了，这个并不是一个有什么技术含量的提交。
更多的是运气成分。
只是由于对于 Dubbo 框架有些许的了解，所以对于这个地方，我发现问题、定位问题、解决问题的速度非常的快。
这是运气带不给我的东西。
这需要日复一日的潜入到框架中去，去感受它的脉络，梳理它的结构，学习它的思想。
这是需要时间去沉淀和学习的东西。
注意，我说的是“潜入”，而非是流于表面的。
什么是流于表面的呢？
比如，如果你之前没有用过 Dubbo 框架，但你又想去了解，学习它。
于是你看到了我的这篇或者其他的和 Dubbo 相关的公众号文章，企图从这些文章中入手。
记住鲁迅先生的话：
亦或者是你在搜索框里面，输入 “Dubbo”，然后漫无目的的看了起来。
哪怕你买了一本 Dubbo 相关的书或者看了 Dubbo 相关的系列视频，进行系统的学习。
我觉得，只要没有自己亲手去做，都属于流于表面。
而自己动手的第一步，就是搭建 Demo，从 Demo 入手。
到后面高阶一点的就是你了解到了这个框架的前世今生，能在几个大版本之间进行横向对比，知道为什么升级、怎么升级、升级之后是怎么样的。
再之后，能细致到某一个大的模块的演变是怎样的，历史上出现过哪些 Bug，是怎么去修复的。在那个版本之后进行了修复，是稳定的。
再举个例子吧。
