🚩乐观锁和悲观锁

 这两种锁是站在加锁解锁的角度看待的,看的是加锁解锁的过程中所干的活是多还是少

悲观和乐观是对后续锁冲突是否激烈(频繁)给出的预测。

• 如果预测接下来锁冲突的概率不大，就可以少做一些工作，就称为 乐观锁
• 如果预测接下来锁冲突的概率很大，就应该多做一些工作，就称为 悲观锁

悲观锁： 总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。

举个例子：

同学 A 认为 " 老师是比较忙的 , 我来问问题 , 老师不一定有空解答 ". 因此同学 A 会先给老师发消息 : " 老师你忙嘛? 我下午两点能来找你问个问题嘛 ?" ( 相当于加锁操作 ) 得到肯定的答复之后 , 才会真的来问问题 .如果得到了否定的答复, 那就等一段时间 , 下次再来和老师确定时间 . 这个是悲观锁。

乐观锁： 假设数据一般情况下不会产生并发冲突，所以在数据进行提交更新的时候，才会正式对数据是否产生并 发冲突进行检测，如果发现并发冲突了，则让返回用户错误的信息，让用户决定如何去做。

举个例子:

同学 B 认为 " 老师是比较闲的 , 我来问问题 , 老师大概率是有空解答的 ". 因此同学 B 直接就来找老师 .( 没加锁, 直接访问资源 ) 如果老师确实比较闲 , 那么直接问题就解决了 . 如果老师这会确实很忙 , 那么同学 B也不会打扰老师, 就下次再来 ( 虽然没加锁 , 但是能识别出数据访问冲突 ). 这个是乐观锁。

这两种思路不能说谁优谁劣, 而是看当前的场景是否合适.

• 如果当前老师确实比较忙, 那么使用悲观锁的策略更合适, 使用乐观锁会导致 "白跑很多趟", 耗费额外的资源。
• 如果当前老师确实比较闲, 那么使用乐观锁的策略更合适, 使用悲观锁会让效率比较低.

Synchronized 初始使用乐观锁策略. 当发现锁竞争比较频繁的时候, 就会自动切换成悲观锁策略.

就好比同学 C 开始认为 "老师比较闲的", 问问题都会直接去找老师.

但是直接来找两次老师之后, 发现老师都挺忙的, 于是下次再来问问题, 就先发个消息问问老师忙不忙, 再决定是否来问问题。

读写锁:

• Ⅰ:加读锁
•  Ⅱ:加写锁

普通互斥锁:就如同Synchronized,当两个线程竞争同一把锁的时候就会产生阻塞等待。synchronize不是读写锁，只是普通互斥锁。

多个线程同时读一个变量并没有问题,而且读的场景相比于写的场景就多了很多,使用读写锁相比于普通互斥锁就减少了很多的锁竞争,大大的优化了效率。(因为我们上述说明了，读写锁在读锁和读锁之间不会产生竞争）

---

🚩轻量级锁和重量级锁

• 轻量级锁的加锁解锁开销比较少,典型的是纯用户态的加锁解锁逻辑,开销是比较少的
• 重量级锁的加锁解锁开销比较大,典型的是进入了系统内核态的加锁解锁逻辑,开销是比较大的

这两种锁是站在结果的角度看待最终加锁解锁消耗的时间是多还是少,和乐观锁与悲观锁并不一样通常情况下乐观锁比较轻量,悲观锁比较重量,但是也并不绝对。

---

🚩自旋锁和挂起等待锁

• 自旋锁:相当于是"忙等"的状态,大量消耗的CPU资源,反复询问当前锁是否就绪。
• 挂起等待锁:先把CPU资源空闲出来去做其他的事情,过一段时间才询问当前锁是否就绪。

自旋锁：

按之前的方式，线程在抢锁失败后进入阻塞状态，放弃 CPU ，需要过很久才能再次被调度 .

但实际上 , 大部分情况下，虽然当前抢锁失败，但过不了很久，锁就会被释放。没必要就放弃 CPU. 这个时候就可以使用自旋锁来处理这样的问题。

自旋锁伪代码:

while (抢锁(lock) == 失败) {}

如果获取锁失败 , 立即再尝试获取锁 , 无限循环 , 直到获取到锁为止 . 第一次获取锁失败 , 第二次的尝试会在极短的时间内到来. 一旦锁被其他线程释放, 就能第一时间获取到锁 .

理解自旋锁 vs 挂起等待锁

举个例子：

在我们等人的时候，对方还没有到达约定的地点，一直反复的打电话催促就是自旋锁，而当你发现对方还没到的时候，就在约定的地方找个地方玩手机，叫他来了再在约定的地点旁边找我们一下，多消耗一点时间，却能够用这些时间去做其他的事情，时间被利用起来了，这就是挂起等待锁。

自旋锁是轻量级锁的一种体现,挂起等待锁是重量级锁的一种体现。

---

---

🚩公平锁和非公平锁

• 公平锁:公平锁是先来后到,谁先来谁就拿到锁
• 非公平锁:多个线程同时竞争一把锁,有一个线程是比较晚来的,却比其他先来的线程先拿到锁

举个例子:

• t1,t2,t3三个线程竞争同一把锁,t1先来的,所以t1先拿到了锁,这就叫公平锁.
• 而如果t3是晚来的,然后t3比其他两个线程先拿到了锁,这就叫非公平锁

操作系统默认的锁的调度,是非公平的情况，想要实现一个公平锁,就需要引入额外的数据结构,来记录线程加锁的顺序,需要一定的额外开销。

公平锁和非公平锁没有好坏之分 , 关键还是看适用场景 .

synchronized 是非公平锁 .

---

🚩可重入锁和不可重入锁

• 可重入锁的字面意思是“可以重新进入的锁”，即允许同一个线程多次获取同一把锁。
• 比如一个递归函数里有加锁操作，递归过程中这个锁会阻塞自己吗？如果不会，那么这个锁就是可重入锁（因为这个原因可重入锁也叫做递归锁）。

可重入锁:同一个线程对同一把锁连续加锁两次不会造成死锁

不可重入锁:同一个线程对同一把锁连续加锁两次会造成死锁

理解 "把自己锁死"

一个线程没有释放锁, 然后又尝试再次加锁.

// 第一次加锁, 加锁成功
lock();
// 第二次加锁, 锁已经被占用, 阻塞等待. 
lock();

按照之前对于锁的设定, 第二次加锁的时候, 就会阻塞等待. 直到第一次的锁被释放, 才能获取到第二个锁. 但是释放第一个锁也是由该线程来完成, 结果这个线程已经躺平了, 啥都不想干了, 也就无法进行解锁操作. 这时候就会 死锁。

这样的锁称为 不可重入锁.

synchronized 是可重入锁 （因为我们之前在synchronized中说到了死锁，一个线程，连续针对一把锁，加锁两次，不会出现 死锁 ）但是俩个线程俩把锁， 线程t1获取锁A，t2线程获取锁,B 线程t1获取锁B，t2线程获取锁A.这样大概率是会导致死锁现象。