乐趣区

关于java:分享一个我看源码时的小技巧

你好呀,我是歪歪。

我在之前的文章外面不是常常叫大家拉源码,而后看代码提交记录吗。

也就是看相似于这个界面:

比方下面这个界面中,就能够看到 RedissonBaseLock.java 这个文件,由谁在什么时候进行过变更,以及变更对应的 commit 信息是什么。

这样就能很直观的看到文件的演变过程。

那么问题就来了,有好几个同学都问过我这个问题:怎么在 idea 外面查看 git 提交记录呢?这个界面是藏在哪里的呢,我的 idea 外面怎么没有呢?

好的,是我忽略了,我先入为主的认为这个大家应该都晓得是怎么来的。

然而的确是有一些同学是不太分明的,那我这篇文章就给大家分享一下我通过这个货色看源码的一点点小技巧,心愿能帮忙到你。

怎么搞进去?

那么怎么把这个视图搞进去呢?

首先,你本地得有一个 git.exe。

这个玩意怎么来的,就不必我说了吧,如果连这个都没有,阐明你之前还没有接触过 git,那就是另外一回事儿了,不在本文探讨范畴内。连忙去装置一个 git,而后学学 git 的用法啥的。

我集体的习惯是先用 gitbash,也就是这个玩意,从 github 上 clone 一个我的项目下来:

比方我就用之前写文章的 Redssion 做演示吧,你也能够轻易找一个本人感兴趣的开源我的项目。

执行上面命令把我的项目下载下来:

git clone https://github.com/redisson/r…

下载实现之后,关上你的 idea,导入咱们刚刚下载的我的项目。

而后轻易关上一个文件,点击右键,看看有没有 Git 这个选项:

如果顺利的话,你点击 ShowHistory 之后,就能看到这个窗口了:

如果不顺利,阐明你的 git 配置有问题。

在 idea 的 Settings 外面进行对应的设置:

设置实现之后,能够点击旁边的 test 按钮,如果有弹窗通知你对应的版本号,那就阐明配置胜利了:

总之,只有能调出 Version Control 标签页或者有的高版本外面就叫做 git,就代表配置胜利了。

怎么看?

不论是在工作中还是写文章的时候,我个别在 idea 外面只是看提交记录,我不会用 idea 外面的 git 去做提交代码的动作。

其实 idea 外面拉取代码,提交代码什么的可视化页面做的很好,然而我还是比拟喜爱间接在 gitbash 外面敲命令,也没有什么特地的起因,只是这样显得逼格高而已。

那么,到底怎么去看呢?

以我之前写的 Redisson 文章为例。

次要是围绕着 RedissonLock.java 这个类在写,我是怎么晓得这个类的呢?

其实本人带着问题去 debug 也必定能定位到这个类,然而须要一点工夫。

我以前就是搭完环境之后,就开始疯狂的写案例 debug 了。

当初我学聪慧了,环境搞定之后,先去 github 的 issues 外面拿着关键词去搜一下。

比方我的关键词就是死锁:

然而我强烈建议你别用中文搜索,用英文,deadLock:

这样能搜进去的信息就很多,剩下的就是你一个个点开,看看是不是和本人遇到的问题一样,或者类似。

这个过程会花一点点工夫,然而相对比你一头扎进源码外面找答案快的多。

比方,下面的截图中,最初一个叫 Deadlock after Redis timeout 的 issue,就是我想要找的货色:

在这个外面给出了复现的代码,波及的版本,以及预期的后果和理论的体现。

比如说我找到这个链接之后,对我而言就是找到了一个测试用例,同时他通知了我一个命令:

CLIENT PAUSE 5000

在这之前,我是不晓得这个命令的。我还始终在想,我做 Demo 复现的时候,应该怎么去模仿 Redis 执行命令超时的景象呢?

我过后能想到的一些计划就是 bigkey,或者灌很多数据进去,而后我执行 keys * 命令,再或者搞个 save 命令,这样来模仿 Redis 阻塞。

然而,这都是有工作量且阻塞工夫不可控的。而这个命令间接解决了我这个问题,至多让我少走了几步弯路吧。

同样,这个 issues 外面还关联了几个其余的 issues,这些都是官网认为是同一个起因造成的问题:

而后怎么解决的呢?

惯例来说,他们应该关联一个 pr,通过这个 pr 我就能间接关联到对应的修复的内容。

然而这次他们搞了一个骚操作,间接先弄了一个 SNAPSHOT 版本,并没有关联 pr:

怎么办?

这个时候我想去看他是怎么修复这个问题的,怎么办?

后面提到的 idea 外面的 git 插件就派上用场了。

首先,从他的评论工夫我晓得是 2019 年 3 月 13 号,那么我能够间接在工具外面定位到那一天提交的内容。

点击 Version Control 视图外面的 Log 标签,就能够看到整个我的项目历史上的所有的提交,它会依照工夫的程序给你排好序,所有很容易就找到了当天的相干的提交:

你要是感觉难得找,也能够间接通过日期进行过滤:

