JUC源码分析-集合篇:并发类容器介绍

JUC源码分析-集合篇:并发类容器介绍

同步类容器是 线程安全 的,如 Vector、HashTable 等容器的同步功能都是由 Collections.synchronizedMap 等工厂方法去创建实现的,底层使用 synchronized 关键字,每次只有一个线程访问容器。这明显不满足高并发的需求。

JDK1.8 中的并发类容器

非阻塞队列 阻塞队列
ConcurrentHashMap [ArrayBlockingDeque]
[ConcurrentSkipListMap] LinkedBlockingQueue
[ConcurrentSkipListSet] LinkedBlockingDeque
ConcurrentLinkedQueue PriorityBlockingQueue
ConcurrentLinkedDeque DelayQueue
CopyOnWriteArrayList SynchronousQueue
CopyOnWriteArraySet LinkedTransferQueue

《Java并发容器使用》:http://tutorials.jenkov.com/java-util-concurrent/index.html

1. ConcurrentMap

ConcurrentHashMap 容器内部使用(Segment)来表示不同的部分,每个段其实就是一个小的 HashTable ,它们有自己的锁。只要多个修改操作发生在不同的段上,它们就可以并发进行。把一个整体分成了16个段(Segment)。也就是最高支持16个线程的并发修改操作。这也是在多线程场景时 减小锁的粒度从而降低锁竞争 一种方案。并且代码中大多共享变量使用 volatile 关键字声明,目的是第一时间获取修改的内容,性能非常好。

2. Copy-On-Write

CopyOnWrite 容器既写时复制的容器, 用于读多写少的场景 。往一个容器添加元素时,不直接往当前容器添加,而是先将当前容器 Copy ,复制一个新的容器,然后往新的容器添加元素,添加完成之后,再将原容器的引用指向新的容器,这样做的好处是可以对 CopyOnWrite 容器进行并发的读,而不需要加锁,因为当前容器不会添加任何元素。所以 CopyOnWrite 容器是一种读写分离的思想,读和写不同的容器。

3. ConcurrentLinkedQueue 无阻塞队列

适合高并发场景下的队列,通过无锁的方式,实现了高并发状态下的高性能,通常 ConcurrentLinkedQueue 性能好于 LinkedBlockingQueue。它是一个基于链接节点的无界线程安全队列。该队列的元素遵循先进先出的原则,且不允许 null 元素。

4. BlockingQueue 阻塞队列

Java 中阻塞队列的 4 种处理方式,JDK1.8 提供了 中提供的 7 种阻塞队列。

阻塞队列(BlockingQueue)是一个支持两个附加操作的队列。这两个附加的操作支持阻塞的插入和移除方法。

1)支持阻塞的插入方法:意思是当队列满时,队列会阻塞插入元素的线程,直到队列不满。
2)支持阻塞的移除方法:意思是在队列为空时,获取元素的线程会等待队列变为非空。

阻塞队列常用于生产者和消费者的场景,生产者是向队列里添加元素的线程,消费者是从队列里取元素的线程。阻塞队列就是生产者用来存放元素、消费者用来获取元素的容器。在阻塞队列不可用时,这两个附加操作提供了 4 种处理方式,如下表所示。

方法 抛出异常 返回特殊值 一直阻塞 超时退出
插入 add(e) offer(e) put(e) offer(e, time, unit)
移除 remove(e) poll() take() poll(time, unit)
查找 element() peek() × ×

JDK 7提供了7个阻塞队列,如下。

  1. ArrayBlockingQueue:一个由数组结构组成的有界阻塞队列。
  2. LinkedBlockingQueue:一个由链表结构组成的有界阻塞队列。
  3. PriorityBlockingQueue:一个支持优先级排序的无界阻塞队列。
  4. DelayQueue:一个使用优先级队列实现的无界阻塞队列。
  5. SynchronousQueue:一个不存储元素的阻塞队列。
  6. LinkedTransferQueue:一个由链表结构组成的无界阻塞队列。
  7. LinkedBlockingDeque:一个由链表结构组成的双向阻塞队列。

每天用心记录一点点。内容也许不重要,但习惯很重要!

版权声明:本文为binarylei原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/binarylei/p/10945770.html