前言
锁的策略:加锁过程中,即处理冲突的过程中,需要涉及到的一些不同的处理方式(此处锁策略并不是java独有的),本篇内容主要是讲解一下关于锁的相关知识点;
1. 关于锁的分组
1.1 第一组:乐观锁和悲观锁
------>这是两种不同的锁的实现方式
乐观锁:在加锁之前,预估当前出现锁冲突的概率不大,因此在进行加锁的时候不会做太多的工作。加锁过程中做的事情比较少,加锁的速度可能更快,但是更容易引入一些其他的问题(即可能会消耗更多的cpu资源)
悲观锁:在加锁之前,预估当前出现锁冲突的概率比较大,因此在进行加锁的时候会做更多的工作,因为做的事情更多,所以加锁的速度回更慢,但是整个过程中不容易出现其他的问题。
1.2 第二组:轻量级锁和重量级锁
轻量级锁,加锁的开销更小,加锁的速度更快--->轻量级锁,一般都是乐观锁
重量级锁,加锁的开销更大,加锁的速度更慢--->轻量级锁,一般都是悲观锁
轻量重量是加锁之后对结果的评价,悲观乐观,是加锁之前,对未来的事情进行的预估,根据整体来说,这两种角度,描述的都是同一个事情;
1.3 第三组:自旋锁和挂起等待锁
自旋锁:是轻量级锁的一种典型实现;加锁的时候,如果加锁失败,不会就此阻塞放弃cpu,而是相当于添加一个while循环,不停的进行锁竞争,这次锁竞争失败了就再次进入循环竞争锁,直到加锁成功,才退出循环。
这种反复快速的执行,就称为 “自旋”,故此自旋锁也是乐观锁,使用自旋锁的前提是预期锁冲突概率不大,只要其他线程释放了锁,它就能第一时间加锁成功;但如果有很多线程要加锁,就必要使用自旋锁了,因为会浪费cpu资源。
等待挂起锁:是重量级锁的一种典型体现,也是悲观锁;加锁的时候,如果加锁失败,就会等待一段时间,这段时间它不会去进行加锁操作和别的线程锁竞争,故此就能把一些cpu资源让出来,被让出来的这些cpu资源可以干一些其他事情,等一段时间过后,会再次尝试加锁,如果失败还是重复以上工作,直到最后成功拿到锁;
当等待挂起的时候,会有内核调度器介入,所以就需要完成的操作就多了,从而要获取锁的时间花费也更多一些。
Q:java中的synchronized算以上锁的哪种情况?
A:synchronized具有自适应能力,且synchronized在某些情况下是乐观锁,轻量级锁,自旋锁;但是在某些情况下时悲观锁,重量级锁,等待挂起锁,当然系统内部会自动的评估当前锁冲突的激烈程度;
如果当前锁冲突的激烈程度不大,就处于乐观锁\轻量级锁\自旋锁;
如果当前锁冲突的激烈程度很大,就处悲观锁锁\重量级锁\等待挂起锁;
1.4 第四组: 普通互斥锁和读写锁
普通互斥锁:类似synchronized这种,操作涉及到加锁、解锁
读写锁:这里加锁的情况分为两种:加读锁,加写锁
读锁和读锁之间,不会出现锁冲突(不会阻塞);写锁和写锁之间,会涉出现锁冲突(会阻塞);读锁和写锁之间,会出现锁冲突(会阻塞);当一个线程加读锁时,另一个线程只能读,不能写;当一个线程加写锁时,另一个线程不能写,也不能读
Q:为啥要引入读写锁?
A: 如果两个线程读,本身就是线程安全的,不需要进行互斥;
如果使用synchronized这种方式加锁,两个线程读与会产生互斥(阻塞),对于性能有一定的损耗,完全给读操作不加锁,就怕连个线程一个是读线程,一个是写线程,这样更加会涉及锁冲突;如上所述,读写锁能很好地解决上述的问题
java标准库中,也提供了专门的类,来实现读写锁(读写锁本质上还是系统提供的读写锁,系统提供api,jvm中将api进行封装给我们使用),注意synchornized不是读写锁;
1.5 第五组:公平锁和非公平锁
此处的公平即遵循先来后到的规则才是公平;
公平锁:如果线程和线程之间,锁竞争的时间大小不一样,按照锁竞争时间久的线程先拿到锁,有先后顺序(先来后到的意思)
非公平锁:线程和线程之间没有拿锁顺序,随机调度,各凭各的本事拿锁。
这里使用公平锁,就能很好的解决线程饿死的这一问题。而要想实现公平锁,就需要引入额外的数据结构(引入队列,记录每个线程的先后顺序),才能实现公平锁。
1.6 第六组:可重入锁和不可重入锁
可重入锁:如synchronized,加锁一段代码,锁里面可以再进行一次加锁,锁里面可以嵌套多个锁,里面是用计数器这种方式对加锁的数量进行计数,并判断是否解锁,是可重入锁。
不可重入锁:系统自带的锁,不能连续加锁两次。
1.7 synchronized和Linux基于特定锁的简单比较
下面来说明一下synchronized和系统自带的锁的具体锁;
synchronized:乐观锁 / 悲观锁自适应
轻量级锁 / 重量级锁自适应
自旋锁 / 挂起等待所自适应
不是读写锁
非公平锁
可重入锁
linux提供的mutex(系统自带的锁):
悲观锁
重量级锁
挂起等待所
不是读写锁
非公平锁
不可重入锁
2. 细说synchronized的自适应
Synchronized的加锁过程,自适应如下所述:
当线程执行到synchronized的时候,如果这个对象处于未加锁的状态,就会经历一下的过程:
2.1 锁升级
1、偏向锁阶段
核心思想:“懒汉模式”,就是能不加锁,就不加锁;所谓的偏向锁,并不是真的加锁了,只是做了个非常轻量的标记。
一旦有线程来竞争这个锁,持有偏向锁的线程能第一时间拿到这个锁,如果没有其他线程竞争锁,下次还是拿到锁的线程大概率还是持有偏向锁的线程。
总的来说,当有锁竞争的情况下,偏向锁没有提高效率,在没有锁竞争的情况下,偏向锁就能大幅度的提高效率了。
这个标记是锁里面的一个属性,每个锁都有自己的标记,当锁对象首次加锁是,没有涉及到锁竞争,这个阶段就是偏向锁阶段,一旦涉及到锁竞争,就会升级成轻量级锁阶段。
2、轻量级锁阶段
此处的轻量级锁就是通过自旋的方式实现的。假设有锁竞争,但不多的时候,就会处于轻量级锁阶段,它的优势:当其他线程释放锁了,处于轻量级锁阶段的线程能第一时间拿到锁;劣势:比较消耗cpu资源,因为是自旋的方式实现的,会有个循环一直尝试拿锁。
当线程多了,轻量级锁就不合适了,每个线程都循环尝试拿锁,但如果已经有线程拿到锁了,其他线程要阻塞等待,但等待的这过程是会有循环不断的尝试拿锁,这里消耗的cpu资源就很多了。这时,就会从轻量级锁阶段升级成重量级锁阶段。
3、重量级锁阶段
此处的重量级锁是用挂起等待的方式实现的,当有很多线程同时去竞争这个锁时,有个线程拿到锁了,其他线程没拿到,就会阻塞等待,等待一段时间再去尝试拿锁,不成功再阻塞等待一段时间,循环以上步骤,如此就会让出cpu的资源,可以利用这些cpu资源干一些其他的事。注意:当前版本此处只能升级,不能降级。
2.2 锁消除
锁消除是synchronized的内部优化;
有时候,有些代码可以一眼看上去就不用加锁,但是代码加锁了,这时候,编译器就会把这个锁给消除掉,毕竟加锁操作也是要消耗一些硬件资源的。
注意:锁消除和偏向锁的区别
锁消除:针对能够一眼就看出不涉及到线程安全问题的代码,编译器能够把锁给消除掉。
偏向锁:是已经运行代码了,才知道没有锁竞争。
2.3 锁粗化
通常情况下,我们更偏好于让锁更细一些,这样更有利于并发编程的时候解决线程安全问题;但有时候,让锁更粗写能提高效率,会希望锁粗点。
锁粗化:把多个细粒度的锁合并成一个粗粒度的锁。如下图所示:
一段代码中,频繁的加锁解锁,肯定会消耗更多的硬件资源,但是如果能把一段代码的多个加锁、解锁操作,优化成只有一次加锁、解锁,这样也能提高效率。
ps:关于多线程中锁策略的内容就到这里了,如果对你有所帮助的话,就请一键三连哦!!!