多线程场景下如何使用 ArrayList

ArrayList 不是线程安全的，这点很多人都知道，但是线程不安全的原因及表现，怎么在多线程情况下使用ArrayList，可能不是很清楚，这里总结一下。

1. 源码分析

查看 ArrayList 的 add 操作源码如下：

    /**
     * Appends the specified element to the end of this list.
     *
     * @param e element to be appended to this list
     * @return <tt>true</tt> (as specified by {@link Collection#add})
     */
    public boolean add(E e) {
　　　　  // 判断列表的capacity容量是否足够，是否需要扩容
        ensureCapacityInternal(size + 1);  // Increments modCount!!
        // 将元素添加进列表的元素数组里面
　　　　  elementData[size++] = e;
        return true;
    }

源码中涉及的几个元素及方法定义如下：

      /**
     * Default initial capacity.
     */
    private static final int DEFAULT_CAPACITY = 10;
　　  /**
　　  * 列表元素集合数组
     * 如果新建ArrayList对象时没有指定大小，那么会将EMPTY_ELEMENTDATA赋值给elementData，
     * 并在第一次添加元素时，将列表容量设置为DEFAULT_CAPACITY
　　　*/
    transient Object[] elementData; 

    /**
　　 *列表大小，elementData中存储的元素个数
　　 */
    private int size;

  　private void ensureCapacityInternal(int minCapacity) {
        if (elementData == DEFAULTCAPACITY_EMPTY_ELEMENTDATA) {
            minCapacity = Math.max(DEFAULT_CAPACITY, minCapacity);
        }

        ensureExplicitCapacity(minCapacity);
    }

    private void ensureExplicitCapacity(int minCapacity) {
        modCount++;

        // overflow-conscious code
        if (minCapacity - elementData.length > 0)
            grow(minCapacity);
    }
    private void grow(int minCapacity) {
        // overflow-conscious code
        int oldCapacity = elementData.length;
        int newCapacity = oldCapacity + (oldCapacity >> 1);
        if (newCapacity - minCapacity < 0)
            newCapacity = minCapacity;
        if (newCapacity - MAX_ARRAY_SIZE > 0)
            newCapacity = hugeCapacity(minCapacity);
        // minCapacity is usually close to size, so this is a win:
        elementData = Arrays.copyOf(elementData, newCapacity);
    }

通过源码可以看出：ArrayList的实现主要就是用了一个Object的数组，用来保存所有的元素，以及一个size变量用来保存当前数组中已经添加了多少元素。

执行add方法时，主要分为两步：

  • 首先判断elementData数组容量是否满足需求——》判断如果将当前的新元素加到列表后面，列表的elementData数组的大小是否满足，如果size + 1的这个需求长度大于了elementData这个数组的长度，那么就要对这个数组进行扩容；
  • 之后在elementData对应位置上设置元素的值。

2. 线程不安全的两种体现

2.1 数组越界异常 ArrayIndexOutOfBoundsException

由于ArrayList添加元素是如上面分两步进行，可以看出第一个不安全的隐患，在多个线程进行add操作时可能会导致elementData数组越界。

具体逻辑如下：

  1. 列表大小为9，即size=9
  2. 线程A开始进入add方法，这时它获取到size的值为9，调用ensureCapacityInternal方法进行容量判断。
  3. 线程B此时也进入add方法，它获取到size的值也为9，也开始调用ensureCapacityInternal方法。
  4. 线程A发现需求大小为10，而elementData的大小就为10，可以容纳。于是它不再扩容，返回。
  5. 线程B也发现需求大小为10，也可以容纳，返回。
  6. 线程A开始进行设置值操作， elementData[size++] = e 操作。此时size变为10。
  7. 线程B也开始进行设置值操作，它尝试设置elementData[10] = e，而elementData没有进行过扩容，它的下标最大为9。于是此时会报出一个数组越界的异常ArrayIndexOutOfBoundsException.

2.2 元素值覆盖和为空问题

elementData[size++] = e 设置值的操作同样会导致线程不安全。从这儿可以看出，这步操作也不是一个原子操作，它由如下两步操作构成：

