如何把握编程世界的那把锁

1.共享变量惹得祸

创新互联是一家朝气蓬勃的网站建设公司。公司专注于为企业提供信息化建设解决方案。从事网站开发，网站制作，网站设计，网站模板，微信公众号开发，软件开发，微信平台小程序开发，十多年建站对成都橡塑保温等多个行业，拥有丰富建站经验。

我们这里是个典型的弱肉强食的世界，人口多而资源少，为了争抢有限的资源，大家都在自己能运行的CPU时间片里拼了老命，经常为了一个变量的修改而打的头破血流。

100纳秒以前，我有幸占据了CPU，从内存中读取了一个变量x == 100, 我把它加了1，休息了一会儿后我打算把它写回内存，但是惊奇的发现：内存中的x 已经变成102了。

估计是哪个不着调的线程在我休息的时候也读取并且修改了x，有不少好心的线程在冲我喊：不要写回了! 但是写回内存是我的指令啊，你不让我执行，难道让我退出? 我只能毫不客气的把101写入内存，把那个不符合我逻辑的值102给覆盖掉，这样我才能执行下一条指令。

你看，单线程的逻辑正确并不表示多线程并发运行时的逻辑也能正确。

这样的事情发生的多了，程序总是无法正确运行，引起了人类的强烈不满，小道消息说他们在考虑kill掉我们，换编程语言了。

但是换编程语言有什么用，只要有共享变量，多线程读写的时候就是会出现不一致啊。

除非你消除共享变量，让每个线程只访问一个函数内的局部变量，这些局部变量我们每个线程都会有一份，函数结束以后就会销毁，所以线程之间就隔离了，就安全了。

消除共享变量谈何容易，人类使用的很多语言例如C++, Java，那些共享变量大多数一个对象的字段，你想把字段去掉，只留下函数，那类也没有存在的必要了，就类似于函数式编程了，一切都是函数。有时候我挺羡慕函数式的世界，那种无状态应该是一种非常美妙的感觉吧。

2.争抢吧，线程

既然共享变量是无法消除的，那就想想别的办法吧，线程元老院的那帮家伙们哼哧了半天，终于公布了一个方案：加锁！

任何线程，只要你想操作一个共享变量，对不起，先去申请一把锁，拿到这把锁才能读取x的值，修改x的值，把x写回内存， ***释放锁，让别人去玩。

元老院设计的这把锁非常简单，类似于一个boolean 变量， boolean lock = false. 谁能抢先把这个变量改成true, 就意味着获取了这把锁。

来吧，哥几个，快来抢吧 !

我运行的时候，就去检查lock这个变量是否可以设置为true, 如果被别的家伙给抢到了(已经变成true了)，我就在这里***循环，拼命的抢，除非我的时间片到了，被迫让出CPU, 但是我不会阻塞，还是就绪状态，等待下一次的调度，进入CPU继续抢。

看到某人把它变成false, 我眼疾手快迅速出手，终于抢到了，赶紧把lock改成true, 这把锁现在属于我了，赶快去干活，干完活要记住把lock 改成false, 让别的家伙们去抢。

我想正是由于这种***循环的特点，元老院把他命名为“自旋锁”吧!

列位看官，可能你已经想到了，假设有两个线程，都读到了lock == false, 都把lock 改成true, 那这个锁算谁的?

这个问题元老院的大佬们早就考虑到了，他们和操作系统(我听说还有硬件)都商量好了，这个检测lock是否为false, 以及设置lock 为true 的操作其实被合并了，叫做test_and_set(lock), 操作系统郑重承诺，这是一个不可分割的原子操作，在这个test_and_set执行的时候，总线都被锁住了，别人不能访问内存，即使有多个CPU在执行也不会乱掉。

如果你感兴趣，可以看看下面的实现，否则直接无视跳过：

3.改进

有了自旋锁，至少可以保证程序的正确运行了，我们大家都玩的不亦乐乎。

有一天我遇到了一个递归函数，我是挺喜欢递归的，因为逻辑简单，只要递归的层次别太深，别搞出栈溢出就好。

这个递归函数中需要获得自旋锁，做点事情，然后继续调用自己，类似于这样：

我***次调用doSomething, 获取了自旋锁，然后第二次调用doSomething, 还要获取自旋锁，可是这个锁已经在我***次调用的时候持有了，现在第二次调用只有***的等待了!

这下尴尬了，我进退不得，自己把自己搞成了死锁!

看来这个自旋锁虽然能实现互斥的访问，但是不能重新进入同一个函数(简称不可重入)啊!

我赶紧把这个问题向元老院做了汇报，修改方案很快就下来了：每次成功的申请锁以后，要记录下到底是谁申请的，还要用一个计数器记录重入的次数，下一次持有锁的家伙再次申请锁只是给计数器加一而已。

释放的时候也是一样，把计数器减一，如果等于0了才真正的释放锁。

可重入性就这么解决了，但是这么多线程都在那里拼命的抢也不是办法，空耗CPU也是巨大的浪费啊。

于是元老院又发布了新的锁 ReentrantLock，这个锁可以重入，如果你抢不到，不要***循环了，乖乖的到等待队列里待着去，等到锁被别人释放了再通知你去抢。(在Java 中最初是synchronzied关键字，可以用在一个方法上或者一个代码块上，后来又改进为更加灵活的ReentrantLock)

很快就有线程还抱怨说，明明是我先发出获得锁的申请啊，为什么隔壁老王却先拿到了锁? 这不公平啊，不行，以后得排队，先来先得。好吧，只好加上一个是否公平的参数。

还有线程说，我是个急性子，申请锁的时候只想等待5秒钟， 5秒之内得不到锁我就放弃了，能不能支持? 那就再加上一个参数：等待时间。

4.发扬光大

体会到锁带来的甜头以后，各种各样样的需求纷至沓来：

（1）有时候需要多个线程都获得同一把锁，去做一件事情，那怎么办呢?

没关系，信号量(Semaphore)出马，创建信号量的时候得指定一个整数(例如10)，表明同一时刻最多有10个线程可以获得锁：

Semaphore lock= new Semaphore(10);

当然每个线程都需要调用lock.aquire(), lock.release()去申请/释放锁。

（2）一个线程要写共享变量，可是还有几个线程要同时读，怎么办? 你写的时候可以锁住，但总不能读的时候也只允许一个线程吧?

只好来一个读写锁了ReadWriteLock，为了保证可重入性，元老院体贴的实现了ReentrantReadWriteLock。

（3）一个线程需要等待其他多个线程完工以后才能干活，怎么办?

CountDownLatch前来救驾，搞一个计数器，某个线程干完了就把计数器减去1，如果计数器为0了，那个一直耐心等待的线程就可以开始了。

（4）还有几个线程必须互相等待，就像100米赛跑那样，所有人都准备好了才能开闸放水，不，是起跑，就那就赏你一个CyclicBarrier吧。

【本文为专栏作者“刘欣”的原创稿件，转载请通过作者微信公众号coderising获取授权】

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：创新互联

猜你还喜欢下面的内容