一点一点看JDK源码(〇)
liuyuhang原创,未经允许进制转载
写在前面:
几乎所有的大神都会强调看源码,也强调源码的重要性;
但是如何看源码,源码看什么?看了什么用?看了怎么用?
困扰很多人,尤其是初学者。
本系列的目的在于看源码,并非学习和总结源码,先能够粗略的浏览大量的原码
并保证知晓有这么个东西,有个基本概念,再对其中的设计原理,优化方案进行学习
本文简单的回答以下几个问题:
1.为什么要看源码?
2.什么时候或什么条件下看源码?
3.看源码看什么?
4.看源码有什么用?
5.源码看完了怎么用?
接下来以个人见解依次回答以上问题:
1.为什么要看源码?
究这个问题,很多人都认为软件会用即可,写代码也是一种软件应用,这个是本质!
我们都站在巨人的肩膀上,过去是,现在是,将来也是,这个巨人,是历史!
在拿到每一个产品并使用的时候,我们需要仔细阅读产品说明书:(从不看说明书的人左转)
①了解产品的使用功能
②了解产品的安全性能
③了解产品的毒性和副作用
④了解产品的维护周期和生命周期
⑤了解产品的厂商与声明
对于不正确使用产品至死致残又状告商家的,就好像被人砍了要找卖刀的算账一样,
只要超越了一般产品的正常使用方式,出现的问题没人会代你负责的。(扯远了)
源码就是编码的说明书,因为我们在使用这个源码。
我们需要阅读源码,从说明书的角度去正确使用这些工具。
2.什么时候或什么条件下看源码?
本人只有java开发经验,所以只能以java举例进行说明了。
- 如果java的基础语法已经学习完了,能够写一些简单的代码了
- 如果对于java的面向对象设计能够依葫芦画瓢了,已经学完了jdk中的大部分工具了
- 如果每天学习4小时以上,已经连续学习超过一个月了
- 如果你很闲(不知道做什么)
- 如果你很穷(还会写点代码)
- 如果你想吃这口技术饭
以上六条只要满足三条以上,已经是应该适当看看源码的时候了。
3.看源码看什么?
我们说万物究其本源,要透过现象看本质,实际上这两句话并不是完全正确的。
万物的本源应该是微观粒子领域吧,事物的本质都是宇宙基本定律,也许还能更细究。
假设我们要看java的原码,那么又要考虑java是运行在jvm上的,应该看jvm原码。
同时jvm又是c++写的,我们应该看c++原码。
同时c++运行在计算机底层是汇编,我们应该看汇编原码。
这哪里有完。
所以,看java原码,先看使用的工具集,即jdk就足够了。
一项一项向上系统的看才是正确的,至于其他的也并非不进行接触,可能不是那么系统而已。
而jdk看什么?
打开API,好像随便点一个类,都会有一个继承(extends)的类,同时又实现(implements)很多接口
难道一个一个向上看,看到最顶层,然后从顶层开始向下学习么?
笔者也想过用这种方式,刚看了几分钟就觉得不对,原因如下:
- java虽然是单根继承体系,但是允许多接口实现;
- java的设计根类是Object,但是根接口有很多;
- java中很多类的设计是网状的,并非一个单根树结构;
- java中很的接口可能又有很多子接口,孙子接口,光看接口,非常疲乏;
所以,看java,要从一个常用的工具开始看,
这个工具一定是一个具体的实现类,而并非抽象类,并非是接口。
从一个点开始,向上开始展开。同时这个类最好不是jvm底层有运算符相关的
(如String类的设计不建议最开始就看)
4.看源码有什么用?
这个问题看起来好像和为什么看源码是一个意思,但是实际上要解释的是不同的内涵。
看源码,主要是看源码体现出的几个问题,他分为两个层次:
4.1.源码的构成模式
构成模式,是指从一个类开始看,了解这个类的构成。一般包括:
①类的继承体系
②类的实现体系
③类的成员变量
④类的构造器
⑤类的方法实现
在看类的构造器和方法实现的时候,会发现有些类的构造器是使用了父类构造器,或
加工了父类的构造器的。同理,类的方法实现,即时具体代码看不懂,也要知道这个
方法是做什么的,比如入参,出参,加工逻辑,是否是继承,是否是父接口实现等。
4.2.源码的设计模式
看源码的继承体系和实现体系的时候,肯定会有一种不知所然的感觉,
“这个为啥要继承?”“这个为啥要那么多接口?”
当然,看的数量少,必定会有这种感觉。
而源码中的设计模式,实际上是妙不可言的,有些变量的命名,也是很走心的,
有些没有写在doc中的双斜杠注释,才是真的应该关心,在API中看不到的内容。
5.源码看完了怎么用?
看源码看jdk的原码(自己说的,自己打脸),实际上对jdk进行改动的人少之又少,虽然开源。
我们看源码,看完了,明白了其中的良苦用心,难道我们在使用这些工具的时候能玩出花来么?
也许根本做不到,美丽花朵夏天一场雨也许就掉光了。
我们会不用jdk设计好的基类,而是在其基础上进行扩展么?好像也不会。
实际上jdk的设计模式,是我们开发模式的抽象集成。如:
如何把控类的边界?
如何把控类的扩展性?
如何提高类的可维护性?
如何提高类的健壮性?
如何进行代码重构?
难道架构师真的是个满嘴跑火车号令群猿的人而已么?
难道接口工程师只是命名写注释么?
难道开发工程师拿到固定需求是随便写类的么?
如果一个大型的研发体系中,没有人懂源码,没有人懂架构,哦~呵呵~
这必将影响这个研发项目产出产品的生命周期了。
怎么用,取决于个人,看多深,也取决于个人,也许看到了一个新奇的代码很是喜欢呢。
理论就说这些,之后将一个一个拆,对于源码的体系,进行慢慢的剖析。
我也不知道会更多久,会不会更下去,坚持一点是一点吧。
6.已更列表:
以上!