synchronized常见锁策略

boolean CAS(address, expectValue, swapValue) {
    if (&address == expectedValue) {
        &address = swapValue;
        return true;
     }
        return false;
}

CAS的会执行如下的操作:

将旧的预期值与内存中原有数据进行比较
如果相等,就将新的值与内存数据交换.
返回更新成功否则返回失败

注意 : CAS上述3个操作都是原子的.---是一种硬件指令

多个线程操作CAS时只会有一个线程成功,其余线程不会阻塞,但是都会接收操作失败的信号.

CAS的应用场景

CAS实现原子类

伪代码如下 :

class AtomicInteger {
    private int value;
    public int getAndIncrement() {
        int oldValue = value;
        while ( CAS(value, oldValue, oldValue+1) != true) {
            oldValue = value;
        }
        return oldValue;
    }
}

线程1先进行操作,如果与内存原有数据相等就+1之后与内存数据交换.
线程2在进行操作,与内存数据进行比较,发现不相等就进入循环,把内存数据赋值给线程2.
线程2再次进行操作,与内存数据进行比较,发现相等,就对线程2的值+1然后与内存数据交换.

到此就完成了两个线程都对内存执行了两次++操作.

在Java类中也有原子类,能进行原子的++,--操作------>AtomicInteger

public static void main(String[] args) {
     AtomicInteger atomicInteger = new AtomicInteger();
     atomicInteger.getAndIncrement();//后置++;
     atomicInteger.incrementAndGet();//前置++;
     atomicInteger.decrementAndGet();//前置--;
     atomicInteger.getAndIncrement();//后置--
}

CAS实现自旋锁

伪代码如下 :

public class SpinLock {
private Thread owner = null;
    public void lock(){
    while(!CAS(this.owner, null, Thread.currentThread())){

    }
}
    public void unlock (){
        this.owner = null;
    }
}

刚开始Thread线程对象owner为null;然后一直与null值进行比较.

如果为null,证明当前线程没有占用锁,就退出循环,把owner设为当前持有锁线程

如果不为null,证明当前线程占用了锁,进入循环,自旋等待.

CAS中的ABA问题

我们在执行CAS的操作时,就会拿A与内存中的数据进行比较,如果相等就进行交换/更新,但是这里就会出现问题,我们拿的A是始终是A,还是从A->B->A,CAS就会认为A始终没有变化,这就会导致问题.

举个例子

比如小明现金有1000元,小明要取钱,一不小心按下了两次取钱操作,这时就会出现两个线程,线程1与银行卡的前进行比较1000与1000相同,这时就扣款成功银行卡中只剩下500,此时线程2的CAS又对其执行扣款,线程2原来有1000与500进行比较扣款失败,此时没有问题,符合预期,但是当线程2读取时,又有小明的朋友转了500元,有来了个线程3,线程3中的500与银行卡中的500进行比较相等然后打钱成功,此时银行卡又剩下1000元,线程2读取时发现1000与1000相等此时又进行了一次扣款. 这就导致扣款两次,导致500元转丢了.我们并不知道银行卡中的500.始终是500还是500->1000->500

那如何解决CAS中ABA问题呢???

我们可以通过引入版本号来解决此问题.比较值的同时也要比较版本号,每次进行修改时,都要对版本号进行+1操作,如果版本号不相同则操作失败

此时引入版本号,再次进行推演上个例子

还是小明有1000元(版本号为1),此时要取款,线程1进行比较,1000(版本号为1)与1000(版本号为1),发现相等就扣款成功此时银行卡中有500(版本号2),线程2在读取时,线程3又对其打钱500,此时变为1000(版本号3),在线程2读取时又要扣款,线程2(版本号1,1000元)与线程3(版本号3,1000)不一致则扣款失败.

CAS还会有一些问题 :

循环时间开销大;

只能保证一个共享变量的原子操作.

synchronized锁升级过程

JVM有时会根据情况对synchronized进行锁升级;

基本的升级过程为无锁===>偏向锁===>轻量级锁===>重量级锁

无锁

没有加锁的状态

偏向锁

当要进行加锁时,从无锁转为偏向锁.

注意理解偏向锁 :

偏向锁不是真正的加锁,而是给对象头标记为偏向锁状态.如果接下来不会产生锁冲突,就不会进行锁升级.偏向锁的目的就是尽量能不加锁就不加锁,延迟加锁,避免了加锁的开销.当发生锁冲突时,就取消偏向锁状态,进行锁升级--升级为轻量级锁.

轻量级锁

这个轻量级锁时基于CAS实现的,CAS为其更新内存,更新成功,则加锁成功,否则处于自旋状态(始终占CPU).

重量级锁

当竞争在激烈时就会转为重量级锁,此时会进入内核态,会看当前锁是否被占用,如果没有被占用就切换为用户态.如果被占用就需要阻塞等待,等待其他线程都释放锁之后,才尝试加锁

总结

刚开始为无锁状态,随着要进行加锁,进入偏向锁状态,偏向锁不是真正的加锁,只是在对象头上做了个标记,标记为偏向锁状态,如果不产生锁冲突就一直保持当前状态,如果产生锁冲突,就需要进行锁升级,升级为轻量级锁.此轻量级锁基于CAS实现的,CAS会为其更新内存,如果更新内存成功,则加锁成功,否则进入自旋等待状态.此时自旋状态相当于CPU空转,浪费CPU资源.随着锁冲突/竞争激烈时,又转为重量级锁,此时会进入内核态.会看当前锁是否被占用,如果没有被占用,则切换为用户态加锁成功,如果当前锁被占用,会一直阻塞等待,等待其他线程释放锁,才尝试获取锁.

锁的其他优化

锁消除

比如StringBuilder的append方法是使用了synchronized来保证线程安全状态,而当我们在单线程使用append方法时,不涉及到线程安全问题,此时JVM和编译器就会对其优化,将其锁消除

锁粗化

这里是表示synchronized代码块的范围.

当代码块的范围越大时,锁的粒度就越粗.当代码块的范围越小时,锁的粒度就越细.

有时代码范围越小就导致反复的加锁释放锁,这时就会扩大代码块的范围,避免反复的加锁释放锁.

举例 :

比如向领导汇报工作,我是三件事情分成三次时间向领导汇报工作这样做不仅我烦,领导也会很烦,所以我就一次性的把三件事情全部汇报清楚.

厚积薄发ض

关注

3
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
synchronized常见锁策略

悲观锁对发生并发冲突总假设最坏情况,预测锁冲突概率会很大,所以每次拿数据时都要进行加锁,如果其他线程想要获取此资源就要进行阻塞等待.----悲观锁往往要进入内核态--使当前线程阻塞等待.重量级锁 : 重量级锁一般是指操作系统提供的mutex互斥锁,需要在内核态和用户态之间频繁的切换,容易引发线程调度. ---- 常常是悲观锁。乐观锁则认为一般情况下不会发生并发冲突,而是当需要进行更新数据时,才来检测是否发生锁冲突,如果发生冲突交给用户处理----(纯用户态操作)读写锁 : 读写锁是将读和写分离开来;...
复制链接

扫一扫