黄冈网站建设公司,药业做网站的网站目标分析,怎么装wordpress,wordpress管理导航栏目目录 常见的锁策略
乐观锁 vs 悲观锁
重量级锁 vs 轻量级锁
自锁锁和挂起等待锁
读写锁
可重入锁 vs 不可重入锁
公平锁 vs 非公平锁
CAS
ABA问题
synchronized几个重要的机制
1、锁升级
2、锁消除
3、锁粗化 常见的锁策略
乐观锁 vs 悲观锁
乐观锁和悲观锁是锁的…目录 常见的锁策略
乐观锁 vs 悲观锁
重量级锁 vs 轻量级锁
自锁锁和挂起等待锁
读写锁
可重入锁 vs 不可重入锁
公平锁 vs 非公平锁
CAS
ABA问题
synchronized几个重要的机制
1、锁升级
2、锁消除
3、锁粗化 常见的锁策略
乐观锁 vs 悲观锁
乐观锁和悲观锁是锁的一种特性不是一把具体的锁。
悲观和乐观是对后续锁冲突是否频繁给出的预测
如果预测接下来锁冲突的概率不大就可以少做一些工作称为乐观锁如果预测接下来锁冲突的概率很大就可以多做一些工作称为悲观锁
重量级锁 vs 轻量级锁
轻量级锁锁的开销比较小
重量级锁锁的开销比较大
这两种锁和刚才的乐观悲观有关乐观锁通常也就是轻量级锁悲观锁通常也就是重量级锁。
自锁锁和挂起等待锁 自旋锁属于轻量级锁的一种典型实现往往是纯用户态实现比如使用一个while循环不停的检查当前锁是否被释放如果没释放就继续循环释放了就获取到锁从而结束循环忙等虽然消耗了cpu但是换来了更快的响应速度。 挂起等待锁属于重量级锁的一种典型实现要借助系统api来实现一旦出现锁竞争了就会在内核中触发一系列的动作比如让这个线程进入阻塞状态暂时不参与cpu调度
读写锁
两个线程加锁过程中
读和读之间不会产生竞争读和写之间会产生竞争写和写之间会产生竞争
把加锁分成两种
读加锁读的时候别的线程能读但是不能写写加锁写的时候其他线程不能读也不能写
可重入锁 vs 不可重入锁
一个线程针对同一把锁连续加锁2次不会死锁就是可重入锁会死锁就是不可重入锁。
可重入锁会记录加锁线程信息以便线程二次加锁同时引入计数器每加锁一次就1直到计数器为0才释放锁
公平锁 vs 非公平锁
当很多线程去尝试加一把锁的时候一个线程能够拿到锁其他线程阻塞等待一旦第一个线程释放锁之后接下来是哪个线程能够拿到锁呢
公平锁按照“先来后到”的顺序
非公平锁剩下的线程以“均等”的概率来重新竞争锁
操作系统提供的加锁api默认情况就属于“非公平锁”如果要想实现公平锁还需要引入额外的队列维护这些线程的加锁顺序
上述这些锁策略都是描述了一把锁的基本特点的synchronized属于哪种锁呢
对于“悲观乐观”自适应的对于“重量轻量”自适应的对于“自旋 挂起等待”自适应的不是读写锁是可重入锁是非公平锁
所谓自适应就是初始情况下synchronized会预测当前的锁冲突的概率不大此时以乐观锁的模式来运行此时也就是轻量级锁基于自旋锁的方式来实现
在实际使用过程中如果发现锁冲突的情况比较多synchronized就会升级成悲观锁也就是重量级锁基于挂起等待的方式来实现
CAS
什么是CAS
CAS全称Compare and swap字面意思“比较并交换”一个CAS涉及到以下操作 假设内存中存在原数据V旧的预期值A需要修改的新值B 比较A与V是否相等如果比较相等将B写入V返回操作是否成功 比较交换的也就是内存和寄存器 如下例子
有一个内存 M两个寄存器 A,B
CAS(V,A,B)
如果M和A的值相同把M和B的值进行交换同时返回true如果M和A的值不同无事发生返回false
CAS其实就是一个cpu指令一个cpu指令就能完成上述比较交换的逻辑单个的cpu指令是原子的就可以使用CAS完成一些操作进一步的替代“加锁”。
基于CAS实现线程安全的方式也称为“无锁编程”
java中AtomicInteger和其他原子类就是基于CAS的方式对int进行了封装 进行就是原子的了。 public class Main { public static AtomicInteger countnew AtomicInteger(0); public static void main(String[] args) throws InterruptedException { Thread t1new Thread(()-{ //count count.getAndIncrement(); //count count.incrementAndGet(); //count-- count.getAndDecrement(); //--count count.decrementAndGet(); }); Thread t2new Thread(()-{ //count count.getAndIncrement(); //count count.incrementAndGet(); //count-- count.getAndDecrement(); //--count count.decrementAndGet(); }); t1.start(); t2.start(); } } 前面的“线程不安全”本质上是进行自增的过程中穿插执行了
CAS也是让这里的自增不要穿插执行核心思路和加锁是类似的
加锁是通过阻塞的方式避免穿插CAS则是通过重试的方式避免穿插
基于CAS实现自旋锁 public class spinLock{ private Thread ownernull; public void lock() { while(!CAS(this.owner,null,Thread.currentThread())) { } } public void unLock(){ this.ownernull; } } ABA问题 CAS进行操作的关键是通过值“没有发生变化”来作为“没有其他线程穿插执行的判断依据”但是这种判断方式不够严谨更极端的情况下可能有另一个线程穿插进来把值从A-B-A针对第一个线程来说看起来好像是这个值没变但是实际上已经被穿插执行了。 要避免ABA问题我们可以让判定的数值按照一个方向增长即可有增有减就可能出现ABA只是增加或者只是减少就不会出现ABA但是一些情况下本身就应该要能增能减我们可以引入一个额外的变量版本号约定每次修改余额都会让版本号自增此时在使用CAS判定的时候就不是直接判定余额了而是判定版本号看版本号是否是变化了如果版本号不变注定没有线程穿插执行了。
synchronized几个重要的机制
1、锁升级
JVM将synchronized锁分为无锁偏向锁轻量级锁重量级锁状态会依据情况进行依次升级。 无锁-偏向锁-自旋锁轻量级锁-重量级锁 锁升级的过程是单向的不能再降级了。
偏向锁不是真的加锁只是做了一个标记核心思想就是“懒汉模式”的另一种体现如果有别的线程竞争锁再升级成轻量级锁。
2、锁消除
锁消除是编译器优化的手段编译器会自动针对你当前写的加锁代码做出判定如果编译器觉得这个场景不需要加锁此时就会把你写的synchronized给优化掉。
比如StringBuilder不带synchronizedStringBuffer带有synchronized如果在单个线程中使用StringBuffer此时编译器就会自动的把synchronized给优化掉
3、锁粗化
锁的粒度synchronized里头代码越多就认为锁的粒度越粗代码越少锁的粒度越细。
粒度细的时候能够并发执行的逻辑更多更有利于充分利用好多核CPU资源但是如果粒度细的锁被反复进行加锁解锁可能实际效果还不如粒度粗的锁。