高并发之——从架构师角度来深度探索多线程原子性问题的解决方案

前言

在《高并发之——你知道Java设计者是如何解决可见性和有序性问题的吗？》一文中，我们了解了Java是如何解决多线程之间的可见性和有序性问题。在《高并发之——你知道为何在32位多核CPU上执行long型变量的写操作会出现诡异的Bug问题吗？》我们已经明确了产生这个问题的根本原因是线程切换带来的原子性问题，而且在32位多核CPU上并发写64位数据类型的数据，基本上都会遇到这个问题。

如何保证原子性

那么，如何解决线程切换带来的原子性问题呢？答案是 保证多线程之间的互斥性。也就是说，在同一时刻只有一个线程在执行！ 如果我们能够保证对共享变量的修改是互斥的，那么，无论是单核CPU还是多核CPU，都能保证多线程之间的原子性了。

锁模型

说到线程之间的互斥，我们可以想到在并发编程中使用锁来保证线程之前的互斥性。我们可以将使用锁的模型简单的使用下图来表示。

在这里插入图片描述

我们可以将上图中受保护的资源，也就是需要多线程之间互斥执行的代码称为临界区。线程进入临界区之前，会首先尝试加锁操作lock()，如果加锁成功，则进入临界区执行临界区中的代码，则当前线程持有锁；如果加锁失败，就会等待，直到持有锁的线程释放锁后，当前线程获取到锁进入临界区；进入临界区的线程执行完代码后，会执行解锁操作unlock()。

其实，在这个锁模型中，我们忽略了一些非常重要的内容：那就是我们对什么东西加了锁？需要我们保护的资源又是什么呢？

改进的锁模型

在并发编程中对资源进行加锁操作时，我们需要明确对什么东西加了锁？而需要我们保护的资源又是什么？只有明确了这两点，才能更好的利用Java中的互斥锁。所以，我们需要将锁模型进行修改，修改后的锁模型如下图所示。

在这里插入图片描述

在改进的锁模型中，首先创建一把保护资源的锁，使用这个保护资源的锁进行加锁操作，然后进入临界区执行代码，最后进行解锁操作释放锁。其中，创建的保护资源的锁，就是对临界区特定的资源进行保护。

这里需要注意的是：我们在改进的锁模型中，特意将创建保护资源的锁用箭头指向了临界区中的受保护的资源。目的是为了说明特定资源的锁是为了保护特定的资源，如果一个资源的锁保护了其他的资源，那么就会出现诡异的Bug问题，这样的Bug非常不好调试，因为我们自身会觉得，我明明已经对代码进行了加锁操作，可为什么还会出现问题呢？如果出现了这种问题，你就要排查下你创建的锁，是不是真正要保护你需要保护的资源了。

Java中的synchronized锁

说起，Java中的synchronized锁，相信大家并不陌生了，synchronized关键字可以用来修饰方法，也可以用来修饰代码块。例如，下面的代码片段所示。

public class LockTest{
    //使用synchronized修饰非静态方法
    punlic synchronized void execute(){
        //临界区：受保护的资源
    }
    
    //使用synchronized修饰静态方法
    public synchronized static void submit(){
        //临界区：受保护的资源
    }
    
    //创建需要加锁的对象
    private Object obj = new Object();
    //修饰代码块
    public void run(){
        synchronized(obj){
            //临界区：受保护的资源
        }
    }
}

在上述的代码中，我们只是对方法（包括静态方法和非静态方法）和代码块使用了synchronized关键字，并没有执行lock()和unlock()操作。本质上，synchronized的加锁和解锁操作都是由JVM来完成的，Java编译器会在synchronized修饰的方法或代码块的前面自动加上加锁操作，而在其后面自动加上解锁操作。

在使用synchronized关键字加锁时，Java规定了一些隐式的加锁规则。

当使用synchronized关键字修饰静态方法时，锁定的是当前类的Class对象。
当使用synchronized关键字修饰非静态方法时，锁定的是当前实例对象this。
当使用synchronized关键字修饰代码块时，锁定的是实际传入的对象。

再次深究count+=1的问题