elementData[size] = e;
size = size + 1;

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

  1. 列表大小为0，即size=0
  2. 线程A开始添加一个元素，值为A。此时它执行第一条操作，将A放在了elementData下标为0的位置上。
  3. 接着线程B刚好也要开始添加一个值为B的元素，且走到了第一步操作。此时线程B获取到size的值依然为0，于是它将B也放在了elementData下标为0的位置上。
  4. 线程A开始将size的值增加为1
  5. 线程B开始将size的值增加为2

这样线程AB执行完毕后，理想中情况为size为2，elementData下标0的位置为A，下标1的位置为B。而实际情况变成了size为2，elementData下标为0的位置变成了B，下标1的位置上什么都没有。并且后续除非使用set方法修改此位置的值，否则将一直为null，因为size为2，添加元素时会从下标为2的位置上开始。

3. 代码示例

如下，通过两个线程对ArrayList添加元素，复现上面的两种不安全情况。

import java.util.ArrayList;
import java.util.List;

public class ArrayListSafeTest {

    public static void main(String[] args) throws InterruptedException {

        final List<Integer> list = new ArrayList<Integer>();
        // 线程A将1-1000添加到列表
        new Thread(new Runnable() {

            @Override
            public void run() {
                for (int i = 1; i < 1000; i++) {
                    list.add(i);

                    try {
                        Thread.sleep(1);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }

            }

        }).start();

        // 线程B将1001-2000添加到列表
        new Thread(new Runnable() {

            @Override
            public void run() {
                for (int i = 1001; i < 2000; i++) {
                    list.add(i);

                    try {
                        Thread.sleep(1);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }

            }

        }).start();

        Thread.sleep(1000);

        // 打印所有结果
        for (int i = 0; i < list.size(); i++) {
            System.out.println("第" + (i + 1) + "个元素为：" + list.get(i));
        }
    }
}

执行过程中，两种情况出现如下：

4. ArrayList线程安全处理

4.1 Collections.synchronizedList

最常用的方法是通过 Collections 的 synchronizedList 方法将 ArrayList 转换成线程安全的容器后再使用。

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

4.2 为list.add()方法加锁

synchronized(list.get()) {
list.get().add(model);
}

4.3 CopyOnWriteArrayList

使用线程安全的 CopyOnWriteArrayList 代替线程不安全的 ArrayList。

List<Object> list1 = new CopyOnWriteArrayList<Object>();

4.4 使用ThreadLocal

使用ThreadLocal变量确保线程封闭性(封闭线程往往是比较安全的， 但由于使用ThreadLocal封装变量，相当于把变量丢进执行线程中去，每new一个新的线程，变量也会new一次，一定程度上会造成性能[内存]损耗，但其执行完毕就销毁的机制使得ThreadLocal变成比较优化的并发解决方案)。

ThreadLocal<List<Object>> threadList = new ThreadLocal<List<Object>>() {
        @Override
         protected List<Object> initialValue() {
              return new ArrayList<Object>();
         }
 };

参考：https://blog.csdn.net/u012859681/article/details/78206494

https://www.cnblogs.com/mabaoqing/p/7446938.html

原文地址：https://www.cnblogs.com/zjfjava/p/10217720.html

时间： 2024-08-04 19:41:44

多线程场景下如何使用 ArrayList的相关文章

多线程场景下延迟初始化的策略

1.什么是延迟初始化 延迟初始化(lazy initialization,即懒加载)是延迟到需要域的值时才将它初始化的行为.如果永远不需要这个值,这个域就永远不会被初始化.这种方法既静态域,也适用于实例域. 最好建议“除非绝对必要,否则就不要这么做”. 2.延迟初始化线程安全的一个策略:同步 延迟初始化的一个好处,是当域只在类的实例部分被访问,并且初始化这个域的开销很高,那就可能值得进行延迟初始化. 但是在大多数情况下,正常的初始化要优先于延迟初始化.因为在多线程的场景下,采用某种形式的同步是很

高并发场景下请求合并的实践

前言 项目中一般会请求第三方的接口,也会对外提供接口,可能是RPC,也可能是HTTP等方式.在对外提供接口时,有必要提供相应的批量接口,好的批量实现能够提升性能. 高并发场景中,调用批量接口相比调用非批量接口有更大的性能优势.但有时候,请求更多的是单个接口,不能够直接调用批量接口,如果这个接口是高频接口,对其做请求合并就很有必要了.比如电影网站的获取电影详情接口,APP的一次请求是单个接口调用,用户量少的时候请求也不多,完全没问题:但同一时刻往往有大量用户访问电影详情,是个高并发的高频接口,如果

多线程场景设计利器：分离方法的调用和执行——命令模式总结

前言 个人感觉,该模式主要还是在多线程程序的设计中比较常用,尤其是一些异步任务执行的过程.但是本文还是打算先在单线程程序里总结它的用法,至于多线程环境中命令模式的用法,还是想在多线程的设计模式里重点总结. 实现思路 其实思路很简单,就是把方法的请求调用和具体执行过程分开,让客户端不知道该请求是如何.何时执行的.那么如何分开呢? 其实没什么复杂的,就是使用 OO 思想,把对方法的请求封装为对象即可,然后在设计一个请求的接受者对象,当然还要有一个请求的发送者对象,请求本身也是一个对象.最后,请求要如

java中HashMap在多线程环境下引起CPU100%的问题解决（转）

最近项目中出现了Tomcat占用CPU100%的情况,原以为是代码中出现死循环,后台使用jstack做了dump,发现是系统中不合理使用HashMap导致出现了死循环(注意不是死锁). 产生这个死循环的根源在于对一个未保护的共享变量 — 一个"HashMap"数据结构的操作.当在所有操作的方法上加了"synchronized"后,一切恢复了正常. 这算jvm的bug吗?应该说不是的,这个现象很早以前就报告出来了(详细见:http://bugs.sun.com/bug

C++多线程环境下的构造函数

多线程的环境里,我们总不可避免要使用锁.于是一个常见的场景就是: 1 class ObjectWithLock 2 { 3 private: 4 std::mutex mtx_; 5 SomeResType shared_res_; 6 7 public: 8 // Constructor/Destructor 9 … 10 11 void OpOnSharedRes() 12 { 13 std::lock_guard<std::mutex> lock(mtx_); 14 15 // read

多线程环境下队列操作之锁的教训

之前一直在研究多线程环境下的编程方法,却很少实战体验,以至于我一提到多线程编程,我总是信心不足,又总是说不出到底哪里不明白.今天工程现场反馈了一个“老问题”,我一直担心的是DAServer的运行机制有什么我不明白的地方,DAS Toolkit中总有一部分是我没有仔细研究的,在我心中有阴影,所以工程出了问题我第一反应就是“会不会问题出在阴影里?”.结果,至今为止,我总结起来问题90%都是在自己编码部分. 我的DAServer中有一个需求,就是上送某个定点数据的速度不能太快,否则后台接收不过来.于是

java中HashMap在多线程环境下引起CPU100%的问题解决

最近项目中出现了Tomcat占用CPU100%的情况,原以为是代码中出现死循环,后台使用jstack做了dump,发现是系统中不合理使用HashMap导致出现了死循环(注意不是死锁). 产生这个死循环的根源在于对一个未保护的共享变量 — 一个"HashMap"数据结构的操作.当在所有操作的方法上加了"synchronized"后,一切恢复了正常. 这算jvm的bug吗?应该说不是的,这个现象很早以前就报告出来了(详细见:http://bugs.sun.com/bug

AddTransient、AddSingleton、AddScopped 三者都应该在什么场景下使用

网上随便一搜,能搜出一大堆对三者进行区别分析的文章,但是呢,理论是一回事,实际使用又是另外一回事,到底在何种场景下应该使用何种注入方式呢? 通过这篇文章和我自身的实际经验,来说一说实际应用中的情况: 首先 AddTransient,这个文章中说的挺明白,就是当组件无法共享时,将使用Transient.非线程安全的数据库访问对象就是一个例子. 我根据我实际遇到的情况,着重说一下 AddSingleton 和 AddScopped,毕竟这两种实际开发中用到的比较多. 于我个人而言,我比较习惯用Add

SQLite在多线程环境下的应用

这几天研究了一下SQLite这个嵌入式数据库在多线程环境下的应用,感觉里面的学问还挺多,于是就在此分享一下. AD: 2014WOT全球软件技术峰会北京站 课程视频发布 先说下初衷吧,实际上我经常看到有人抱怨SQLite不支持多线程.而在iOS开发时,为了不阻塞主线程,数据库访问必须移到子线程中.为了解决这个矛盾,很有必要对此一探究竟. 关于这个问题,最权威的解答当然是SQLite官网上的“Is SQLite threadsafe?”这个问答. 简单来说,从3.3.1版本开始,它就是线程安全的了