普洱市网站建设_网站建设公司_Ruby_seo优化

不出意外这是多线程的最后一篇文章，主要介绍的是面试中比较常考的一个点——多线程下使用容器，我们开始吧~

我们知道，在单线程环境下ArrayList、HashMap等容器使用起来非常方便，但在多线程环境中，如果多个线程同时对容器进行修改，就可能导致数据不一致、数组越界甚至死循环等问题

那么在多线程环境下我们该如何安全地使用这些容器呢？

1. 多线程下使用ArrayList

首先最直接也最简单的方式：加锁

List<Integer>list=newArrayList<>();synchronized(list){list.add();}

这样写显然是可行的，也很灵活，但是对代码的侵入性强、且很容易出错（一旦出错年终奖就没了，，）

因此在实际开发过程中，更常见的做法是使用Java提供的线程安全容器，对并发控制进行统一封装（尽量把坑留给框架，而不是自己）

Collections.synchronizedList会返回一个线程安全的List，其内部通过在关键方法上加上synchronized来保证线程安全

虽然在一定程度上保证了线程安全，但是由于所有操作共用一把锁，并发度低，在读多写少场景下性能较一般，比较适合低并发场景

除了Collections.synchronizedList，Java还提供了另一种思路的线程安全list——CopyOnWriteArrayList

从名字就能看出来，它采用的是一种非常经典的并发设计思想：写时拷贝

写时拷贝的核心思路是：

• 读操作不加锁
• 写操作时先拷贝一份底层数组
• 在新数组上完成修改
• 最后一次性替换引用

好处很明显，实现了读写分离，写操作不会影响正在进行的读操作，读操作不加锁不会阻塞，并发性能很高；写操作内部使用ReentrantLock保证线程安全

同样它也存在问题，写操作时需要拷贝数组，内存开销较大；如果list本身很大或者写操作频繁，性能会明显下降；多个线程同时写入写操作仍会互相竞争锁

对比一下

2. 多线程环境下使用队列

在多线程环境中，队列往往承担着线程协作的角色，例如经典的生产者-消费者模型

Java 在 java.util.concurrent 包中提供了一组 阻塞队列（BlockingQueue） 的实现，用于简化这类并发场景

阻塞队列的核心特性是，队列为空时take()阻塞，队列已满时put()阻塞，以此避免频繁的轮询和手动加锁

2.1 常见的BlockingQueue实现

1. ArrayBlockingQueue：基于数组实现，容量固定，内存连续，结构简单
2. LinkedBlockingQueue：基于链表实现，可以指定容量，吞吐量高（线程池中默认使用的就是这种队列实现）
3. PriorityBlockingQueue：基于堆实现，支持元素优先级，出队顺序由优先级决定，而不是FIFO，适用于任务有明显优先级区分的场景
4. TransferQueue：支持直接把元素交给消费者，如果没有消费者才会进入队列，更强调线程之间的“交接”，使用场景相对较少，但在高并发任务调用中性能表现优秀

3. 多线程环境下使用Map

和 ArrayList 类似，HashMap 在单线程环境下使用非常方便，但在多线程环境中却是典型的线程不安全容器

如果多个线程同时对HashMap进行put/resize等操作，可能会导致数据覆盖、链表结构被破坏、JDK7中可能出现死循环等

3.1 HashTable

HashTable是Java早期提供的线程安全Map，其实现方法也很直接：给几乎所有public方法加上了synchronized
这确实保证了线程安全，但问题同样明显，所有操作共用一把锁、并发度较低、在高并发场景下性能较差

因此，HashTable基本上只存在于学校教材中，实际开发中很少使用

3.2 ConcurrentHashMap

并发环境下的首选！！

它的设计目标非常明确：在保证线程安全的前提下，尽可能提高并发访问性能

为此，它主要做了三方面的优化：

① 细化锁粒度，从“锁整张表”到“锁单个桶”

JDK8中，写操作只锁当前桶（链表或红黑树），不同桶上的操作可以并发进行

这样一来只有在操作同一个桶时线程才可能发生阻塞，并发性能大幅提升

②原子操作维护size

Q: 为什么size在并发下这么难？
A: 多个线程同时size++，读size的线程可能看到中间状态，如果给size加全局锁，每次put/remove都要竞争，性能急剧下降

ConcurrentHashMap内部不是使用一个size，而是多个计数单元，类似

baseCount// 基础计数counterCells[]// 多个计数槽

可以理解为使用多个小本子记账，而不是所有人挤在一本账上

写操作时尽量“就近记账”，通过原子操作（CAS）对计数进行更新，在并发冲突较大时，将计数分散到多个计数单元中，不同线程更新不同计数单元，从而减少竞争

在调用size()时，会将各个计数单元的值进行累加，得到当前Map的元素数量。由于统计过程中可能存在并发写入，size()返回的是一个瞬时近似值，但在绝大多数业务场景下是可以接收的

这样设计在避免全局锁的同时，显著提升了高并发下的整体性能

③渐进式rehash

扩容是Map中开销最大的操作之一，如果扩容时一次性创建新数组将所有元素整体搬迁，那么在高并发场景下性能会非常糟糕

ConcurrentHashMap的做法是，新表和旧表同时存在，扩容过程被“拆散”到后续的多次操作中完成

具体表现为：每次put/get/remove时，顺带迁移一小部分旧数据，直到所有桶都完成迁移（蚂蚁搬家，一点一点搬）

这种渐进式扩容的方式，有效避免了长时间阻塞

综上上上所述，ConcurrentHashMap的优势主要在于锁粒度小、并发度高、针对热点操作做了大量优化、在高并发场景下性能稳定可靠

因此在多线程环境中，除非有非常明确的理由，否则应该优先选择ConcurrentHashMap，而不是HashMap或者HashTable

完结撒花★,°:.☆(￣▽￣)/$:.°★。