从当天提交的这个 commit 信息来看,就晓得我找对中央了。

而这里就只是批改了 RedissonLock.java 这个类,所以我就找到了这个要害的类:

而后点进去再剖析一下这个类具体的批改,这样算是找到了 debug 的时候我应该重点关注的中央。

又比方看门狗生效的那个 bug:

https://github.com/redisson/r…

在这外面,就是间接关联了一个 pr,而后咱们能够通过这个链接,找到提交的代码,也能够找到其对应的 issues。

这玩意属于双向奔赴了。

而且我也能晓得这次提交对应的类叫做 RedissonBaseLock.java:

那我又能够回到 idea 的视图外面,间接看看这个类的提交记录了:

一看才发现,这个哥们一共提交了三次。而且还发现这个类还挺年老的,2021 年 1 月 21 日才首次提交。

我之前在《踩到一个对于分布式锁的非比寻常的 BUG!》这篇文章外面留了个思考题:

就是由这三次提交引起的。

我带你看一下这三次提交别离是什么。

首先第一次提交,退出了 else 分支,外面执行了一次 cancelExpirationRenewal 办法,入参是 threadId。

含有是把以后线程的重入次数减一。

然而能走到 else 分支外面来有个大前提是给锁续命的 lua 脚本返回 false,也就是说这个锁都没了。

锁都没了,还保护重入次数干啥呢?

间接从 MAP 外面把这个对象拿掉就行了。

怎么拿掉呢?

传入 null 就能够了:

所以,才有了第二次提交,把入参从 threadId 批改为 null:

那么第三次提交又是干啥呢?

是不是齐全看不出来是干啥?

别急,我这样给你上个截图你就懂了:

之前是用的 tab 制表符,起初批改为四个空格。这是编码格调的问题。

提到用 tab 还是用空格,这又是另外一个在编程畛域外面争执不止的话题了。

我记得之前我看过一个美剧,叫做《硅谷》。外面的主人公就因为到底应该用 tab 还是用空格和女朋友吵了一架。

而后 …

我写文章的时候还想起了一个无聊的问题,并且去寻找到了答案。

我想晓得 Redisson 是在什么时候引进看门狗机制的,我想看看这个狗子最开始的模样。

我怎么找的呢?

首先我晓得启动看门狗的代码是位于 RedissonLock.java 中的 renewExpiration 这个办法:

那我就在 RedissonLock.java 的历史提交记录外面用找一下 renewExpiration 这个办法什么时候是第一次提交的就行了。

于是我很快就找到了 2019 年 3 月 13 日的这次:

我才发现原来看门狗还换过名字,它之前叫做 scheduleExpirationRenewal,起初才改名叫 renewExpiration。

很显然,我感觉新名字更好。

而后我就持续找 scheduleExpirationRenewal 是什么时候第一次呈现的,我找啊找啊,找到了 2015 年 12 月 14 日的这次提交:

好家伙,这个狗子还有个叫做 newRefreshTask 的曾用名啊。

最终,找到了 newRefreshTask 第一次呈现的中央,就是 2015 年 7 月 4 日:

这就是看门狗的生日,间隔明天不到两个月了,我提前祝它生日快乐。

然而,我不得不吐槽一句。

对于看门狗的这一次提交,提交了十分多的货色。能够在这次提交上右键,而后点击上面框起来的选项:

就能看到这次提交的所有货色:

提交了 31 个文件,其中蕴含了看门狗机制。

然而提交的 commit 信息十分简陋,只体现了因为波及到事务操作,所以应用了 LUA 脚本的这一个个性。

这就是一个十分不好的 commit 提交示例。

然而你转念一想,你每次提交的时候示例是怎么写的,是不是也常常偷懒。

别问我是怎么晓得。

所以,每次提交的 commit 信息还是要认真写的,因为你要晓得,总是有我这样无聊的人,会去翻一些没啥卵用的知识点进去。

比方我问你,我找看门狗机制的这段形容,除了让你晓得它的生日和几个曾用名之外还有什么卵用吗?

是的,没有。

祝贺你又学到了一个没啥卵用的知识点。

再来一个

我再带你看一个我的项目,Dubbo。

还是依照我后面说的,把我的项目拉下来,而后点击这里的 log,就能够看到整个我的项目历史上的所有提交:

拉到最上面,能够找到历史上第一次提交的状况:

第一次提交是梁飞在 2011 年 10 月 20 日 23 点 04 分提交的。

然而从提交的 commit 信息来看,咱们也晓得这是一次空提交。

真正的第一次提交是 2 分钟之后的 23 点 06 分:

9 个模块,共计 669 个文件,就是日后这个一路坎坎坷坷、几近夭折、友商续命,最终成为 Apache 顶级开源我的项目的雏形。

11 年前的 10 月 20 日,梁飞从早晨 23 点干到了凌晨 5 点 25 分,终于给 Dubbo 打上了第一个里程碑 tag:2.0.7。

期间,还公布了一个微博:

而他本人,第二天的中午,也在本人的博客上颁布了这件事件:

https://www.iteye.com/blog/ja…

