专栏系列文章

2. 第二篇：原子类的说明与使用
3. 第三篇：Lock的学习与使用
4. 第四篇：走近CopyOnWriteArrayList
5. 第五篇：HashMap的源码分析
6. 第六篇：走近ConcurrentHashMap（JDK1.8）
7. 第七篇：ConcurrentHashMap（JDK1.8）扩容的详细介绍以及多线程测试
8. 第八篇：链表的学习：链表的头插法和尾插法
9. 第九篇：队列的学习，用数组和链表实现单向队列
10. 第十篇：队列的学习，循环队列，阻塞队列和并发队列
11. 第十一篇 队列的学习（三） 手写一个阻塞队列
12. 第十二篇：ArrayBlockingQueue的源码解析
13. 第十三篇：LinkedBlockingQueue的源码解析（基于JDK1.8）
14. 第十四篇：ConcurrentLinkedQueue的源码解析
15. 第十五篇：LinkedBlockingDeque的源码解析（基于JDK1.8）
16. 第十六篇：面试必备的线程池知识-线程池的使用
17. 第十七篇：面试必备的线程池知识-线程池的原理

摘要

Java并发包（concurrent）是Java用来处理并发问题的利器，该并发包中主要有原子类，锁（lock），并发容器类等等。本系列博客主要就是介绍并发包中一些常用的并发容器，常用的类。那么就让我们一起来揭开并发包的面纱吧。

环境

基于JDK1.8

原子类

首先登场的就是我们的原子类。啥是原子类？原子类用啥用？
第一个问题，啥是原子类：操作具有原子性的类，我们称之为原子类。为啥要有原子类呢？
原子类是为了保证操作的原子性。例如：long i=0; i=i+1(i为全局变量)，在多线程的环境下，就有线程安全的问题，因为，i=i+1这个操作分为三条CPU指令执行。指令执行完之后会发生指令切换，造成可见性问题。但是，如果我们使用AtomicLong类来包装i,然后调用getAndIncrement()方法（该方法是具有原子性的），则可以保证其安全性。

 AtomicLong atest = new AtomicLong(0);
 atest.getAndIncrement();

  

 

  
1
  
2
 

原子类主要有如下几个：

锁

原子类说完了，我们接着来说说锁，我们都知道Java中synchronized关键字作为同步锁，同时，在并发包中还提供了Lock锁。关于Lock与synchronized的区别后面会有说到。锁的类图如下：

并发容器

简单的说完了锁，我们接着来看重头戏并发容器。虽然，Java中提供了同步容器Vector和Collections包装的容器。但是同步容器最大的问题就是性能太差。因为其是直接对添加元素，删除元素，读取元素的所有方法都加锁。
所有在并发包中提供了并发容器，并发容器的实现后面我们在阐述。
我们先看看有哪些并发容器。
按照数据结构类型分类来看。

List接口下

List 接口下有CopyOnWriteArrayList实现类。其实现是内部维护了一个数组，成员变量array就指向这个内部数组，读操作都是基于array进行的，写操作的话，
CopyOnWriteArrayList会将array复制一份，然后，在新复制处理的数组上执行增加元素的操作。执行完之后再将array指向这个新的数组。仅仅适用于写操作非常少的场景，而且能够容忍读写的短暂不一致的情况。

Map接口下

Map 接口下有ConcurrentHashMap和ConcurrentSkipListMap。ConcurrentHashMap内部的数据结构跟HashMap一致，都是数组+链表+红黑树的结构。ConcurrentSkipListMap内部的数据结构则是数组+跳表的数组结构。

Set接口下

Set接口下面有ConcurrentSkipListSet和CopyOnWriteArraySet两个并发类。

Queue接口下

Queue接口下的并发容器类比较多，阻塞队列BlockingQueue接口下有
单端堵塞队列ArrayBlockingQueue，LinkedBlockingQueue，SynchronousQueue，LinkedTransferQueue，PriorityBlockingQueue，DelayQueue，双端阻塞队列LinkedBlockingDeque。非阻塞队列有：单端队列ConcurrentLinkedQueue，双端队列：ConcurrentLinkedDeque。

总结

本文简单概述了Java并发包下的一些常用的类。后续的博客将围绕着这些类来剖析。

文章来源: feige.blog.csdn.net，作者：码农飞哥，版权归原作者所有，如需转载，请联系作者。

原文链接：feige.blog.csdn.net/article/details/104041553