一次 parallelStream 引发的线程安全问题思考

╰+攻爆jí腚メ 2023-02-20 06:41 19阅读 0赞

## 前言 ##

之前 业务开发中 parallelStream用的很少，书中对他的介绍印象中也停留在线程安全中，所以在使用parallelStream的中途就没有考虑线程安全问题，然后就出现了如下诡异的线程安全问题

## 问题代码 ##

List<ClearProduct> clears = Lists.newArrayListWithExpectedSize(sizeCount);
            source.stream().parallel().forEach(s -> { 
                //elasticsearch 查询返回结果集
                ClearProduct clearProduct = clearProduct(s, print);
                if (ObjectUtil.isNotEmpty(clearProduct)) { 
                    clears.add(clearProduct);
                }
            });
            if (CollectionUtils.isNotEmpty(clears)) { 
                Lists.partition(clears, 1000).parallelStream().forEach(s -> clearProductDao.saveBatch(s));
            }

开始以为 clearProduct方法由线程安全问题，仔细看了下发现不过是普通的业务代码，问题出在哪呢？  
仔细发现是 clears 这个不安全的List集合导致的

我们通过看ArrayList的源码发现他的 add 方法如下

public boolean add(E e) { 
    
        /** * 添加一个元素时，做了如下两步操作 * 1.判断列表的capacity容量是否足够，是否需要扩容 * 2.真正将元素放在列表的元素数组里面 */
        ensureCapacityInternal(size + 1);  // Increments modCount!!
        elementData[size++] = e;
        return true;
    }

ensureCapacityInternal()这个方法的详细代码我们可以暂时不看，它的作用就是判断如果将当前的新元素加到列表后面，列表的elementData数组的大小是否满足，如果size + 1的这个需求长度大于了elementData这个数组的长度，那么就要对这个数组进行扩容。

由此看到add元素时，实际做了两个大的步骤：

判断elementData数组容量是否满足需求  
在elementData对应位置上设置值  
这样也就出现了第一个导致线程不安全的隐患，在多个线程进行add操作时可能会导致elementData数组越界。具体逻辑如下：

列表大小为9，即size=9  
线程A开始进入add方法，这时它获取到size的值为9，调用ensureCapacityInternal方法进行容量判断。  
线程B此时也进入add方法，它获取到size的值也为9，也开始调用ensureCapacityInternal方法。  
线程A发现需求大小为10，而elementData的大小就为10，可以容纳。于是它不再扩容，返回。  
线程B也发现需求大小为10，也可以容纳，返回。  
线程A开始进行设置值操作， elementData\[size++\] = e 操作。此时size变为10。  
线程B也开始进行设置值操作，它尝试设置elementData\[10\] = e，而elementData没有进行过扩容，它的下标最大为9。于是此时会报出一个数组越界的异常ArrayIndexOutOfBoundsException.  
另外第二步 elementData\[size++\] = e 设置值的操作同样会导致线程不安全。从这儿可以看出，这步操作也不是一个原子操作，它由如下两步操作构成：

elementData\[size\] = e;  
size = size + 1;  
在单线程执行这两条代码时没有任何问题，但是当多线程环境下执行时，可能就会发生一个线程的值覆盖另一个线程添加的值，具体逻辑如下：

列表大小为0，即size=0  
线程A开始添加一个元素，值为A。此时它执行第一条操作，将A放在了elementData下标为0的位置上。  
接着线程B刚好也要开始添加一个值为B的元素，且走到了第一步操作。此时线程B获取到size的值依然为0，于是它将B也放在了elementData下标为0的位置上。  
线程A开始将size的值增加为1  
线程B开始将size的值增加为2  
这样线程AB执行完毕后，理想中情况为size为2，elementData下标0的位置为A，下标1的位置为B。而实际情况变成了size为2，elementData下标为0的位置变成了B，下标1的位置上什么都没有。并且后续除非使用set方法修改此位置的值，否则将一直为null，因为size为2，添加元素时会从下标为2的位置上开始。

*  总结

> 根本原因是，两个线程调传入了同一个ArrayList，这个参数在jvm内以地址方式存在栈内，指向堆区的（size和object\[\]数组），本质上调用  
> ArrayList add() \{ ensureCapacityInternal(size + 1); // Increments modCount!! elementData\[size++\] = e; return true; \}  
> 时，是通过this.size获取堆内size，这时候两个线程操作同一个堆内变量，就会出现读取时的值是对的，但是使用时值已经被修改了，在此this.size，就是脏数据

## 解决方式 ##

解决很简单，要么给 add 方法加锁 要么把ArrayList变为线程安全的集合

List<ClearProduct> clears = Collections.synchronizedList(Lists.newArrayListWithExpectedSize(sizeCount));
    //或者
     synchronized (this) { 
                    clears.add(clearProduct);
                }

Collections.synchronizedList()底层也是用 synchronized 实现的，给你返回的 SynchronizedCollection的方法都是全部加锁了  
![在这里插入图片描述][20200629103819163.png]

## 案例复现 ##

这里提供一个简单的案例给大家去复现

private static List<Integer> list1 = new ArrayList<>();
        private static List<Integer> list2 = new ArrayList<>();
        private static List<Integer> list3 = new ArrayList<>();
        private static Lock lock = new ReentrantLock();
    
        public static void main(String[] args) { 
            IntStream.range(0, 100000).forEach(list1::add);
    
            IntStream.range(0, 100000).parallel().forEach(list2::add);
    
            IntStream.range(0, 100000).forEach(i -> { 
                lock.lock();
                try { 
                    list3.add(i);
                }finally { 
                    lock.unlock();
                }
            });
    
            System.out.println("串行执行的大小：" + list1.size());
            System.out.println("并行执行的大小：" + list2.size());
            System.out.println("加锁并行执行的大小：" + list3.size());
        }

> 需要多试几次

*  参考  
    https://blog.csdn.net/u012859681/article/details/78206494  
    https://www.cnblogs.com/puyangsky/p/7608741.html

[20200629103819163.png]: https://img-blog.csdnimg.cn/20200629103819163.png