noteless 头像

java 并发多线程 锁的分类概念介绍 多线程下篇(二)

接下来对锁的概念再次进行深入的介绍
之前反复的提到锁,通常的理解就是,锁---互斥---同步---阻塞
其实这是常用的独占锁(排它锁)的概念,也是一种简单粗暴的解决方案
抗战电影中,经常出现为了阻止日本人炸桥?炸路?的场景,这只是阻止日本人的一种手段,如果大喊一声TMD滚蛋,日本人就走了,还炸桥干嘛?
用锁是为了线程安全,而不是为了上锁,上锁是一种途径,独占锁则是“上锁”的其中一种形式
如果有更优雅的上锁方式,自然不必要每次都简单粗暴的使用独占锁,不是嘛
 
从几个维度可以大致分为下面几种
分类是以锁为核心,而延展出来的优雅的使用方式
image_5c7f1e9b_3c8d

乐观锁与悲观锁

  • 乐观就像小米的宣传语-永远相信,美好的事情即将发生;
  • 而悲观就像透过有色眼睛看世界,永远都带有颜色;
对应到程序中
使用锁是为了什么?因为线程之间会共享数据,共享数据就一定会出现问题吗?当然是概率的
  • 两个人去同一个水井打水,如果每次都错开,那么美好一直存在
  • 如果天天赶到同一个时间点,我相信早晚必有一战.....
所以如何看待在多线程共享数据中,出现的概率性竞争问题?
  • 乐观的眼光就是坚信绝大多数时候是没问题的,只需要最后发生修改或者操作时进行校验,比如校验是否被修改过,然后再去进一步处理
  • 悲观的眼光就是坚信肯定会有问题,所以我就一直加锁,只要一直锁住反正肯定不会出现问题
所以你看,乐观锁其实可以并没有锁,是在逻辑上实现了锁的业务
假设这样一种比较极端的场景
A,B两个线程,共享数据c
A线程每分钟都会对c进行操作(一天24*60次),B每天都会对c进行一次操作
试想一下乐观锁和悲观锁之间的性能差异?
在这个场景中可以认为即使没有任何防范措施,每天正确的概率也会大于99.9%(不考虑一次错误后导致的后续连锁错误),如果选用悲观锁,将会有多少无谓的损耗?
synchronized就是悲观锁,他会为你保障百分百的加锁与同步

公平锁与非公平锁

公平与非公平的字面意思大家都很清晰,没有人理解起来有难度
比如语文老师对你和同桌的态度一视同仁、比如领导对你和同事的年终你觉得不公平....
但是,对于锁来说,这个公平与不公平针对的是什么?
之前在监视器概念中提到的,线程如果在某个监视器的等待集合中,那么如果当前线程执行结束后,谁应该被选作下一个进入监视器的线程呢?
这就是锁的公平性针对的点
  • 对于锁的请求,每个线程总是有一个先来后到的先后顺序,如果按照先后顺序,那么就是公平锁
  • 如果不按照先后顺序,随机的或者按照什么算法优先级等选择,那么就是非公平锁
除非有额外的公平性要求,否则不应该使用公平锁,因为对性能是有损耗的

独占锁和共享锁

  • 如果一个锁仅仅只能被一个进程拥有,那么他就是独占的;
  • 如果一个锁可以同时被多个线程拥有,那么他就是共享的;
独占锁会保障任何时候都只是有一个线程进行访问,ReentrantLock就是独占锁,synchronized的原理也是独占锁
而读写锁ReadWriteLock就是共享锁,可以同时允许多个读线程进行操作

可重入锁

重入,就好像是你结账后餐馆老板对你说的下次再来!
当一个线程想要获取一个被其他线程独占的锁时,你需要等待,但是如果是自己已经获得的锁呢?
答案是你可以多次获取,这就是可重入
比如一个类中有两个同步的实例方法,而锁对象都是当前对象this
如果不可重入会发生什么?
调用了A方法之后,想要调用方法B但是锁却被自己占有了,如果不可重入,就成了自己等自己,岂不是傻子?
可重入锁在内部维护了一个计数器,用于记录重入次数
自己获得一次,那么计数器+1,释放一次计数器-1,如果计数器为0,说明该线程释放了该锁,否则,锁仍旧被该线程持有

自旋锁

在之前线程简介中有提到,Java线程是内核级映射的线程(1.2吧?之后)
如果一个线程请求获取一个锁时,并不能获取到,那么将会进入阻塞状态,也就是会被切换到内核态然后挂起
当该线程获取到锁时,又需要切换到内核状态进行唤醒,说白了需要用户状态与内核状态的切换
而且,这个状态的切换,还是比较消耗性能的
怎么办?
有一种解决办法就是线程继续运行,过一会儿再次尝试锁的获取
怎么做到的?
其实就是相当于CPU空跑,而不是直接将线程进行挂起
所以说相当于牺牲了CPU的时间片,换取内核状态的开销,这就涉及到一个平衡点的问题
如果线程之间竞争不激烈,可能下次的尝试获取就成功了
但是如果线程之间竞争非常激烈,下次还是抢不到,下下次还是抢不到......会发生什么情况?
那就是浪费了太多的CPU时间片,而且,你也不能永远的像“死循环”一样尝试呀,所以一般会有一个时长或者次数,总之有个上限
现在对自旋锁应该有了一定的了解了,自旋就是自己在那边不停地打转,不给糖吃就打滚的哭
书面点的说法:
当前线程获取锁时,如果发现锁已经被其他线程占有,并不会马上阻塞自己,在不放弃CPU的情况下,多次尝试
刚才也说明了,对于线程是否竞争激烈,自旋锁有着不同的反应,也说不定会导致CPU白白浪费了时间片,所以要根据业务来

适应性自旋

刚才说到,对于自旋不能无止境的,那就是类似“死循环”,所以都有限制,通常用次数,比如规定次数为5
但是实际情况中,可能有时经常1次就能够成功,也可能经常5次了还没有成功,如果1次就成功的还好,如果说限制为5次,每次都5次后还是失败,这就是纯粹的白忙活
所以后来出现了自适应的自旋锁,自旋的次数(限制)不再是固定的了
  • 如果对于某个锁,自旋很少成功获得过,那在以后尝试获取这个锁时将可能省略掉自旋过程,直接阻塞线程,避免浪费处理器资源
  • 如果对于某个锁,自旋等待刚刚成功获得过锁,那么将会认为这次也很可能是成功的,所以将会允许自旋,甚至允许更多次数(时间)的自旋等待
对于适应性自旋,大致逻辑是这样,具体细节由具体算法决定
再次强调
对于自旋,表面上看是减少了阻塞的发生,进而可以减少状态切换的性能损耗,但是这是以浪费CPU为代价的
所以并不能认为自旋锁是治疗百病的良药
实际使用中,不能只看到带来的好处,也需要关注付出的代价,而对于适应性自旋,只是对于自旋的“死板”的一种调优而已

小结

以上分类只是就某一个维度对锁的概念以及应用的分析
他们概念上不是完全隔离的,不是说就存在那么几种锁,A,B,C....A就是A,B就是B
比如人类都是人,但是分为男人、女人,还可以分为好人、坏人等,好人有男女,坏人也有男女
比如独占锁属于悲观锁,独占就是要保障同一时间只有一个线程操作,其他线程必须等待
共享锁就属于乐观锁,因为他放宽了加锁的条件
理解锁的分类有助于后续关于其他高级工具、类的理解与学习
posted @ 2019-03-07 10:51  noteless  阅读(1589)  评论(1编辑  收藏  举报