(Java 高并发程序设计) 一篇文章带你深入了解多线程中的隐蔽错误

﹏ヽ暗。殇╰゛Y 2022-12-21 10:56 127阅读 0赞

作为一名软件开发人员，修复程序BUG应该说是日常的基本工作之一。作为Java程序员，也许你经常会被抛出的一大堆的异常堆栈所困扰，因为这可能预示着你又有工作可做了。如果程序出错，你看到了异常堆栈，你应该感到格外的高兴，因为这也意味着你极有可能可以在两分钟内修复这个问题（当然，并不是所有的异常都是错误）。最可怕的情况是：系统没有任何异常表现，没有日志，也没有堆栈，但是却给出了一个错误的执行结果，这种情况下，才真会让人头疼。

### 文章目录 ###

*   *  一、无提示的错误案例
     *  二、并发下的 ArrayList
     *  三、并发下诡异的HashMap
     *  四、错误的加锁

## 一、无提示的错误案例 ##

我在这里想给出一个系统运行错误，却没有任何提示的案例，让大家体会一下这种情况的可怕之处。在任何一个业务系统中，求平均值应该是一种极其常见的操作。这里就以求两个整数的平均值为例。请看下面的代码：

public class TestClass { 
        public static void main(String[] args) throws InterruptedException { 
            int v1 = 1073741827;
            int v2 = 1431655768;
            System.out.println("v1=" + v1);
            System.out.println("v2=" + v2);
            int ave = (v1 + v2) / 2;
            System.out.println("ave=" + ave);
        }
    }

上述代码中，加粗部分试图计算v1和v2的均值。乍看之下，没有什么问题。目测v1和v2的当前值，估计两者的平均值大约为12亿。但如果你执行代码，却会得到以下输出：

![在这里插入图片描述][20201116105046324.png_pic_center]  
你一定会非常吃惊，均值竟然是一个负数！但只要你有一点钻研精神，就会马上有所觉悟。这是一个典型的溢出问题，v1+v2的结果导致了int的溢出。把这个问题单独拿出来研究，也许你不会有特别的感触，但是，一旦这个问题发生在一个复杂系统的内部，由于复杂的业务逻辑很可能掩盖这个看起来微不足道的问题，再加上程序自始至终没有任何日志或异常，如果你运气不是太好，那么这类问题不让你耗上几个通宵，恐怕也难有眉目。

所以，我们自然会害怕这些问题，我们也希望在程序异常时，能够得到一个异常或者相关的日志。但是，非常不幸的是，错误地使用并行非常容易产生这类问题。它们难觅踪影，就如同幽灵一般。

## 二、并发下的 ArrayList ##

`ArrayList`是一个线程不安全的容器。如果在多线程中使用`ArrayList`，可能会导致程序出错。究竟可能引起哪些问题呢？试看下面的代码：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmh1YWliZWlhbg_size_16_color_FFFFFF_t_70_pic_center]  
上述代码中，t1和t2两个线程同时向一个ArrayList中添加容器。它们各添加100万个元素，因此我们期望最后可以有200万个元素在ArrayList中。但如果执行这段代码，则可能得到三种结果。  
第一，程序正常结束，ArrayList的最终大小确实200万。这说明即使并行程序有问题，也未必会每次都表现出来。

第二，程序抛出异常。

![在这里插入图片描述][20201116110428393.png_pic_center]  
这是因为ArrayList在扩容过程中，内部一致性被破坏，但由于没有锁的保护，另外一个线程访问到了不一致的内部状态，导致出现越界问题。

第三，出现了一个非常隐蔽的错误，比如打印如下值作为`ArrayList`的大小。

![在这里插入图片描述][20201116110508235.png_pic_center]  
这是由于多线程访问冲突，使得保存容器大小的变量被多线程不正常的访问，同时两个线程也对ArrayList中的同一个位置进行赋值导致的。如果出现这种问题，那么很不幸，你就得到了一个没有错误提示的错误。并且，它们未必是可以复现的。

注意：改进的方法很简单，使用线程安全的Vector代替ArrayList即可

## 三、并发下诡异的HashMap ##

`HashMap`同样不是线程安全的。当你使用多线程访问`HashMap`时，也可能会遇到意想不到的错误。不过和`ArrayList`不同，`HashMap`的问题似乎更加诡异。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmh1YWliZWlhbg_size_16_color_FFFFFF_t_70_pic_center 1]  
上述代码使用t1和t2两个线程同时对`HashMap`进行`put()`方法操作。如果一切正常，则得到的`map.size()`方法就是100 000。但实际上，你可能会得到以下三种情况（注意，这里使用JDK 7进行试验）。

第一，程序正常结束，并且结果也是符合预期的，HashMap的大小为100 000。

第二，程序正常结束，但结果不符合预期，而是一个小于100 000的数字，比如98868。

第三，程序永远无法结束。

前两种可能和ArrayList的情况非常类似，因此不必过多解释。而对于第三种情况，如果是第一次看到，我想大家一定会觉得特别惊讶，因为看似非常正常的程序，怎么可能就结束不了呢？

这非常类似死循环的情况。使用jstack工具显示程序的线程信息，如下所示。其中jps可以显示当前系统中所有的Java进程，而jstack可以打印给定Java进程的内部线程及其堆栈。

![在这里插入图片描述][202011161109105.png_pic_center]  
我们会很容易找到 t1、t2 和 main 线程。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmh1YWliZWlhbg_size_16_color_FFFFFF_t_70_pic_center 2]  
可以看到，主线程main正处于等待状态，并且这个等待是由于join()方法引起的，符合我们的预期。而t1和t2两个线程都处于Runnable状态，并且当前执行语句为HashMap.put()方法。查看put()方法的第498行代码，如下所示：

