java 并发多线程 锁的分类概念介绍 多线程下篇（二）
接下来对锁的概念再次进行深入的介绍之前反复的提到锁，通常的理解就是，锁---互斥---同步---阻塞
其实这是常用的独占锁（排它锁）的概念，也是一种简单粗暴的解决方案
抗战电影中，经常出现为了阻止日本人炸桥？炸路？的场景，这只是阻止日本人的一种手段，如果大喊一声TMD滚蛋，日本人就走了，还炸桥干嘛？
**用锁是为了线程安全，而不是为了上锁，上锁是一种途径，独占锁则是“上锁”的其中一种形式**
如果有更优雅的上锁方式，自然不必要每次都简单粗暴的使用独占锁，不是嘛
从几个维度可以大致分为下面几种
分类是以锁为核心，而延展出来的优雅的使用方式
!(data/attachment/forum/202207/17/224334zfcj6upc3c67cjcp.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/300 "image.png")
### 乐观锁与悲观锁
* 乐观就像小米的宣传语-永远相信，美好的事情即将发生；
* 而悲观就像透过有色眼睛看世界，永远都带有颜色；
对应到程序中
**使用锁是为了什么？因为线程之间会共享数据，共享数据就一定会出现问题吗？当然是概率的**
* 两个人去同一个水井打水，如果每次都错开，那么美好一直存在
* 如果天天赶到同一个时间点，我相信早晚必有一战.....
所以如何看待在多线程共享数据中，出现的概率性竞争问题？
* 乐观的眼光就是坚信绝大多数时候是没问题的，只需要最后发生修改或者操作时进行校验，比如校验是否被修改过，然后再去进一步处理
* 悲观的眼光就是坚信肯定会有问题，所以我就一直加锁，只要一直锁住反正肯定不会出现问题
所以你看，乐观锁其实可以并没有锁，是在逻辑上实现了锁的业务
假设这样一种比较极端的场景
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**
比如人类都是人，但是分为男人、女人，还可以分为好人、坏人等，好人有男女，坏人也有男女
比如独占锁属于悲观锁，独占就是要保障同一时间只有一个线程操作，其他线程必须等待
共享锁就属于乐观锁，因为他放宽了加锁的条件
理解锁的分类有助于后续关于其他高级工具、类的理解与学习
!(data/attachment/forum/202206/16/141330jha7st9soow8772i.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/300 "common_log.png")
`转载务必注明出处：程序员潇然，疯狂的字节X，https://crazybytex.com/thread-81-1-1.html `
页:
[1]