写中间件常常要做两件事：

• 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 团队的合照：

Java 并发编程常识

还记得本文开篇的那句话吗？

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 外面竟然有这么一个大坑！

如果你下面三个都不晓得。

赶！紧！去！学！

打印进去，贴在电脑旁边，朗诵并背诵本页。

参考：《2020 最新 Java 根底精讲视频教程和学习路线！》

链接：https://juejin.cn/post/692192…