![在这里插入图片描述][20201116111139233.png_pic_center]  
可以看到，当前这两个线程正在遍历`HashMap`的内部数据。当前所处循环乍看之下是一个迭代遍历，就如同遍历一个链表一样。但在此时此刻，由于多线程的冲突，这个链表的结构已经遭到了破坏，链表成环了！当链表成环时，上述的迭代就等同于一个死循环，图2.9展示了最简单的一种环状结构，key1和key2互为对方的next元素。此时，通过next引用遍历，将形成死循环。

![在这里插入图片描述][20201116111232640.png_pic_center]

死循环的问题一旦出现，着实可以让你郁闷一下，但这个死循环的问题在JDK 8中已经不存在了。由于JDK 8对HashMap的内部实现做了大规模的调整，因此规避了这个问题。即使这样，贸然在多线程环境下使用`HashMap`依然会导致内部数据不一致。最简单的解决方案就是使用`ConcurrentHashMap`代替`HashMap`

## 四、错误的加锁 ##

在进行多线程同步时，加锁是保证线程安全的重要手段之一。但加锁也必须是合理的。假设我们需要一个计数器，这个计数器会被多个线程同时访问。为了确保数据正确性，我们自然需要对计数器加锁，因此，就有了以下代码：

class MyThread implements Runnable{ 
        Integer i = 0;
        @Override
        public void run(){ //覆写 run() 方法
            for(int j=0;j<100000;j++){ 
                synchronized (i){ 
                    i++;
                }
            }
        }
    }
    
    public class Test{ 
        public static void main(String[] args) throws InterruptedException { 
            MyThread mt = new MyThread();
            Thread t1 = new Thread(mt);
            Thread t2 = new Thread(mt);
            t1.start();t2.start();
            t1.join();t2.join();
            System.out.println(mt.i);
        }
    }

为了保证计数器i的正确性，每次对i自增前，都先获得i的锁，以此保证i是线程安全的。从逻辑上看，这似乎并没有什么不对，所以，我们就满怀信心地尝试运行代码。如果一切正常，那么这段代码应该返回200000（每个线程各累加100000次）。但结果却得到了一个比200000小很多的数字

![在这里插入图片描述][20201116112637730.png_pic_center]

这说明什么问题呢？一定是这段程序并没有真正做到线程安全！但把锁加在变量i上又有什么问题呢？似乎加锁的逻辑也是无懈可击的。

要解释这个问题，得从Integer说起。在Java中，Integer属于不变对象，即对象一旦被创建，就不可能被修改。也就是说，如果你有一个Integer对象代表1，那么它就永远表示1，你不可能修改Integer对象的值，使它为2。那如果你需要2怎么办呢？也很简单，新建一个Integer对象，并让它表示2即可。

如果我们使用javap命令反编译这段代码的run()方法，我们可以看到：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmh1YWliZWlhbg_size_16_color_FFFFFF_t_70_pic_center 3]  
第19～22行（对字节码来说，这是偏移量，这里简称为行）代码实际上使用了`Integer.valueOf()`方法新建了一个新的Integer对象，并将它赋值给变量i。也就是说，i++在真实执行时变成了：

![进一步查看Integer.valueOf()方法，我们可以看到：][Integer.valueOf]

`Integer.valueOf()`实际上是一个工厂方法，它会倾向于返回一个代表指定数值的Integer对象实例。因此，`i++`的本质是创建一个新的`Integer`对象，并将它的引用赋值给i。

由于在多个线程间，并不一定能够看到同一个i对象（因为i对象一直在变），因此，两个线程每次加锁可能都加在了不同的对象实例上，从而导致对临界区代码控制出现问题。

修正这个问题也很容易，只要改为下面的代码：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmh1YWliZWlhbg_size_16_color_FFFFFF_t_70_pic_center 4]

[20201116105046324.png_pic_center]: /images/20221120/95e52cf0aa7846539a7073ca22bd39d6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmh1YWliZWlhbg_size_16_color_FFFFFF_t_70_pic_center]: /images/20221120/2271cb0a757f4b93a59421115dc1cc72.png
[20201116110428393.png_pic_center]: /images/20221120/809afea0e8fe4d23820b9e517cd18799.png
[20201116110508235.png_pic_center]: /images/20221120/a96668454f694712a11abb197cb04749.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmh1YWliZWlhbg_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221120/09c7f9125dca4c9ab1bb005d8263b1e8.png
[202011161109105.png_pic_center]: /images/20221120/bb89cf18067c4914a17a34e21cc00cd2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmh1YWliZWlhbg_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221120/8b0b98f019f1444e8fe92c2486d398a8.png
[20201116111139233.png_pic_center]: /images/20221120/7487c0452fbd4a1d9ad15066895e5498.png
[20201116111232640.png_pic_center]: /images/20221120/cfaefb6b37a84758b9e01d92bc0d617f.png
[20201116112637730.png_pic_center]: /images/20221120/357b043b8d1f4963a5b80b556dba6659.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmh1YWliZWlhbg_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221120/a3fa16fe04e645b4a3235d7bdb6f7126.png
[Integer.valueOf]: /images/20221120/bd3bfb91e0ed4789a1575af345d7ecba.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmh1YWliZWlhbg_size_16_color_FFFFFF_t_70_pic_center 4]: https://img-blog.csdnimg.cn/20201116112826757.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmh1YWliZWlhbg==,size_16,color_FFFFFF,t_70#pic_center