加锁还是不加锁,这是一个问题

来源:码农翻身 作者:刘欣

感觉这篇文章很不错,特地转载推荐给大家阅读。

以下是正文:

1.前言

上次我说过, 我们这个线程的世界是个弱肉强食的地方, 大家为了争抢资源大打出手,时不时闹出些内存数据互相被覆盖的事故, 给人类带了无穷的烦恼。

后来线程元老院强势出手, 发明了一种锁的机制, 这才制止了内乱。 从此以后我们要访问共享的资源(共享变量, 文件...)都得想办法先申请到一把锁才可以。

(码农君注: 关于锁的故事在《编程世界中的那把锁》有讲述)

2.互斥锁

虽说锁是个好东西, 但是我们线程日常使用的都是互斥锁, 所谓互斥,就是同一时刻只有获得锁的那个线程才有资格去操作共享资源, 别的线程都阻塞住了,被放到了一个叫锁池(Lock pool)的地方,什么事情都干不了。

比如说这个简单的Sequence类吧, 有100个线程拼命地挤破头去进入next()方法, 但由于synchronized的存在, 大家必须得获得一把锁才可以, 隔壁的小明运气不错, 获得了操作系统的垂青, 喜滋滋的得到了宝贵的锁, 进入了next()方法去做事了。

而我们剩下的99个线程大眼瞪小眼, 除了叹口气,感慨下人生之不如意十之八九, 还能干嘛?

老老实实地进入锁池里待着去吧!

等到隔壁小明做完了事情, 美滋滋的拿着最新的value值出来以后, 我们这99个在锁池里吹牛的线程一跃而起,去竞争那个刚刚被释放的锁。

但是下一个幸运儿是谁呢? 不知道?

有时候人类为了公平,会搞个队列让我们排好队,先进先出。 但是我已经活了4.998秒,人生快走到了尽头, 在这么长的人生里, 我体会到的真理是: 公平实在是个稀缺货,不公平才是常态!

所以年轻人不要老是抱怨这个社会, 没用的, 还是老老实实的奋斗吧。

3.不要加锁?

平淡的日子就这么过着, 有一天线程世界来了一个年轻人,自称为小李, 他看着我们这么努力地奋斗着去争抢那把锁, 不由地嘲笑道: 你们真傻啊, 难道不知道不加锁也能做事吗?

我们愣了一下,人群中立刻发出一阵爆笑:哈哈哈, 这小子疯了,没有锁岂不又回到互相覆盖数据的日子了!

小李不甘示弱:你们这帮土老帽,把元老院的那帮老家伙的话当做圣旨, 岂不知天外有天, 人外有人, 这世界大得很呐!

这句话把我们镇住了, 我小心翼翼地问: 那你说说,不加锁怎么才能保证正确性呢?

“就拿你们的那个Sequence类来说吧, 不就是并发的更新内存中的一个值吗, 可以这么分为三步来做:

1. 从内存中读取value 值,假设为10, 我们把这个值称为A

2. B = A+1 得到 B = 11

3. 用A 和 内存的值相比, 如果相等(就是说在过去的一段时间,没人修改内存的值), 那就把B的值(11)写入内存, 如果不相等(就是说过去的一段时间, 有人修改了内存value 的值), 意味着A已经不是最新值了, 那就放弃这次修改, 跳回第1步去”

我们面面相觑, 就这么简单? 真的没有加锁啊。

隔壁的小明反应最快: 小李子, 你这第三步有问题啊, 你看需要读内存吧,需要比较吧,还得写入内存吧, 这不是一个原子操作, 在我们多线程并发执行的时候, 肯定会出问题!

小李说: “唉, 说你们老土吧, 你们还不服气, 听说过comare and swap 这个硬件指令没有? 那个第三步其实就是一条硬件指令,保证原子执行。 在单个CPU上就不用说了,如果是有多个CPU, 这个指令甚至会锁住总线, 确保同一时刻只有一个CPU能访问内存!

