parallelStream() 踩坑指南，出现null元素，输出list的size不符合预期

1. 使用parallelStream()出现的一些奇怪情形

有时候，为了使用多线程加快代码运行速度，我们会使用parallelStream()来代替stream()，我们先来看一段示例代码：

List<Integer> integerList = new ArrayList<>();
for (int i = 0; i < 100; i++) {
		integerList.add(i);
}
List<Integer> list = new ArrayList<>();
integerList.parallelStream().forEach(list::add);
System.out.println(list);

我们的预期是，输出的list能够是0-99的一共99个数字，顺序不限；

然而，人生就是这样，就连我们如此简单的预期，也往往无法得到满足。。。

经过多次运行代码，会发现一些很奇怪的现象：

1. 输出的list的size()不符合预期，有时候是100，有时候是99，甚至是97等；
2. 输出的list中有时含有null元素，数量不定，有时甚至达到十几个之多；
3. 有时会出现IndexOutOfBounds异常；
4. 由于以上问题的出现，可能会导致业务代码中出现NPE；

2. 原因探究

为什么会出现以上问题呢？我们来逐个分析一下各个问题出现的原因。

2.1. 输出的list的size()不符合预期

1. 【现象】输出的list的size()不符合预期，有时候会比预想的要少，也就是出现了元素丢失的现象；

2. 【原因】

   1. 我们来看一下ArrayList的add方法：

         /**
          * Appends the specified element to the end of this list.
          *
          * @param e element to be appended to this list
          * @return true (as specified by {@link Collection#add})
          */
         public boolean add(E e) {
             ensureCapacityInternal(size + 1);  // Increments modCount!!
             elementData[size++] = e;
             return true;
         }
      

   2. add方法是分两步进行的，第一步是通过ensureCapacityInternal(size + 1); 进行扩容，第二步是通过elementData[size++] = e;添加新元素。在添加新元素时，先读取size的值，然后执行elementData[size] = e;，将e添加到size的位置，在执行size++;，有三个步骤，并不是原子操作。

   3. 因此存在内存可见性问题。当线程 A 从内存读取 size 后，可能这是还没来得及继续执行，线程B就迅速地从内存中读取了size，并且将5写入到了size处，然后size++，然后线程A才将6写入到了size处，将 size 加 1，然后写入内存。在这种情况下，线程B的更新就丢失了，出现了元素丢失的现象。

   2.2. 输出的list中有时含有null元素

   1. 【现象】输出的list中有时含有null元素，数量不定，有时甚至达到十几个之多；

   2. 【原因】

      1. null 元素产生跟元素数据丢失类似，也是由于elementData[size++] = e;这一步并不是原子操作导致的。
      2. 假设存在三个线程，线程A、线程B、线程C。三个线程同时开始执行，初始 size 值为 1。
      3. 线程A首先读取size值为1，然后线程B读取size值为1，然后线程C读取size为1，然后线程B将数据添加到size位置，然后线程A将数据也添加到了size位置，覆盖了B的更新，然后线程A将size更新为2；然后线程B将size更新为3；然后线程C将数据更新到size也就是3的位置，然后将size更新为4；这样2的位置就是null了。

   2.3. 有时会出现IndexOutOfBounds异常；

   1. 【现象】有时会出现IndexOutOfBounds异常；

   2. 【原因】

      1. 由于ArrayList的add方法，第一步是通过ensureCapacityInternal(size + 1); 进行扩容，第二步是通过elementData[size++] = e;添加新元素。
      2. 如果线程A已经进行了扩容，但还没添加新元素，此时线程B也进行了扩容（注意此时扩容是无效的，因为在线程B看来，目前的size还是原来的size），然后线程A读取size，将数据更新到size的位置，size++后结束；线程B读取size，发现已经超出了数组的界限，抛出IndexOutOfBounds异常；

3. 解决方法

可以使用线程安全的List：

List<Integer> list = Collections.synchronizedList(new ArrayList<>());

或者

List<Integer> list = new CopyOnWriteArrayList<>();

4. 参考资料

在The Java™ Tutorials Parallelism章节中，有一个部分叫做Stateful Lambda Expressions。这部分告诉我们，不要使用Stateful Lambda Expressions，比如

e -> { parallelStorage.add(e); return e; }

因为每次运行代码时，其结果可能会有所不同；

Note: This example invokes the method synchronizedList so that the List parallelStorage is thread-safe. Remember that collections are not thread-safe. This means that multiple threads should not access a particular collection at the same time. Suppose that you do not invoke the method synchronizedList when creating parallelStorage:

List parallelStorage = new ArrayList<>();

The example behaves erratically because multiple threads access and modify parallelStorage without a mechanism like synchronization to schedule when a particular thread may access the List instance. Consequently, the example could print output similar to the following:

Parallel stream:
8 7 6 5 4 3 2 1
null 3 5 4 7 8 1 2

并且该文章已经指出，如果我们使用的集合不是线程安全的，那么就会得到一个不稳定的实例，可能会出现null元素。