cas
什么是CAS
CAS:全称Compareandswap，字⾯意思:”⽐较并交换“，⼀个CAS涉及到以下操作： 我们假设内存中的原数据V，旧的预期值A，需要修改的新值B。
1. ⽐较A与V是否相等。（⽐较）
2. 如果⽐较相等，将B写⼊V。（交换）
3. 返回操作是否成功。
CAS伪代码
下⾯写的代码不是原⼦的,真实的CAS是⼀个原⼦的硬件指令完成的.这个伪代码只是辅助理解CAS的⼯作流程.
boolean CAS(address, expectValue, swapValue) {if (&address == expectedValue) {&address = swapValue;return true;}return false;
}
CAS有哪些应用
1)实现原⼦类
标准库中提供了ava.util.concurrent.atomic 包,⾥⾯的类都是基于这种⽅式来实现的. 典型的就是AtomicInteger类.其中的getAndIncrement相当于i++操作.
AtomicInteger atomicInteger = new AtomicInteger(0);
// 相当于 i++
atomicInteger.getAndIncrement();
伪代码实现:
class AtomicInteger {private int value;public int getAndIncrement() {int oldValue = value;while ( CAS(value, oldValue, oldValue+1) != true) {oldValue = value;}return oldValue;}
}
假设两个线程同时调⽤getAndIncrement
1. 两个线程都读取value的值到oldValue中.(oldValue是⼀个局部变量,在栈上.每个线程有⾃⼰的栈)
2. 线程1先执⾏CAS操作.由于oldValue和value的值相同,直接进⾏对value赋值.
注意:
• CAS是直接读写内存的,⽽不是操作寄存器.
• CAS的读内存,⽐较,写内存操作是⼀条硬件指令,是原⼦的.
3. 线程2再执⾏CAS操作,第⼀次CAS的时候发现oldValue和value不相等,不能进⾏赋值.因此需要 进⼊循环.
在循环⾥重新读取value的值赋给oldValue
4. 线程2接下来第⼆次执⾏CAS,此时oldValue和value相同,于是直接执⾏赋值操作.
5. 线程1和线程2返回各⾃的oldValue的值即可.
通过形如上述代码就可以实现⼀个原⼦类.不需要使⽤重量级锁,就可以⾼效的完成多线程的⾃增操作.
本来checkandset这样的操作在代码⻆度不是原⼦的.但是在硬件层⾯上可以让⼀条指令完成这个 操作,也就变成原⼦的了.
synchronized
锁升级
JVM将synchronized锁分为⽆锁、偏向锁、轻量级锁、重量级锁状态。会根据情况，进⾏依次升 级。
1)偏向锁
第⼀个尝试加锁的线程,优先进⼊偏向锁状态.
偏向锁不是真的"加锁",只是给对象头中做⼀个"偏向锁的标记",记录这个锁属于哪个线程.
如果后续没有其他线程来竞争该锁,那么就不⽤进⾏其他同步操作了(避免了加锁解锁的开销)
如果后续有其他线程来竞争该锁(刚才已经在锁对象中记录了当前锁属于哪个线程了,很容易识别当前 申请锁的线程是不是之前记录的线程),那就取消原来的偏向锁状态,进⼊⼀般的轻量级锁状态.
偏向锁本质上相当于"延迟加锁".能不加锁就不加锁,尽量来避免不必要的加锁开销. 但是该做的标记还是得做的,否则⽆法区分何时需要真正加锁.
2)轻量级锁
随着其他线程进⼊竞争,偏向锁状态被消除,进⼊轻量级锁状态(⾃适应的⾃旋锁). 此处的轻量级锁就是通过CAS来实现.
• 通过CAS检查并更新⼀块内存(⽐如null=>该线程引⽤)
• 如果更新成功,则认为加锁成功
• 如果更新失败,则认为锁被占⽤,继续⾃旋式的等待(并不放弃CPU).
⾃旋操作是⼀直让CPU空转,⽐较浪费CPU资源. 因此此处的⾃旋不会⼀直持续进⾏,⽽是达到⼀定的时间/重试次数,就不再⾃旋了. 也就是所谓的"⾃适应"
3)重量级锁
如果竞争进⼀步激烈,⾃旋不能快速获取到锁状态,就会膨胀为重量级锁 此处的重量级锁就是指⽤到内核提供的mutex.
• 执⾏加锁操作,先进⼊内核态.
• 在内核态判定当前锁是否已经被占⽤
• 如果该锁没有占⽤,则加锁成功,并切换回⽤⼾态.
• 如果该锁被占⽤,则加锁失败.此时线程进⼊锁的等待队列,挂起.等待被操作系统唤醒.
• 经历了⼀系列的沧海桑⽥,这个锁被其他线程释放了,操作系统也想起了这个挂起的线程,于是唤醒 这个线程,尝试重新获取锁.
锁消除
编译器+JVM判断锁是否可消除.如果可以,就直接消除.
什么是"锁消除"
有些应⽤程序的代码中,⽤到了synchronized,但其实没有在多线程环境下.(例如StringBuffer)
StringBuffer sb = new StringBuffer();
sb.append("a");
sb.append("b");
sb.append("c");
sb.append("d");
此时每个append的调⽤都会涉及加锁和解锁.但如果只是在单线程中执⾏这个代码,那么这些加锁解 锁操作是没有必要的,⽩⽩浪费了⼀些资源开销.
锁粗化
⼀段逻辑中如果出现多次加锁解锁,编译器+JVM会⾃动进⾏锁的粗化.
锁的粒度:粗和细
实际开发过程中,使⽤细粒度锁,是期望释放锁的时候其他线程能使⽤锁.
但是实际上可能并没有其他线程来抢占这个锁.这种情况JVM就会⾃动把锁粗化,避免频繁申请释放锁.
举个栗⼦理解锁粗化
滑稽⽼哥当了领导,给下属交代⼯作任务:
⽅式⼀:
• 打电话,交代任务1,挂电话.
• 打电话,交代任务2,挂电话.
• 打电话,交代任务3,挂电话.
⽅式⼆:
• 打电话,交代任务1,任务2,任务3,挂电话.
显然,⽅式⼆是更⾼效的⽅案.可以看到,synchronized的策略是⽐价复杂的,在背后做了很多事情,⽬的为了让程序猿哪怕啥都不懂,也不⾄于写出特别慢的程序.JVM开发者为了Java程序猿操碎了心.