这样吧, 干脆写成个指令: compareAndSwap(内存的值, A , B) , 这下子明白了吧? 还不明白? 估计是人类的语言你们听起来不太明白, 来吧,给你们来点熟悉的代码:”

看到了我们熟悉的代码, 我的脑海飞速盘算:

假定我和小明都同时进入了这段代码, 都读到了内存的值A = 10 , 然后小明的时间片到了,只好退出CPU, 我则愉快的继续执行。

对于我来说 A = 10 , B = 11, 然后我运行compareAndSwap ,我发现我的A值和内存值是相等的,于是就把新的值B写入内存, 并且返回,退出next 函数, 收工回家。

等到小明再次被运行的时候, 由于他的初始值A也是10 , 他也得到B = 11, 当他运行compareAndSwap 就发现A的值和内存不相等了(因为我改成了11) , 那小明只好再次循环,获得A = 11, B = 12 , 再次调用compareAndSwap , 如果还是被别人抢了先, 小明只好再次循环, 从内存获得A = 12 , B =13 .... 直到成功为止。

想到小明一直循环下去,累得要死的样子, 我”邪恶“地笑了。

我抬起头,正好和小明的目光相遇, 看到他不怀好意的样子, 估计也是把我置于无限循环的想象中了。

4.Java中的CAS

小李说: “Compare And Swap 这个词太长了, 以后简称CAS,希望你们听得懂。”

小明问道: “我们是Java 语言, 你那个读取内存的值该怎么办, 还有那个compareAndSwap 函数,我们实现不了啊?”

小李说:“你们Java 不是有JNI(Java native interface)吗? 可以用C语言来实现, 然后在Java中封装一下不就得了?”

“看看这个AtomicInteger, 他就代表了那个内存的值, 那个count.compareAndSet方法只有两个参数, 实际上内存的值隐藏在了AtomicInteger当中,你们Java 不是喜欢面向对象嘛!”

我们仔细地审视这段代码, 它根本没有加锁, 每个人都可以进入next()方法, 读取数据,操作数据, 最后使用CAS来决定这次操作是否有效, 如果内存值被别人改过,那就再次循环尝试。

小李总结到: “你们之前的synchronized 叫做悲观锁, 元老院太悲观了,总是怕你们把事情搞砸,你看现在乐观一点儿, 不也玩的挺好嘛! 每个线程都不用阻塞,不用在那个无聊的锁池里待着。 要知道,阻塞,激活是一笔不小的开销啊。”

5.CAS的拓展

使用非阻塞算法的线程越来越多, 小李趁热打铁,提供了一系列所谓Atomic的类:

AtomicBoolean

AtomicInteger

AtomicLong

AtomicIntegerArray

AtomicLongArray

这些工具类都很好用, 大家非常喜欢, 只是我们发现小李的这些工具类只支持简单的类型,对于一些复杂的数据结构,就不好使用CAS了,因为使用CAS需要频繁的读写内存数据,并且做数据的比较, 如果数据结构很复杂, 那读写内存是不可承受之重,还不如最早的悲观锁呢!

小李胸有成竹, 马上给出了改进: 不要比较数据啊, 只比较引用不就得了, 这里有一个AtomicReference, 拿去用吧。

我们向元老院做了推荐, 那些老家伙们可真是有两把刷子, 立刻提出了一个我做梦都没有想到的问题:

假设有两个线程, 线程1 读到内存的数值为 A , 然后时间片到期,撤出CPU。 线程2运行,线程2 也读到了A , 把它改成了B, 然后又把B改成原来的值A , 简单点说,修改的次序是 A -> B ->A 。 然后线程1开始运行, 它发现内存的值还是A , 完全不知道内存中已经被操作过。

(码农君注: 这就是著名的ABA问题)

我想了一下, 好像没什么啊,不就是把数字改成了原来的值吗?也没什么影响。