为什么 Dubbo 会选在这一天进行开源呢?

我想应该是为了赶上两天之后的 Qcon 寰球软件开发者大会:

那一天,才是 Dubbo 真正意义上,站在公众视线里,承受投诉与讥嘲的开始。

在 idea 的视图外面,还能够过滤指定的人提交的记录。

比方梁飞就用过上面这几个账号提交代码:

我过滤了一下,发现多达 1294 次,最初一次提交在 2015 年 4 月 1 日:

而且我还发现他特地能肝,相似这样工夫点的提交记录有好几处:

而后我还找了几个类,想看看通过 10 多年的倒退,这些类中还留下多少他的代码。

首先我给你看看这个负载平衡策略相干的类 AbstractLoadBalance.java。

在这个类上右键,而后抉择 git->Annotate 就能够调出右边的 (工夫 - 用户) 的视图:

这就示意的是以后这个类,每一行代码是谁在什么时候提交的。

还是能够看到梁飞的身影。

而且我给你看看这个:

这个办法是 Dubbo 启动的时候,给新机器预热,一点点的给权重。第一分钟给 10% 的流量,第二分钟给 20% 的流量 … 第十分钟这个时候机器基本上曾经通过充沛的预热,所以能够给到 100% 的流量。

至于为什么要预热呢,这个就和 JVM 相干了,你如果感兴趣的话,能够去钻研一下。

就是这个性能,这一个外围办法,通过 10 多年工夫,除了一点微调,其外围算法、外围逻辑没有产生一点变动。

再比方,我给你看看起码沉闷数负载平衡策略的实现 LeastActiveLoadBalance.java:

从初始化提交之后,一共就没批改过几次。

然而你要晓得每次提交都是有它的意义的,比方这两次:

一次提交是把变量 leastIndexs 批改为 leastIndexes,因为 index 是 x 结尾的,以 s、x、sh、ch 结尾的名词,它的复数模式应该是加 es。这是一个英语小常识。

一次提交是把 Random 替换为 ThreadLocalRandom,因为后者性能更好,这是编程小常识,背地的起因是值得深挖的。就看有没有有心人了。

你也能够比照一下,初始版本和以后最新的版本,外围算法、外围逻辑根本没有发生变化:

这两个类通知我一个什么情理?

比起业务代码的增删改查,只有算法,稳固的算法才是更容易再岁月的长河中留下来的,而且历久弥新。

而后,再回到 log 的标签中,你会发现一个很奇怪的景象。

整个 2014 年到 2015 年,都没有提交过几次代码:

其实从 2013 年开始到 2017 年基本上就没多少提交了。

这是为什么呢?

这就不得不说一下 Dubbo 崎岖的毕生了。

后面说了,2011 年它是属于出世寒门,从阿里开源走了进去。

然而在 2012 年 10 月 23 日,Dubbo 2.5.3 公布后,阿里就基本上进行了对于 Dubbo 的保护降级。

而后始终到 2017 年 9 月 7 日,Dubbo 轻轻在 GitHub 公布了 2.5.4 版本。随后,又迅速公布了 2.5.5、2.5.6、2.5.7 等版本。在 10 月举办的云栖大会上,阿里发表 Dubbo 被列入团体重点保护开源我的项目,这也就意味着 Dubbo 起死回生,开始从新进入快车道。

在 2012 年到 2017 年这五年间,当当网本人拉了一个 Dubbox 的分支开搞,相当于帮 Dubbo 把命给续住了。

2018 年 1 月 8 日,Dubbo 2.6.0 版本公布,新版本将之前当当网开源的 Dubbox 进行了合并,实现了 Dubbo 版本的对立整合。

而后 2018 年 2 月,阿里巴巴发表将 Dubbo 募捐给 apache,进入 apache 孵化器。

2019 年 5 月 21 号,通过了漫长的孵化期,Dubbo 迎来了毕业。成为 Apache 基金会顶级我的项目。

之后的故事你应该也就晓得了,Dubbo 当初都搞到 3.0 了,筹备在云原生的赛道上发力。

所以你看,这妥妥的就是一个爽文的套路啊。

这就是一个富家子弟不慎流落街头,被人收养,悉心照料,最初在一片惊呼中,又重回巅峰的故事啊。

那么这个故事通知了咱们一个什么情理呢?

它通知咱们,有个好爸爸真的是太好了。要是 Dubbo 不是阿里开源进去的,起死回生是很难了,对半曾经是隐没在历史的长河中了。

话说回来,后面提到的这些货色,都是能够由我这篇文章给你提到的这个 idea 的视图衍生进去的。

而且我只是给你介绍了一些十分惯例的用法,你能够本人去挖掘出更适宜你本人的关注点。

这玩意,平时本人没事,拉个本人感兴趣的我的项目下来,看看提交记录,看看新个性。

就像我后面说的,每次提交都是有它的意义的,有的提交背地是值得深挖的,就看有没有有心人了。

你说,这玩意难道不比小说难看吗?

欢送关注公众号 why 技术,第一工夫接管最新文章。

退出移动版