锁及其优化

乐观锁和悲观锁

悲观锁

总是假设最坏的情况,每次在获取共享数据的时候都认为别人会修改,所以每次都在获取数据的时候加锁。即在整个数据处理过程中,将数据处于锁定状态。传统的数据库里就用到很多这种锁,比如行锁、表锁、读锁、写锁等都是在操作之前先上锁,比如java中Synchronized关键字的实现也是悲观锁。

悲观锁存在的问题:

在多线程竞争下,加锁,释放锁会导致比较多的上下文切换和调度延迟,引起性能问题,一个线程持有锁会导致其他需要此锁的线程挂起。

乐观锁

乐观锁认为数据一般情况下不会产生并发冲突,所以在数据进行提交更新的时候,才会对数据是否产生并发冲突进行检测,如果发现并发冲突,则返回错误信息,需要用户去决定如何操作。

乐观锁的实现的典型是CAS(Compare and Swap)

CAS

具有原子特性

CAS是乐观锁的实现技术,当多个线程尝试使用CAS同时更新同一个变量,只有一个线程能更新变量的值,而其他的线程都失败,失败的线程不会被挂起,而是被告知这次竞争失败了,并可以再次进行尝试。

CAS操作中涉及三个操作数:

  1. 需要读写的内存位置(V)
  2. 需要比较的预期原值(A)
  3. 拟写入 的新值(B)

如果内存位置V的值与预期原值A相匹配,那么处理器会自动的将该位置值更新为B,否则处理器不做任何处理。

第一步:获取位置V的值

第二步:将获取的值与预期原值A进行比较

如果相等,认为没有其他线程修改该位置,即不存在并发竞争,就可以将新值B写入位置V。如果不相等,说明存在其他的线程在对该位置进行并发操作。不能直接修改,继续跳转第一步,获取位置V的值,再进行比较,直至相等时修改为B。

模拟CAS算法

public class CompareAndSwap {
    private int value;


    //获取内存值
    public synchronized int getValue() {
        return value;
    }

    //比较并交换
    public synchronized int compareAndSwap(int expectValue,int newV) {
        int oldV = value;
        //如果内存值和预期值一致,就替换
        if (oldV == expectValue) this.value = newV;

        return oldV;
    }

    //设置 调用比较并交换, 看期望值和原来的值是否一致
    public synchronized boolean compareAndSet(int expectValue,int newV){
        return expectValue == compareAndSwap(expectValue, newV);
    }

}

public class TestCompareAndSwap {
    public static void main(String[] args) {
        CompareAndSwap cas = new CompareAndSwap();
        for (int i = 0; i < 10; i++) {
            new Thread(new Runnable() {
                @Override
                public void run() {
                    Random random = new Random();
                    int expectValue = cas.getValue();
                    int newV = random.nextInt(100);
                    boolean compareAndSet = cas.compareAndSet(expectValue, newV);
                    System.out.println(Thread.currentThread().getName()+
                            ",预期值:"+expectValue+",待写入值:"+newV+",操作结果:"+compareAndSet);

                }
            }).start();
        }
    }
}

在JDK1.5中新增了java.util.concurrent(J.U.C)建立在CAS之上,相对于Synchronized是一种线程阻塞处理,CAS是非阻塞的一种常见实现,即线程即使没有获取到变量,也不会进入到阻塞状态。就是在不使用锁的情况下来保证线程安全,在JUC下存在如AtomicInteger为例,其中一些i++操作是安全性操作,getAndIncrement()方法。

CAS中的ABA问题

CAS会引起ABA的问题,假如存在如下执行序列:

1.线程1从内存V中取出A

2.线程2从内存V中取出A

3.线程2进行了一些操作,将B写入位置V

4.线程2将A再次写入位置V

5.线程1进行CAS操作,发现位置V依然是A,进行修改操作成功

6.尽管线程1的CAS操作成功,但不代表这个过程没有问题--对于线程1,线程2的修改已经丢失了

一个链表ABA的问题:

1.现有一个单向链表实现的堆栈,栈顶为A。这时线程1已经知道A.next是B,希望通过CAS操作将栈顶替换为B,线程1执行compareAndSwap(A,B)

2.在线程1执行上面指令之前,线程2介入,将A、B出栈,再依次入栈D、C、A,而对象B此时处于游离状态。

3.此时线程1执行CAS操作,检测栈顶是A,所以CAS成功,栈顶修改为B,但实际B.next为null,此时堆栈中只有一个B元素,C和D组成的链表就不存在堆栈中,C、D被丢弃了。

ABA问题的解决方案

使用版本号,在变量上追加一个版本号,每次变量变更版本号加1,那么A-B-A就为1A-2B-3A

使用CAS会引发的问题

使用CAS好处就是使用锁的开销要小,但存在问题

