侧边栏壁纸
博主头像
why

一个主要敲代码,经常怼文章,偶尔拍视频的成都人。

  • 累计撰写 181 篇文章
  • 累计创建 11 个标签
  • 累计收到 88 条评论

Java并发编程常识

why
why
2021-01-25 / 0 评论 / 0 点赞 / 195 阅读 / 4,357 字
温馨提示:
关注公众号why技术,第一时间接收最新文章。

写中间件经常要做两件事:

  • 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里面居然有这么一个大坑!

如果你上面三个都不知道。

赶!紧!去!学!

打印出来,贴在电脑旁边,朗读并背诵本页。

最后说一句

文中提到的两个 PPT 和一个文件:

  • 阿里巴巴(B2B)的服务框架探索.ppt
  • Java并发编程常识.ppt
  • hsdis-amd64.dll

关注公众号【why技术】,然后在后台回复关键字【ppt】即可获得。

写文章很累的,需要一点正反馈。你的关注,就是强有力的正反馈!

才疏学浅,难免会有纰漏,如果你发现了错误的地方,还请你留言给我指出来,我对其加以修改。

抱拳了,铁子!

0

评论区