这是why的第 85 篇原创文章
写中间件经常要做两件事:
- 1.延迟加载,在内存缓存已加载项。
- 2.统计调用次数,拦截并发量。
就这么个小功能,团队里的人十有八九写错。
上面这句话不是我说的,是梁飞在他的博客里面说的。
梁飞是谁?
据网上的公开资料,梁飞,花名虚极。
2009 年加入阿里巴巴,负责中间件的开发,Dubbo 开源分布式服务框架作者,HTTL 开源模板引擎作者。
2012 年加入天猫,负责手机天猫 APP 的技术团队,见证了天猫双 11 无线化全过程。
热衷参与开源社区建设,传播服务化、SOA、框架设计、移动应用等架构设计理念。
下面这段是我在他的个人博客里面找到的:
https://www.iteye.com/blog/javatar-287026
上周五去杭州面试,早上飞过去,晚上飞回来,有点匆忙,飞机晚点,到那边的时候都快下午一点了,面试了一个小时左右,主要是笔试没做了,省了不少时间。
面试完后,跟着几个熟人转了一圈,学习交流气氛都很好。
周二收到了Offer,看来HR效率很高,赞一个,定的是1月8号入职。
这两天忙于提交辞职申请,就要离开奋斗了近三年的公司,还是有点不舍,公司给了我很多发展机会,领导们对我也特别好,真的很感谢他们。
只是现在新的公司发展机遇更好,我不想放弃,希望在新的岗位上能做得更好,呵呵,流水帐记到这里。
这篇博客,发布于 2008 年 12 月 24 日。
他说的上周五,也就是 2008 年 12 月 19 日。一天之内,从深圳飞到杭州,面试一小时,又从杭州飞回深圳,4 天之后,收到了阿里的 offer。
彼时,梁飞也仅从湖南科技职院软件学院的大门走出来不到 3 年的时间。
文章里面说的“1 月 8 号入职”,也就是 2009 年的 1 月 8 日。
从此,在阿里开启了长达 12 年的升级打怪之路,从 P5 一路杀到了 P9。
众所周知,阿里能到 P9 ,已经不是能力的事儿了,这属于祖上积德。
而梁飞在 2016 年的时候就已经是 P9 了。
上面说的这么多标签,而他最为人熟知的标签应该是:Dubbo 创始人。
在梁飞加入阿里的 1015 天之后,也就是 2011 年 10 月 20 日 23 点 06 分,Dubbo 在开源社区发出了第一声啼鸣:
9 个模块,共计 669 个文件,就是日后这个一路坎坎坷坷、几近夭折、友商续命,最终成为 Apache 顶级开源项目的雏形。
2011 年 10 月 20 日那天晚上,对于梁飞来说注定是一个回忆起来,难以忘怀的夜晚。
他一直进行了13 次提交:
终于在第二天的早上 5 点 25 分给 Dubbo 打上了第一个 tag:2.0.7。
期间还抽空通知官媒发了个微博:
而他自己,第二天的中午,也在自己的博客上公布了这件事情:
为什么 Dubbo 会选在这一天进行开源呢?
我想应该是为了赶上两天之后的 Qcon 全球软件开发者大会:
那一天,才是 Dubbo 真正意义上,站在大众视野里,接受赞扬与嘲讽的开始。
我千辛万苦,找到了近 10 年前,那次大会的分享 PPT,开篇第一页:
十年过去了,白云苍狗,Dubbo 从阿里走了出来,已经真正的飞入寻常百姓家了。
十年间,PPT 上的数据,从总量上来看,就像双十一的销售额一样,不知道翻了多少个翻。
但是转念一想,这是 10 年前的阿里,每天 10 亿次的调用,这是多少技术人一生也接触不到的流量啊。
同时,我在 PPT 里面也发现很多熟悉的图片,比如这张:
左边是现在的 Dubbo 官网,右边是 10 年前 Qcon 大会上的 PPT。
10 年过去了,当这两张图片同框的时候,不知道右边的“老图”,有没有一种老父亲般的欣慰。
如果说上面这个图你的感觉还不是特别的强烈,那么再看看这个:
左边是官网,右边是 PPT。
10 年过去了,整体设计没有发生一丝变化。
我不知道你看到这里的时候想到的是什么,于我而言,真牛逼啊。
一个 10 年前的整体设计,竟然在日新月异、风起云涌的互联网行业一丝不变的屹立了下来。
这是一群工程师智慧的结晶。
Dubbo 第一次面世的 PPT 有 55 页,里面有很多设计从十年后的今天看去也不过时。
我就不一一展示了,有兴趣的朋友,在文末可以看到获取方式。
最后,献上一张最早的 Dubbo 团队的合照:
还记得本文开篇的那句话吗?
https://www.iteye.com/blog/javatar-1963774
这里的 PPT 链接失效了,我历尽千辛万苦,搜索找到了一份。
一共 18 页,一一展示一下。
有的地方是纯知识点,有的地方是代码。
反正我觉得我看明白了,有必要讲一下的地方。我就在图片下面进行一个简短的描述。
走起。
稍微解释一下这一页上面的东西。
这几个命令,我在之前的文章中也用到过:
一个困扰我122天的技术问题,我好像知道答案了。
就是下面这部分:
所以,我知道这个地方是有个坑的。
如果你把命令直接粘过去,会抛出这个错误:
Java HotSpot(TM) 64-Bit Server VM warning: printing of assembly code is enabled; turning on DebugNonSafepoints to gain additional output
是因为你缺少了一个叫做 hsdis-amd64.dll 的文件(windows平台)。
你需要把这个文件放在 jre/bin/server 的目录下:
然后把命令换成这个:
-XX:+UnlockDiagnosticVMOptions
-XX:+PrintAssembly
-XX:CompileCommand=print,*AtomicInteger.incrementAndGet
再次执行程序,就有汇编输出了:
再主要说一下 CompileCommand 这个参数。
这个参数用来定制编译需求,比如可以指定某个方法不做 JIT 编译,也可以只编译指定的方法等等。
用法是这样的:
-XX:CompileCommand=command,method[,option]
其中的 command 有下面这些选项:
- exclude,跳过编译指定的方法
- compileonly,只编译指定的方法
- inline/dontinline,设置是否内联指定方法
- print,打印生成的汇编代码
- break,JVM以debug模式运行时,在方法编译开始处设置断点
- quiet,不打印在此命令之后、通过-XX:CompileCommand指定的编译选项
- log,记录指定方法的编译日志,若未指定,则记录所有方法的编译日志
- 其他命令,option,help
比如 PPT 中的这个用法 -XX:CompileCommand=print,*AtomicInteger.incrementAndGet
含有就是打印 AtomicInteger.incrementAndGet 方法生成的汇编代码。
缓冲行对齐,这个应该是一个需要掌握的知识点,属于关于程序优化的奇技淫巧。
偶现于面试环节。
对齐的目的是为了解决伪共享(False Sharing)的发生。
不知道伪共享的朋友,建议去了解一下。
PPT 中的例子的源码来源是:
com.google.code.yanf4j.util.LinkedTransferQueue.PaddedAtomicReference
需要注意的是,在 Java8 里面,提供了更加优雅的解决方案:@Contented 注解。
这个也是一个非常经典的、关于单例模式的演变过程。
PPT 上一共四个单例模式的写法,我们一个个的看。
这就是我们耳熟能详的饿汉式单例。通过提前初始化的方式,解决了并发问题,保证了单例性。
这里面最关键的就是 final static 关键字。
作者也用了蓝色做以区分,肯定是有深意的。
来,一起背一遍类的加载过程:
加载、验证、准备、解析、初始化。
比如下面这个例子:
public static int value =123
变量 value,只有 static 修饰,那么该变量在准备阶段被赋上初始值,即 0。
在初始化阶段被赋上 123。
但是当再多一个 final 修饰的时候:
public final static int value =123
value 变量在准备阶段就会被赋上 123。
所以,你想想上面的饿汉式,是不是一个道理?
而这一方面的知识点,在《深入理解Java虚拟机》一书里面,写的还是很清楚的。
但是饿汉式有一个明显的劣势,那就是不管应用程序是否使用,都会被初始化出来。
这样并不优雅。
于是,就到了第二段程序,饱汉式。
在需要使用的时候,才进行初始化操作。
但是怎么保证线程安全呢?
通过在方法上加 synchronized 关键字的方式来保证了线程安全?
但是这个玩意真的安全吗?
这可能是面试官最喜欢问的问题之一吧。
要是你之前不知道,也许打死你也想不到还有拿到一个只初始化了一半的对象的情况。
简单来说就是 new Singleton()
不是原子性的,所以会导致 if 条件满足时,instance 并没有完全初始化。
于是就引出了下面这段程序:
传说中的双重检查加锁。
而这段程序最容易被“忽视”的就是 volatile 关键字了。
如果没有 volatile 关键字,那么这个程序也是废的。
还有,需要注意的是梁飞在这里备注了一个 jdk1.5+
。
为什么呢?
其实答案就写在《Java并发编程实战》的第 287 页:
在这本书里面,形容双重检查加锁的成语是:声名狼藉。
而且在图片里面可以看到:促使该模式出现的驱动力已经不复存在,并不是一种高效的优化措施。
现在,我觉得双重检查加锁主要还是应用在面试环节。
明明就不是一种高效的优化措施,却还是一个高频考点,为什么呢?
还不是八股文害人啊。
接下来说最后一种,也是作者推崇的方式:
这个骚操作的学名叫做“基于类初始化的单例模式解决方案”。
JVM 在 Class 被加载后,且被线程使用之前,也就是类的初始化阶段,会去获取一个锁。
这个锁可以保证多个线程对同一个类进行初始化时,只有一个线程能初始化成功。
而该方法的原理在《Java并发编程的艺术》一书的 3.8.4 章节解释的非常清楚。
什么?这两本书你都没有?
赶紧去搞一本吧,写的还是挺好的,我以前多次推荐过。
额......
这页我也没看明白。
我觉得肯定是有一个上下文的,只是梁飞没有写在 PPT 里面。
导致我看的云里雾里的。
这里只写到了 CountDownLatch 和 CyclicBarrier 。
其实还有一个很重要的、很常用的、工具类:Semaphore。
如果不知道,可以看看这篇文章:
我靠!Semaphore里面居然有这么一个大坑!
如果你上面三个都不知道。
赶!紧!去!学!
打印出来,贴在电脑旁边,朗读并背诵本页。
文中提到的两个 PPT 和一个文件:
- 阿里巴巴(B2B)的服务框架探索.ppt
- Java并发编程常识.ppt
- hsdis-amd64.dll
关注公众号【why技术】,然后在后台回复关键字【ppt】即可获得。
才疏学浅,难免会有纰漏,如果你发现了错误的地方,可以在后台提出来,我对其加以修改。 感谢您的阅读,我坚持原创,十分欢迎并感谢您的关注。
我是 why,一个主要写代码,经常写文章,偶尔拍视频的程序猿。