1、ABA的问题

ABA的问题的解决方案就是加版本号解决

2、循环时间开销大

自旋CAS如果长时间不成功,会给CPU带来非常大的执行开销

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

当对一个共享变量执行操作时,可以使用循环CAS的方式保证原子操作,但对于多个共享变量,循环CAS就无法保证操作的原子性,这个时候就需要借助锁来实现

Synchronized锁优化

在JDK1.5之前,Synchronizeds的底层实现都是重量级的,也称之为Synchronized为重量级锁,在JDK1.5之后,对Synchronized进行了各种优化,实现的原理是锁升级的过程。偏向锁、轻量级锁和重量级锁

Java对象的内存布局

在Java中,创建一个对象后,在JVM中,对象在内存中的存储布局,分为三块:

对象头区域:存放锁信息、对象年龄信息

实例数据区域:存储的是对象的真正有效的信息,比如对象中所有字段内容

对齐填充区域:JVM规定对象的起始地址必须是8字节的整数倍,如果一个对象实际占用的内存大小不是8字节的整数倍,就“补位”到8字节的整数倍,对齐填充区域的大小不是固定的

Synchronized用的锁是存在对象头里,如果对象是数组类型,对象头中还包含了数组长度

如果是数组类型,则虚拟机使用3个字宽存储对象头,如果不是数组类型,则占用2个字宽存储对象头,在32位系统下,1字宽等于4字节即32bit

在java对象头Mark Word是默认存储对象的Hashcode,分代年龄和锁标志位,32位JVM中Mark Word默认存储的结构如下图所示:

在java SE1.6中,锁一共存在4种状态,级别从低到高依次是:无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态,这几个状态随着竞争的情况逐渐升级,锁是可以升级的不能降级,意味着偏向锁升级为轻量级锁再升级成重量级锁,目的是为了提高获取锁和释放锁的效率

偏向锁

偏向锁的操作时无须系统介入的,每个人对象都有对象头,对象头中的Mark Word存储对象的锁信息

 该对象头先处于无锁状态,当有线程来访问,JVM使用CAS操作将线程ID记录到Mark Word中,修改偏向锁的标志位,当前线程就拥有了这把锁

 注意:将线程ID通过CAS操作,变更偏向锁标识为1

JVM不用和操作系统协商设置monitor,只需记录下线程ID,就表示当前线程拥有这把锁,不用操作系统介入

获取锁的线程就可以进入到程序代码块中执行,当线程再次执行时,JVM通过锁对象的Mark Word判断,如果当前线程ID还存在,还持有这个对象的锁,就直接进入临界区执行,这个就是偏向锁,在没有别的线程竞争的时候,一直偏向当前的线程可以一直执行

优点:只有一个线程执行同步块时进一步提高性能,使用于一个线程反复使用同一个锁的情况,偏向锁可以提高带有同步但无竞争的程序的性能

轻量级锁

如果在偏向锁中一个线程A执行过程中,此时又来了另一个线程B要进入代码块执行,但是锁对象保存的是线程A的线程ID,偏向锁就导致线程B无法执行,在这个时候就需要对偏向锁进行升级,变成一个轻量级锁。

JVM把锁对象恢复成无锁状态,在当前的两个线程的栈帧中各分配一个空间,叫做Lock Record,把锁对象的Mark Word在两个线程的栈帧中各复制一份,叫做Displaced Mark Word,将当前线程A的Lock Record的地址使用CAS放到锁对象的Mark Word中,并且将锁的标识设置为00,意味着当前线程A获取到轻量级锁,可以进入到临界区执行

线程B 没有获取到锁,但不阻塞,JVM会然他自旋几次,等待一会,当线程A退出了临界区释放锁的时候,需要将B的Lock Record的地址使用CAS放到锁对象的Mark Word中,接下来线程就可以通过CAS复制信息。这个时候两个线程就可以交替进入临界区,执行代码

轻量级锁即使出现了竞争,想获取锁只要自旋几次,等待一会,锁就可以释放,使用CAS和Lock Record就可以避免重量级锁的开销

优点:绝大部分的锁在整个生命周期中都存在着少量竞争,在多线程交替执行同步代码块时可以避免重量级锁引起的性能问题

重量级锁

轻量级锁在运行时,线程A正持有锁,另一个线程B自旋了好多次,线程A还没有释放锁,这个时候JVM考虑自旋次数太多浪费CPU,就需要将锁升级为重量级锁

重量级锁需要操作系统的介入,依赖操作系统底层的mutex lock,JVM会创建一个monitor对象,把这个对象的地址信息更新到Mark Word中,并将锁标志设置为10

线程A还在持有锁运行,线程B直接挂起,线程进入阻塞,释放掉占用的CPU资源

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值