美文网首页
并发编程(三):锁的优化

并发编程(三):锁的优化

作者: wch853 | 来源:发表于2018-12-08 16:03 被阅读4次

    锁优化角度

    减小锁持有的时间

    在真正需要同步的代码块进行加锁,避免在整个任务的处理上加锁,有助于降低锁冲突的可能性,进而提升系统的并发能力。

    减小锁粒度

    缩小锁定对象的范围,降低锁冲突可能性,进而提升系统并发能力。例如 ConcurrentHashMap 内部细分为若干个小的 HashMap,添加数据时可能只需要对其中的某个 SEGMENT 加锁,这样同时就有多个线程可以操作 ConcurrentHashMap,大大提高了吞吐量。

    使用读写锁代替独占锁

    理论上读-读之前是不应该阻塞的,在读多写少的情况下,使用读写锁相对于独占锁能够有效提升系统并发能力。

    锁分离

    在区别读写锁的基础上进一步延伸,就是锁分离。例如如果需要创建一个线程安全的容器,其加入元素和弹出元素的操作必须要获得容器的锁,那么在运行时,加入和弹出操作就必须等待对方释放资源,如果锁竞争激烈,并发性能就会大大下降。而 LinkedBlockingQueue 的实现中,则使用了读锁和写锁两把锁,其原理是利用 ReentrantLockCondition 分别阻塞和唤醒线程,使得读取和写入之间可以并发。

    锁粗化

    虚拟机在一系列对同一锁不断进行请求和释放的操作时,便会把所有锁操作整合为对锁的一次请求,从而减少对锁的请求同步次数。锁粗化的思想和减少锁的持有时间是相反的。

    JVM对锁的优化

    偏向锁

    如果某个线程获取了锁,到再次请求锁时,没有其他线程再去请求该锁,则省略线程申请锁的同步操作。在几乎没有锁竞争的场合中,偏向锁具有很强的优化效果;但在锁竞争激烈的情况下,可能是多个线程请求相同的锁,偏向模式就会失效。通过虚拟机参数 -XX:+UseBiasedLocking 开启偏向锁。

    轻量级锁

    线程在执行同步块之前,JVM会先在当前线程的栈桢中创建用于存储锁记录的空间,并将对象头中的 Mark Word 复制到锁记录中,然后线程尝试使用 CAS 将对象头中的 Mark Word 替换为指向锁记录的指针。如果成功则线程可以顺利进入临界区,如果失败,锁请求会膨胀为重量级锁。

    自旋锁

    假设在不久的将来,线程就可以获取请求的锁资源,那么直接在操作系统层面将线程挂起是得不偿失的,因此虚拟机会让当前线程做几个空循环,如果若干次循环后能够获得锁,则顺利进入临界区,否则才会将线程真实地在操作系统层面挂起。

    锁消除

    虚拟机在 JIT 编译时通过对上下文的扫描,能够去除不可能存在共享资源竞争的锁。通过锁消除,可以节省无意义的请求锁的时间。锁消除设计的一项关键技术为逃逸分析,即观察某一个变量是否会逃出某一个作用域。

    ThreadLocal

    ThreadLocal 表示线程局部变量,只有当前线程才能访问,因此是线程安全的,但是不同线程的 ThreadLocal 如果存放了相同的对象,那么也是线程不安全的,需要在应用层作出保证。如果共享对象对于竞争的处理容易造成性能损失,则应该考虑使用 ThreadLocal 为每个线程分配单独的对象。

    ThreadLocal.set(T value)

    在调用 ThreadLocalset() 方法时,先根据当前线程获取 ThreadLocal.ThreadLocalMap 的一个实例(可以理解为一个Map),写入数据时,以 ThreadLocal 对象作为 key,写入的数据作为 value

    ThreadLocal.get()

    在调用 ThreadLocalget() 方法时,获取当前线程对应的 ThreadLocal.ThreadLocalMap 实例,再使用 ThreadLocal 对象作为 key 取出数据。

    ThreadLocal.remove()

    通过 ThreadLocal 写入的数据是维护在线程内部的,所以只要线程不退出,对象引用就会一直存在。如果使用线程池,在任务结束后不对数据进行清理,则可能会造成内存泄漏,因此在数据使用完成后最好使用 ThreadLocal.remove() 将数据移除。

    无锁

    对于并发而言,锁是一种悲观的策略,它总是假设每次临界区操作都会产生冲突,在获取不到锁时,会阻塞线程执行。而无锁是一种乐观的策略,它假设对资源的访问是没有冲突的,所有线程都可以在非阻塞的情况下执行,无锁策略使用 CAS (Compare And Swap) 来鉴别线程冲突,一旦检测到冲突,就重试当前操作至没有冲突为止。

    CAS

    CAS (Compare And Swap,比较交换) 由于其非阻塞性,对死锁问题天生免疫;线程间的相互影响远比基于锁的方式要小;使用无锁的方式完全没有锁竞争和线程间频繁调度带来的系统开销,因此无锁比基于锁的方式拥有更优越的性能。

    CAS算法

    CAS(V, E, N) 包含3个参数:

    • V:要更新的变量的值。
    • E:变量的预期值。
    • N:变量需要更新的值。

    CAS 是一个原子操作,仅当 VE 相等时,才会将变量的值更新为 N,否则说明有其它线程对这个变量做了修改操作,当前线程放弃更新,最后返回变量的真实值。

    CAS核心操作

    AtomicInteger 为例,此类中的核心字段为:

    // 实际取值
    private volatile int value;
    

    incrementAndGet() 方法的作用是自增1并获取变量的值,其内部调用的是 Unsafe 类的 getAndAddInt() 方法。

    public final int incrementAndGet() {
        return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
    }
    
    /**
     * @param obj 进行修改的AtomicInteger对象
     * @param valueOffset AtomicInteger的value字段的地址偏移量
     * @param i 要增加的数值
     * @return 被修改的变量修改前的值
     */
    public final int getAndAddInt(Object obj, long valueOffset, int i) {
        int pre;
        do {
            // 需要修改的变量的当前值
            pre = this.getIntVolatile(obj, valueOffset);
            // CAS操作,成功返回true,失败返回false
        } while(!this.compareAndSwapInt(obj, valueOffset, pre, pre + i));
    
        return pre;
    }
    

    getAndAddInt() 方法被调用后,循环调用Java Native 方法 compareAndSwapInt(),如果修改成功则退出循环,返回被修改的变量修改前的值,如果修改不成功,则会一直重试直至成功修改。

    ABA问题

    从内存中读取和比较之间,变量的值可能被多次修改,最终回到原来的值,当前线程可能就会误以为此变量未修改。为了解决这类问题,可以引入 AtomicStampedReference,它的内部不仅维护了变量的值,还维护了修改的时间戳(或者可以看作是版本号),当进行 CAS 操作时,对象值和时间戳都满足期望值,修改才会成功。

    普通字段的原子操作

    原子包提供 AtomicIntegerFieldUpdaterAtomicReferenceFieldUpdater 等工具用于给普通资源提供原子操作,其使用方式如下:

    T t = new T();
    AtomicIntegerFieldUpdater<T> number = AtomicIntegerFieldUpdater.newUpdater(T.class, "number");
    number.incrementAndGet(t);
    

    使用这些工具需要注意:

    • 只能增强非 private 字段,即只能修改可见范围内的字段。
    • 被增强的字段必须要用 volatile 字段修饰,用于确保变量被正确的读取。
    • 由于 CAS 会通过对象实例中的偏移量直接进行赋值,所以增强不支持 static 字段。

    Unsafe类

    sun.misc.Unsafe 类封装了一些不安全的操作,主要是为了操作指针,例如:

    public native int getInt(Object obj, long offset);
    

    此方法的作用是获取到对象 obj 头部的偏移量为 offsetint 值。

    相关文章

      网友评论

          本文标题:并发编程(三):锁的优化

          本文链接:https://www.haomeiwen.com/subject/jkvqhqtx.html