本文主要是介绍JavaEE:多线程进阶(常见的锁策略)，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
文章目录
- 常见的锁策略
- 各种锁的概念
- synchronized
- 特点
- 加锁过程
- 锁消除(编译器的优化策略)
- 锁粗化(编译器的优化策略)
常见的锁策略
锁是一个非常广义的问题.
synchronized只是市面上五花八门的锁的一种典型的实现.它是Java内置的,推荐使用的锁.
各种锁的概念
下面这些概念,一般面试的时候,不会直接问你,但是可能会在某某问题中,引出这样的术语.
-
乐观锁 vs 悲观锁
- 乐观锁: 加锁的时候,假设出现锁冲突的概率不大,接下来要围绕加锁做的工作,就会更少.
- 悲观锁: 加锁的时候,假设出现锁冲突的概率很大,接下来围绕加锁要做的工作,就会更多
synchronized这把锁算是自适应的.
synchronized初始情况下是乐观的,同时它会在背后偷偷统计锁冲突了多少次.如果发现锁冲突的次数达到一定程度了,就会变为悲观的. -
重量级锁 vs 轻量级锁
- 重量级锁: 加锁的开销比较大,要做更多的工作.(往往悲观的时候,会做的重)
- 轻量级锁: 加锁的开销比较小,要做的工作相对更少.(往往乐观的时候,会做的轻)
但是不能就认为是100%等价.
乐观悲观,是站在"预估锁冲突"的角度.
重量轻量,则是站在"加锁开销"的角度 -
挂起等待锁 vs 自旋锁
- 挂起等待锁: 属于是悲观锁/重量级锁的一种典型实现.当线程无法获取锁时，会选择主动让出CPU,并进入等待队列（通常是被操作系统挂起）,直到 锁被释放并收到通知后才重新参与CPU调度 。
- 自旋锁: 属于乐观锁/轻量级锁的一种典型实现.当线程无法获取锁时，会不停的检测锁是否被释放,一旦锁释放了,就立即有机会能够获取到锁
轻量级锁,就是基于"自旋"的方式实现的(JVM内部,用户态代码实现的)
重量级锁,就是基于"挂起等待锁"的方式实现的(调用操作系统api,在内核中实现的) -
公平锁 vs 非公平锁
- 公平锁: 其他线程按照先来后到的顺序来获取锁.
- 非公平锁: 其他线程按照"概率均等"的方式来竞争锁.(概率不一定是数学上的严格均等)
synchronized属于非公平锁.
-
可重入锁 vs 不可重入锁
- 可重入锁: 一个线程,针对同一把锁,可以连续加锁两次以上.
- 不可重入锁: 一个线程,针对同一把锁,不能连续加锁两次以上,否则会出现死锁问题.
可重入锁的实现逻辑:
- 记录当前是哪个线程持有了这把锁.
- 在加锁的时候判定,当前申请锁的线程,是否是锁的持有者线程.
- 通过计数器,记录加锁的次数,从而确定何时真正释放锁.
-
读写锁
读写锁把加锁操作分成两种情况:读加锁和写加锁.- 如果,多个线程,同时读一个变量,此时没有线程安全问题.
- 但是,一个线程读/一个线程写 或者 两个线程都写 就会产生问题.
读写锁提供了两种加锁的api:加读锁和加写锁.
- 如果两个线程,都是按照读方式加锁,此时不会产生锁冲突.
- 如果两个线程,都是加写锁,此时会产生锁冲突.
- 如果一个线程是读锁,一个线程是写锁,也会产生锁冲突.
虽然两种加锁的api不同,但是解锁的api是一样的.
Java标准库提供了
ReentrantReadWriteLock类,实现了读写锁.ReentrantReadWriteLock.ReadLock类表示一个读锁,这个对象提供了lock/unlock方法进行加锁解锁.ReentrantReadWriteLock.WriteLock类表示一个写锁,这个对象也提供了lock/unlock方法进行加锁解锁.
其中:
读加锁和读加锁之间,不互斥.
写加锁和写加锁之间,互斥.
读加锁和写加锁之间,互斥.
synchronized不是读写锁.
synchronized
特点
synchronized有以下特点:
- 乐观 or 悲观,自适应.
- 重量 or 轻量,自适应.
- 自旋 or 挂起等待,自适应.
- 是非公平锁.
- 是可重入锁.
- 不是读写锁.
加锁过程
刚开始使用synchronized加锁,首先锁会处于"偏向锁"状态.
当遇到线程之间的锁竞争时,会升级到"轻量级锁".
进一步的统计出现的频次,次数达到一定程度后,会升级到"重量级锁".
上述锁升级的过程,主要是为了能够让synchronized适应不同的场景,降低程序员的使用负担~
上述锁升级的过程不可逆!
理解一下偏向锁:
偏向锁,不是真的加锁,而只是做一个标记.(标记的过程非常的轻量高效)
锁消除(编译器的优化策略)
编译器会对你写的synchronized代码,做出判定,判定这个地方是否需要加锁.
如果这里没有必要加锁,编译器就能够自动把synchronized给干掉.
虽然存在锁消除,但是咱们在写代码的时候,不能完全指望这个,最好不要无脑加锁.
锁粗化(编译器的优化策略)
要讲锁粗化,那就不得不提到锁的粒度.
在一个锁内,代码越多,粒度就越粗;代码越少,粒度就越细.
注意了,这里的"代码多",指的是执行过程中实际运行的代码行数.
锁粗化,就是把多个"细粒度"的锁,合并成"粗粒度"的锁.
锁粗化可以减少获取和释放锁的次数，从而降低锁带来的开销。
需要注意的是，锁粗化并不是适用于所有情况的优化策略。在某些情况下，锁粒度较细可能是必要的，以保证程序的正确性和性能。
本文到这里就结束啦~
这篇关于JavaEE:多线程进阶(常见的锁策略)的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
