logo头像

BUG本天成，妙手偶得之

探索JAVA并发 - 如何减少锁的竞争

并发编程 并发 线程 锁 2019/08/04

锁的竞争会限制代码的可伸缩性，在并发编程时通过一些手段有意地减少锁竞争，可以让程序有更好的表现。

所谓可伸缩性，即当增加计算资源(如CPU、内存、带宽等)时，程序的吞吐量或处理能力会相应增加。这个时候，我们当然希望增加的效果越明显越好，不过如果锁竞争太严重，可伸缩性会大打折扣。

缩小锁的范围

当某个方法需要操作一个线程不安全的共享资源时，最简单的办法就是给方法加上synchronized，这样一来这个方法只能同时有一个线程在执行，满满的安全感。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class Counter {

    private volatile int value;

    public synchronized void incr(int n) {
        System.out.println("i will incr " + n);
        try {
            // 这个小小的睡眠代表一些线程安全的操作
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("i am ready");
        value = value + n;
        System.out.println("i incr " + n);
    }

    //...
}

上述示例的同步方法中有个耗时1秒的准备过程，这个过程是线程安全，但由于身在同步方法中，众线程不得不排队睡觉。这时候不管增加多少个线程，程序该睡多久还是睡多久。若是把这个步骤从同步代码块中移除，大家就能并发睡觉。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public class Counter {

    private volatile int value;

    public void incr(int n) {
        System.out.println("i will incr " + n);
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("i am ready");
        synchronized (this) {
            // 只有这行代码是不能并发执行的
            value = value + n;
        }
        System.out.println("i incr " + n);
    }

    //...
}

通过上述示例就让线程在持有锁时需要执行的指令尽可能小，并发的效率更高了。

但如果多个线程不安全的操作之间隔着一些安全的耗时操作，是分别使用同步块，还是用一个同步块，并不能说谁一定好。因为同步代码块也是有额外性能开销的，比起同步执行无关的操作，不一定划算，还是需要通过测试，用数据说话。

减小锁粒度 - 锁分解

如果一个锁要用来保护多个相互独立的资源，可以考虑用多个锁分别保护某个资源，即锁分解。

如此这般，就不用在只需要操作一个资源时，把其它不相干资源也卷入其中，导致其它想用资源的线程看着这个线程占着茅坑不拉💩（或者占着整个厕所更恰当？）。

使用一个锁保护多个资源

下面这个示例，不管想操作哪个资源，都会把所有资源都锁住。

1
2
3
4
5
6
7
8
9
10
11
12
public class Counter {

    private volatile int src1;
    private volatile int src2;
    private volatile int src3;

    public synchronized void incr(int src1, int src2, int src3) {
        this.src1 += src1;
        this.src2 += src2;
        this.src3 += src3;
    }
}

一个锁保护一个资源

通过锁分解，每个资源有它自己的锁，可以单独操作。如果想兼容旧代码也是可以的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
public class Counter {

    private volatile int src1;
    private volatile int src2;
    private volatile int src3;

    // 兼容旧代码，不用修改调用的地方
    public void incr(int src1, int src2, int src3) {
        if (src1 != 0) {
            incrSrc1(src1);
        }
        if (src2 != 0) {
            incrSrc2(src2);
        }
        if (src3 != 0) {
            incrSrc3(src3);
        }
    }

    public synchronized void incrSrc1(int n) {
        this.src1 += n;
    }

    public synchronized void incrSrc2(int n) {
        this.src2 += n;
    }

    public synchronized void incrSrc3(int n) {
        this.src3 += n;
    }
}

减小锁粒度 - 锁分段

锁分段是锁分解的进一步扩展，对于一组资源集合，可以把资源分为多个小组，每个小组用一个锁来保护，比如我们熟知的ConcurrentHashMap(java8中已经不再使用分段锁了，改为synchronized + cas)。

用的java8，不能分析一波ConcurrentHashMap的分段锁了，写个例子。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
public class Counter {

    private int[] src;

    private Object[] locks;

    /**
     * @param nSrc   资源数量
     * @param nLocks 分成几段锁
     */
    public Counter(int nSrc, int nLocks) {
        src = new int[nSrc];
        locks = new Object[nLocks];
        for (int i = 0; i < nLocks; i++) {
            locks[i] = new Object();
        }
    }

    /**
     * @param idx 要访问的资源序号
     * @param n   增量
     */
    public void incr(int idx, int n) {
        // 根据一定规则（比如hash）找到目标资源归谁管
        synchronized (locks[idx % locks.length]) {
            src[idx] += n;
        }
    }

    //...
}

避免热点域

上面的例子通过锁分段减小了锁的竞争，因为访问不同段的资源时，需要的锁是不同的，竞争压力也随之减小。毕竟比起10个人竞争一个名额，10个人竞争5个名额的话大家冲突不会那么大。

但是，依然会存在需要同时访问多个资源的情况，比如计算当前所有资源的总和，这个时候锁的粒度就很难降低了。当锁的粒度无法降低时，为了减少等待的时间，机智的程序员往往会用一些优化措施，比如把计算的结果缓存起来，热点域就随之被引入了。

依然以上面的代码为例，增加一个计数器来记录资源的变化，每个资源变化都修改计数器，这样当需要统计所有资源时，只需要返回计数器的值就行了。这个计数器就是一个热点域。

全局计数器引入热点域

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
public class Counter {

    private int[] src;

    private Object[] locks;

    // 全局计数器
    private volatile int count;

    /**
     * @param nSrc   资源数量
     * @param nLocks 分成几段锁
     */
    public Counter(int nSrc, int nLocks) {
        src = new int[nSrc];
        locks = new Object[nLocks];
        for (int i = 0; i < nLocks; i++) {
            locks[i] = new Object();
        }
    }

    /**
     * @param idx 要访问的资源序号
     * @param n   增量
     */
    public void incr(int idx, int n) {
        // 根据一定规则（比如hash）找到目标资源归谁管
        synchronized (locks[idx % locks.length]) {
            src[idx] += n;
        }
        // 不管操作哪个分段的资源，计数时都竞争同一个锁
        synchronized (this) {
            count++;
        }
    }

    // 直接返回缓存的值
    public int count() {
        return count;
    }
    
    //...
}

分段计数器避免热点域

上述通过全局计数器缓存计算的结果虽然让获取计数方法的开销从O(n)变成了O(1)，但却引入了热点域，每次访问资源都要访问同一个计数器，这时候对可伸缩性就产生了一定影响，因为不管怎么增加并发资源，在访问计数器时都会有竞争。

ConcurrentHashMap中的做法是为每段数据单独维护一个计数器，然后获取总数时再对所有分段的计数做一个累加（真实情况会更复杂，比如ConcurrentHashMap会计算两次modCount并比较，如果不相等表示计算过程有变动，就会给所有分段加锁再累加）。

对全局计数器的例子做了简单的改写，去掉了热点域。但换个角度，这样却也让获取总数的方法性能受到了影响，因此实际操作时还需要根据业务场景权衡利弊。鱼和熊掌不可兼得，虽然很想说我全都要。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
public class Counter {

    private int[] src;

    private Lock[] locks;

    /**
     * @param nSrc   资源数量
     * @param nLocks 分成几段锁
     */
    public Counter(int nSrc, int nLocks) {
        src = new int[nSrc];
        locks = new Lock[nLocks];
        for (int i = 0; i < nLocks; i++) {
            locks[i] = new Lock();
        }
    }

    /**
     * @param idx 要访问的资源序号
     * @param n   增量
     */
    public void incr(int idx, int n) {
        // 根据一定规则（比如hash）找到目标资源归谁管
        int lockIdx = idx % locks.length;
        synchronized (locks[lockIdx]) {
            src[idx] += n;
            locks[lockIdx].count++;
        }
    }

    public int count() {
        // 就不像ConcurrentHashMap那么严谨了，意思一下
        int sum = 0;
        for (Lock lock : locks) {
            sum += lock.count;
        }
        return sum;
    }

    // 锁
    private static class Lock {
        volatile int count;
    }

    //...
}

替代独占锁

有时候可以选择放弃使用独占锁，改用更加友好的并发方式。

读写锁

读写锁(ReentrantReadWriteLock)维护了一对锁（一个读锁和一个写锁），通过分离读锁和写锁，使得并发性相比一般的排他锁有了很大提升。

在读比写多的场景下，使用读写锁往往比一般的独占锁有更好的性能表现。

原子变量

原子变量可以降低热点域的更新开销，但无法消除。

java.util.concurrent.atomic.* 包下有一些对应基本类型的原子变量类，使用了操作系统底层的能力，使用CAS(比较并交换，compare-and-swap)更新值。

检测CPU利用率

通过检测CPU的利用率，分析出可能限制程序性能的点，做出相应措施。

CPU利用率不均匀

多核的机器上，如果某个CPU忙成🐶，其它CPU就在旁边喊666，那证明当前程序的的大部分计算工作都由一小组线程在做。这时候可以考虑把这部分工作多拆分几个线程来做（比如参考CPU数）。

一人干活多人围观

CPU利用不充分

和CPU利用率不均匀的区别在于，他可能是均匀的，就是大家都在磨洋工。

磨洋工

CPU利用不充分一般有以下几个原因：

  • 负载不均衡：僧多粥少，一人能分点事做就不错了。这种情况可以考虑增加工作量，不要怜惜它们；
  • I/O密集：程序就不是CPU密集型的，这种情况可以想办法增加I/O效率（比如增加任务/并发、提高带宽），以此来使CPU利用率得到一定提高；
  • 外部依赖限制：比如调用其它服务等待太久，瓶颈在别人那。可以像I/O密集那样自我提升，实力足够的话也可以改变别人；
  • 锁竞争：本文探索的主题，可以在线程转储信息中寻找等待锁的地方，因地制宜。

CPU忙碌

闲也不行，忙也不行，你还要我怎样？要怎样！

如果CPU们已经很忙了，证明工作还是很饱和的，如果还想提高效率，可以考虑加派CPU了。不过并不是增加了CPU效率就一定会提升，增加CPU后可能又会变成上面两种情况，这是一个循环，当循环停止（无法通过上面的方式得到有效优化），我们的应用基本上达到一个所谓“极限”了。

不使用对象池

线程池的应用范围很广，比如各种连接池。当应用创建比较耗时、耗资源时也常用对象池技术。但有时候，高并发下操作对象池带来的性能损耗（线程同步、锁竞争、阻塞…）可能比起在需要的时候直接new一直对象更大。

通常，对象分配操作的开销比线程同步的开销更低。

总结

总的来说有3种方式可以降低锁的竞争程度，上面的操作基本都是围绕这3种方式来做的：

  1. 减少锁的持有时间（如：缩小锁范围）
  2. 降低锁的请求频率（如：锁分解，锁分段）
  3. 使用带有协调机制的独占锁（如：分段锁，读写锁）

参考书籍: 《Java并发编程实战》

转载声明：商业转载请联系作者获得授权,非商业转载请注明出处 © ACUPT.CN
访问量:   |   访客数:
Copyright © 2018 | Powered by Hexo | Theme by Snippet