• 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
    比如人类都是人,但是分为男人、女人,还可以分为好人、坏人等,好人有男女,坏人也有男女
    比如独占锁属于悲观锁,独占就是要保障同一时间只有一个线程操作,其他线程必须等待
    共享锁就属于乐观锁,因为他放宽了加锁的条件
    理解锁的分类有助于后续关于其他高级工具、类的理解与学习
  • 相关阅读:
    敏捷开发读后感
    结对编程:电梯调度 (张恿、赵骞)
    软件工程 Individual Project
    [转]SQLServer 2008以上误操作数据库恢复方法——日志尾部备份
    下拉菜单demo---参考阿里云首页顶部下拉菜单
    走进spring之springmvc实战篇(二)
    剖析javascript全局变量和局部变量
    走进spring之springmvc实战篇(一)
    日常总结——JSP篇(补)
    我的程序员之路
  • 原文地址:https://www.cnblogs.com/noteless/p/10481218.html
Copyright © 2020-2023  润新知