JUC锁的总结

锁的分类：

• 乐观锁、悲观锁
• 独享锁、共享锁
• 公平锁、非公平锁
• 互斥锁、读写锁
• 可重入锁
• 锁升级(无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁)

1、乐观锁 & 悲观锁

乐观锁：乐观锁认为一个线程去拿数据的时候不会有其他线程对数据进行更改，所以不会上锁。

实现方式：CAS机制、版本号机制

悲观锁：悲观锁认为一个线程去拿数据时一定会有其他线程对数据进行更改。所以一个线程在拿数据的时候都会顺便加锁，这样别的线程此时想拿这个数据就会阻塞。效率相对较低。

例如：synchronized关键字，Lock

2、公平锁和非公平锁

公平锁：有多个线程按照申请锁的顺序来获取锁，就是说，如果一个线程组里面，能够保证每个线程都能拿到锁，例如：ReentrantLock（true）

非公平锁：获取锁的方式是随机的，保证不了每个线程都能拿到锁，会存在有的线程饿死，一直拿不到锁，例如：synchronized，ReentrantLock

总结：非公平锁性能高于公平锁，更能重复利用CPU的时间，ReentrantLock默认是非公平锁。

为什么会有公平锁、非公平锁的设计?为什么默认非公平？面试题

恢复挂起的线程到真正锁的获取还是有时间差的,从开发人员来看这个时间微乎其微,但是从CPU的角度来看,这个时间存在的还是很明显的,所以非公平锁能更充分的利用CPU的时间片,尽量减少CPU空闲状态时间。
使用多线程很重要的考量点是线程切换的开销,当采用非公平锁时,当一个线程请求锁获取同步状态,然后释放同步状态,因为不需要考虑是否还有前驱节点,所以刚释放锁的线程在此刻再次获取同步状态的概率就变得非常大了,所以就减少了线程的开销线程的开销。

什么时候用公平？什么时候用非公平？面试题

如果为了更高的吞吐量,很显然非公平锁是比较合适的,因为节省很多线程切换时间,吞吐量自然就上去了。否则那就用公平锁,大家公平使用。

原文链接：https://blog.csdn.net/TZ845195485/article/details/109398072

3、可重入锁和不可重入锁

可重入锁：也叫递归锁，在外层使用锁之后，在内层仍然可以使用，并且不会产生死锁

不可重入锁：在当前线程执行某个方法已经获取了该锁，那么在方法中尝试再次获取锁时，就会获取不到被阻塞

总结：可重入锁能一定程度的避免死锁，例如：synchronized，ReentrantLock

4、自旋锁（和CAS区分开）

自旋锁：一个线程在获取锁的时候，如果锁已经被其它线程获取，那么该线程将循环等待，然后不断的判断锁是否能够被成功获取，直到获取到锁才会退出循环，任何时刻最多只能有一个执行单元获得锁

总结：不会发生线程状态的切换，一直处于用户态，减少了线程上下文切换的消耗，缺点是循环会消耗CPU。

5、共享锁和独享锁

共享锁：也叫读锁，可以查看数据，但是不能修改和删除的一种数据锁，加锁后其他的用户可以并发读取，但不能修改、增加、删除数据，该锁可被多个线程持有，用于资源数据共享

独享锁：也叫排它锁、写锁、独占锁、独享锁，该锁每一次只能被一个线程所持有，加锁后任何线程试图再次加锁都会被阻塞，直到当前线程解锁。例如：线程A对data加上排它锁后，则其他线程不能再对data加任何类型的锁，获得互斥锁的线程既能读数据又能修改数据。

二：万物皆可锁

万物皆可锁是因为每个对象底层都会有monitor，monitor会标记对象是否加锁，一个对象有一个monitorenter但是会有两个monitorexit，当锁的代码块异常时，通过第二个monitorexit来释放锁。