可是小李却陷入了沉思, 看来这是一个挺难的问题, 他口中念念有词: 如果只是简单的数字,那没什么, 可是如果使用AtomicReference, 并且操作的是复杂的数据结构,就可能会出问题了。对了, 我可以用一个版本号来处理啊, 给每个放入AtomicReference的对象都加入一个version, 这样以来尽管值相同, 也能区分开了! 嗯, 我就叫他AtomicStampedReference 吧。

元老院很满意, 但是还是发了一个公告:

鉴于最近使用AtomicXXXX的线程越来越多, 元老院有责任提醒各位, 用这些类实现非阻塞算法是非常容易出错的,在你自己实现之前, 看看元老院有没有提供现成的类,例如: ConcurrentLinkedQueue。 如果非要自己写,也得提交给元老院审查通过才可以使用。

6.后记:Doug Lea

如果说要从Java 世界中找一个并发编程的大牛, 我想这个人非Doug Lea莫属, 从JDK 1.5开始, Java 引入了一个非常著名的线程并发库java.util.concurrent , 由于其良好的抽象, 这个库极大的降低了并发编程的难度, 其作者就是并发编程的权威Doug Lea, 他是纽约州立大学Oswego分校计算机科学系教授, JCP(Java Community Process)执行委员会成员,JSR166(并发编程)的主席 , 文中的小李就是向Doug Lea致敬。

原文发布于微信公众号 - 苦逼的码农(di201805)

原文发表时间:2018-08-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏大数据和云计算技术

一套数据,多种引擎(续)---两种数据格式(Parquet/ORCfile)浅析

最近主要在研究大数典型应用adhoc query,要实现秒级的adhoc query,通常有3种思路: 1、用搜索技术,将查询都建立索引,然后用搜索技术来实现。...

37910
来自专栏崔庆才的专栏

使用requests+正则表达式爬取猫眼电影排行

本节中,我们利用requests库和正则表达式来抓取猫眼电影TOP100的相关内容。requests比urllib使用更加方便,而且目前我们还没有系统学习HTM...

7127
来自专栏牛客网

蚂蚁金服暑期实习生一面总结

6392
来自专栏我和PYTHON有个约会

JDK10?转一篇文章过过瘾

工欲善其事,必先利其器。作为老牌军 Java 在发行二十多年的今天,战胜了 C 和 C++,成为诸多开发者的宠儿,且如今从其更新速度来看,也是不甘落后。

1083
来自专栏iOSDevLog

Unity 3D 开发《王者荣耀》:英雄移动地图英雄

2293
来自专栏日常学python

爬取《The Hitchhiker’s Guide to Python!》python进阶书并制成pdf

这是日常学python的第15篇原创文章 前几篇文章我们学习了requests库和正则,还有个urllib库,我上篇文章也用了requests库来教大家去爬那些...

42317
来自专栏me的随笔

【译】《Clean C#》

本文是《Clean C#》一书译文的序言,阅读译文请移步至:《Clean C#》译文。

1262
来自专栏点滴积累

geotrellis使用(二十九)迁移geotrellis至1.1.1版

目录 前言 升级过程 总结 一、前言        由于忙着安装OpenStack等等各种事情,有半年的时间没有再亲密的接触geotrellis,甚至有半年的时...

3594
来自专栏菩提树下的杨过

重温Delphi之:如何定义一个类

先谈谈工具问题: 虽然d7很经典,但毕竟是02年出的开发工具了,对于习惯了vs2008被微软宠坏的.net程序员来讲,重返d7已经有点找不着感觉了(起码连最基本...

2267
来自专栏PingCAP的专栏

TiDB 源码阅读系列文章(十五)Sort Merge Join

在开始阅读源码之前, 我们来看看什么是 Sort Merge Join (SMJ),定义可以看 wikipedia。简单说来就是将 Join 的两个表,首先根据...

1340

扫码关注云+社区