如果多个线程并发的对共享变量count执行加1操作，就会出现问题。此时，我们可以使用synchronized锁来尝试解决下这个问题。

例如，TestCount类中有两个方法，一个是getCount()方法，用来获取count的值；另一个是incrementCount()方法，用来给count值加1，并且incrementCount()方法使用synchronized关键字修饰，如下所示。

public class TestCount{
    private long count = 0L;
    public long getCount(){
        return count;
    }
    public synchronized void incrementCount(){
        count += 1;
    }
}

通过上面的代码，我们肯定的是incrementCount()方法被synchronized关键字修饰后，无论是单核CPU还是多核CPU，此时只有一个线程能够执行incrementCount()方法，所以，incrementCount()方法一定可以保证原子性。

这里，我们还要思考另一个问题：上面的代码是否存在可见性问题呢？回答这个问题之间，我们还需要看下《高并发之——你知道Java设计者是如何解决可见性和有序性问题的吗？》一文中，Happens-Before原则的【原则四】锁定规则：对一个锁的解锁操作 Happens-Before于后续对这个锁的加锁操作。

在上面的代码中，使用synchronized关键字修饰的incrementCount()方法是互斥的，也就是说，在同一时刻只有一个线程执行incrementCount()方法中的代码；而Happens-Before原则的【原则四】锁定规则：**对一个锁的解锁操作 Happens-Before于后续对这个锁的加锁操作。**指的是前一个线程的解锁操作对后一个线程的加锁操作可见，再综合Happens-Before原则的【原则三】传递规则：如果A Happens-Before B，并且B Happens-Before C，则A Happens-Before C。我们可以得出一个结论：前一个线程在临界区修改的共享变量（该操作在解锁之前），对后面进入这个临界区（该操作在加锁之后）的线程是可见的。

经过上面的分析，如果多个线程同时执行incrementCount()方法，是可以保证可见性的，也就是说，如果有100个线程同时执行incrementCount()方法，count变量的最终结果为100。

但是，还没完，TestCount类中还有一个getCount()方法，如果执行了incrementCount()方法，count变量的值对getCount()方法是可见的吗？

在《高并发之——你知道Java设计者是如何解决可见性和有序性问题的吗？》一文中，Happens-Before原则的【原则四】锁定规则： 对一个锁的解锁操作 Happens-Before于后续对这个锁的加锁操作。 只能保证后续对这个锁的加锁的可见性。而getCount()方法没有执行加锁操作，所以，无法保证incrementCount()方法的执行结果对getCount()方法可见。

如果需要保证incrementCount()方法的执行结果对getCount()方法可见，我们也需要为getCount()方法使用synchronized关键字修饰。所以，TestCount类的代码如下所示。

public class TestCount{
    private long count = 0L;
    public synchronized long getCount(){
        return count;
    }
    public synchronized void incrementCount(){
        count += 1;
    }
}

此时，为getCount()方法也添加了synchronized锁，而且getCount()方法和incrementCount()方法锁定的都是this对象，线程进入getCount()方法和incrementCount()方法时，必须先获得this这把锁，所以，getCount()方法和incrementCount()方法是互斥的。也就是说，此时，incrementCount()方法的执行结果对getCount()方法可见。

我们也可以简单的使用下图来表示这个互斥的逻辑。

在这里插入图片描述

修改测试用例

我们将上面的测试代码稍作修改，将count的修改为静态变量，将incrementCount()方法修改为静态方法。此时的代码如下所示。

public class TestCount{
    private static long count = 0L;
    public synchronized long getCount(){
        return count;
    }
    public synchronized static void incrementCount(){
        count += 1;
    }
}

那么，问题来了，getCount()方法和incrementCount()方法是否存在并发问题呢？

接下来，我们一起分析下这段代码：其实这段代码中是在用两个不同的锁来保护同一个资源count，两个锁分别为this对象和TestCount.class对象。也就是说，getCount()方法和incrementCount()方法获取的是两个不同的锁，二者的临界区没有互斥关系，incrementCount()方法对count变量的修改无法保证对getCount()方法的可见性。所以，修改后的代码会存在并发问题。

我们也可以使用下图来简单的表示这个逻辑。

在这里插入图片描述