前言
本章将阐述多线程并发的拓展及总结
主体概要
- 死锁
- 并发最佳实践
- Spring与线程安全
- HashMap与ConcurrentHashMap解析
- 多线程并发与线程安全总结
主体内容
一、死锁
1.首先，祭出一张熟悉的图，可以看到中间的四辆直行车辆互相在等待其他车让路，大家都动弹不得。如果没有人指挥谁先让步，这些车就要永远等待在这里了。
2. 那么何为进程的死锁呢？是指两个或两个以上的线程因竞争资源而发生互相等待的现象，如果没有外力作用，他们将无法推进下去，此时，我们称进程呈死锁状态。
3.死锁也不是那么容易发生的，有以下四个条件
- 互斥条件：某时间一个资源只能被一个进程占用
- 不可剥夺条件：某个进程占用了资源，就只能他自己去释放。
- 请求和保持条件：某个进程之前申请了资源，我还想再申请资源，之前的资源还是我占用着，别人别想动。除非我自己不想用了，释放掉。
- 循环等待条件：一定会有一个环互相等待。
4.这里举个死锁的小例子
import lombok.extern.slf4j.Slf4j; /** * 一个简单的死锁类 * 当DeadLock类的对象flag==1的时候（td1）,先锁定o1，睡眠500毫秒 * 而td1在睡眠的时候另一个flag==0的对象（td2）线程启动，先锁定o2，睡眠500毫秒 * td1睡眠结束后需要锁定o2才能继续执行，而此时o2已经被td2锁定 * td2睡眠结束后需要锁定o1才能继续执行，而此时o2已经被td1锁定 * td1、td2互相等待，都需要得到对方锁定的资源才能继续执行，从而死锁 */ @Slf4j public class DeadLock implements Runnable{ public int flag=1; private static Object o1 = new Object(),o2=new Object(); @Override public void run(){ log.info("flag:{}",flag); if(flag==1){ synchronized (o1){ try { Thread.sleep(500); } catch (InterruptedException e) { e.printStackTrace(); } synchronized (o2){ log.info("0"); } } } if(flag==0){ synchronized (o2){ try { Thread.sleep(500); } catch (InterruptedException e) { e.printStackTrace(); } synchronized (o1){ log.info("0"); } } } } public static void main(String[] args) { DeadLock td1 = new DeadLock(); DeadLock td2 = new DeadLock(); td1.flag=1; td2.flag=0; //td1,td2都处于可执行状态，但JVM线程调度先执行哪个线程是不确定的 //td2的run()方法可能在td1的run()之前执行 new Thread(td1).start(); new Thread(td2).start(); } }
5.那么如何避免死锁呢？在有些情况下死锁是可以避免的。这里有三种用于避免死锁的技术：
- 加锁顺序（线程按照一定的顺序加锁）
- 加锁时限（线程尝试获取锁的时候加上一定的时限，超过时限则放弃对该锁的请求，并释放自己占有的锁）
- 死锁检测
这三种方式的具体实现可以参照：https://www.cnblogs.com/sthu/p/9660914.html
还有一种，我们可以在死锁发生的时候为各线程设置优先级。
二、并发最佳实践
1.使用本地变量
应该总是使用本地变量，而不是创建一个类或实例变量，通常情况下，开发人员使用对象实例作为变量可以节省内存并可以重用，因为他们认为每次在方法中创建本地变量会消耗很多内存。下面代码的execute()方法被多线程调用，为了实现一个新功能，你需要一个临时集合Collection，代码中这个临时集合作为静态类变量使用，然后在execute方法的尾部清除这个集合以便下次重用，编写这段代码的人可能认为这是线程安全的，因为 CopyOnWriteArrayList是线程安全的，但是他没有意识到，这个方法execute()是被多线程调用，那么可能多线程中一个线程看到另外一个线程的临时数据，即使使用Collections.synchronizedList也不能保证execute()方法内的逻辑不变性，这个不变性是：这个集合是临时集合，只用来在每个线程执行内部可见即可，不能暴露给其他线程知晓解决办法是使用本地List而不是全局的List。
2.使用不可变类
不可变类比如String Integer等一旦创建，不再改变，不可变类可以降低代码中需要的同步数量。
3.最小化锁的作用域范围：S=1/(1-a+a/n)
解释一下意义：
a：并行计算部分所占比例
n：并行处理结点个数
S：加速比
当1-a等于0时，没有串行只有并行，最大加速比 S=n
当a=0时，只有串行没有并行，最小加速比 S = 1
当n→∞时，极限加速比 s→ 1/（1-a）
例如，若串行代码占整个代码的25%，则并行处理的总体性能不可能超过4。
该公式称为："阿姆达尔定律"或"安达尔定理"。
4.使用线程池的Executor，而不是直接new Thread 执行
创建一个线程的代价是昂贵的，如果要创建一个可伸缩的Java应用，那么你需要使用线程池。
5.宁可使用同步也不要使用线程的wait和notify
从Java1.5以后，增加了许多同步工具，如：CountDownLatch、CyclicBarrier、Semaphore等，应该优先使用这些同步工具。
6.使用BlockingQueue实现生产-消费模式
阻塞队列不仅可以处理单个生产、单个消费，也可以处理多个生产和消费。
7.使用并发集合而不是加了锁的同步集合
Java提供了下面几种并发集合框架：
ConcurrentHashMap、CopyOnWriteArrayList、CopyOnWriteArraySet、ConcurrentLinkedQueue 、ConcurrentLinkedDeque等
8.使用Semaphore创建有界的访问
为了建立稳定可靠的系统，对于数据库、文件系统和socket等资源必须要做有机的访问，Semaphore可以限制这些资源开销的选择，Semaphore可以以最低的代价阻塞线程等待，可以通过Semaphore来控制同时访问指定资源的线程数。
9.宁可使用同步代码块，也不实用同步的方法
主要针对synchronized关键字。使用synchronized关键字同步代码块只会锁定一个对象，而不会将整个方法锁定。如果更改共同的变量或类的字段，首先应该选择的是原子型变量，然后使用volatile。如果需要互斥锁，可以考虑使用ReentrantLock。
10.避免使用静态变量
静态变量在并发执行环境下会制造很多问题，如果必须使用静态变量，那么优先是它成为final变量，如果用来保存集合collection，那么可以考虑使用只读集合，否则一定要做特别多的同步处理和并发处理操作。
三、Spring与线程安全（了解）
这里看一下Spring的线程安全，Spring作为一个IOC/DI容器，帮助我们管理了许许多多的“bean”。但其实Spring并没有保证这些对象的线程安全，需要由我们开发者自行编写解决线程安全问题的代码。
Spring对每个bean提供了一个scope属性来表示该bean的作用域。它是bean的生命周期。例如，一个scope为singleton的bean，在第一次被注入时，会创建为一个单例对象，该对象会一直被复用到应用结束。
1.Spring bean
(1) singleton（单例）：默认的scope，每个scope为singleton的bean都会被定义为一个单例对象，该对象的生命周期是与Spring IOC容器一致的（但在第一次被注入时才会创建）。在整个Spring IoC容器里，只有一个bean实例，所有线程共享该实例。
(2) prototype：bean被定义为在每次注入时都会创建一个新的对象。每次请求都会创建并返回一个新的实例，所有线程都有单独的实例使用，这种方式是比较安全的，但会消耗大量内存和计算资源。
2.无状态对象(只要是无状态对象，不管单例多例都是线程安全的)：
我们交由Spring管理的大多数对象其实都是一些无状态的对象，这种不会因为多线程而导致状态被破坏的对象很适合Spring的默认scope，每个单例的无状态对象都是线程安全的（也可以说只要是无状态的对象，不管单例多例都是线程安全的，不过单例毕竟节省了不断创建对象与GC的开销）。
无状态的对象即是自身没有状态的对象，自然也就不会因为多个线程的交替调度而破坏自身状态导致线程安全问题。无状态对象包括我们经常使用的DO、DTO、VO这些只作为数据的实体模型的贫血对象，还有Service、DAO和Controller，这些对象并没有自己的状态，它们只是用来执行某些操作的。例如，每个DAO提供的函数都只是对数据库的CRUD，而且每个数据库Connection都作为函数的局部变量（局部变量是在用户栈中的，而且用户栈本身就是线程私有的内存区域，所以不存在线程安全问题），用完即关（或交还给连接池）。
request（请求范围实例）：bean被定义为在每个HTTP请求中创建一个单例对象，也就是说在单个请求中都会复用这一个单例对象。每当接受到一个HTTP请求时，就分配一个唯一实例，这个实例在整个请求周期都是唯一的。
session（会话范围实例）：bean被定义为在一个session的生命周期内创建一个单例对象。在每个用户会话周期内，分配一个实例，这个实例在整个会话周期都是唯一的，所有同一会话范围的请求都会共享该实例。
application：bean被定义为在ServletContext的生命周期中复用一个单例对象。
websocket：bean被定义为在websocket的生命周期中复用一个单例对象。
globalsession（全局会话范围实例）：这与会话范围实例大部分情况是一样的，只是在使用到portlet时，由于每个portlet都有自己的会话，如果一个页面中有多个portlet而需要共享一个bean时，才会用到。
四、HashMap与ConcurrentHashMap解析
为什么要单独提到这两个类呢？因为他两在后期开发中会经常经常用到，十分重要。
1.首先，我们来说一下HashMap的数据结构：蓝色部分就是HashMap底层数组，数组的每一项都有一个链表。
HashMap有两个因素影响它的性能，一、初始容量；二、加载因子；我们来看下源代码：
（1）默认初始容量16
/** * The default initial capacity - MUST be a power of two. */ static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16
（2）默认加载因子0.75f
/** * The load factor used when none specified in constructor. */ static final float DEFAULT_LOAD_FACTOR = 0.75f;
如何理解这两个因素？初始容量是桶的数量，加载因子是在于桶能装多满的一个尺度。当哈希表中条目数量超过了加载因子乘以初始容量（这里就是16*0.75=12）的时候，它将会调用下面的resize()方法进行扩容，然后将它的容量进行分配。
/** * Initializes or doubles table size. If null, allocates in * accord with initial capacity target held in field threshold. * Otherwise, because we are using power-of-two expansion, the * elements from each bin must either stay at same index, or move * with a power of two offset in the new table. * * @return the table */ final Node<K,V>[] resize() { Node<K,V>[] oldTab = table; int oldCap = (oldTab == null) ? 0 : oldTab.length; int oldThr = threshold; int newCap, newThr = 0; if (oldCap > 0) { if (oldCap >= MAXIMUM_CAPACITY) { threshold = Integer.MAX_VALUE; return oldTab; } else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY && oldCap >= DEFAULT_INITIAL_CAPACITY) newThr = oldThr << 1; // double threshold } else if (oldThr > 0) // initial capacity was placed in threshold newCap = oldThr; else { // zero initial threshold signifies using defaults newCap = DEFAULT_INITIAL_CAPACITY; newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY); } if (newThr == 0) { float ft = (float)newCap * loadFactor; newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ? (int)ft : Integer.MAX_VALUE); } threshold = newThr; @SuppressWarnings({"rawtypes","unchecked"}) Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap]; table = newTab; if (oldTab != null) { for (int j = 0; j < oldCap; ++j) { Node<K,V> e; if ((e = oldTab[j]) != null) { oldTab[j] = null; if (e.next == null) newTab[e.hash & (newCap - 1)] = e; else if (e instanceof TreeNode) ((TreeNode<K,V>)e).split(this, newTab, j, oldCap); else { // preserve order Node<K,V> loHead = null, loTail = null; Node<K,V> hiHead = null, hiTail = null; Node<K,V> next; do { next = e.next; if ((e.hash & oldCap) == 0) { if (loTail == null) loHead = e; else loTail.next = e; loTail = e; } else { if (hiTail == null) hiHead = e; else hiTail.next = e; hiTail = e; } } while ((e = next) != null); if (loTail != null) { loTail.next = null; newTab[j] = loHead; } if (hiTail != null) { hiTail.next = null; newTab[j + oldCap] = hiHead; } } } } } return newTab; }
这里讲的都是默认初始化容量和默认加载因子，实际过程中，我们是可以对这两个参数进行指定的，这里我们看下HashMap的构造函数，它提供了四个构造函数，代码中initialCapacity就是初始容量，loadFactor就是加载因子。
/** * Constructs an empty <tt>HashMap</tt> with the specified initial * capacity and load factor. * * @param initialCapacity the initial capacity * @param loadFactor the load factor * @throws IllegalArgumentException if the initial capacity is negative * or the load factor is nonpositive */ public HashMap(int initialCapacity, float loadFactor) { if (initialCapacity < 0) throw new IllegalArgumentException("Illegal initial capacity: " + initialCapacity); if (initialCapacity > MAXIMUM_CAPACITY) initialCapacity = MAXIMUM_CAPACITY; if (loadFactor <= 0 || Float.isNaN(loadFactor)) throw new IllegalArgumentException("Illegal load factor: " + loadFactor); this.loadFactor = loadFactor; this.threshold = tableSizeFor(initialCapacity); } /** * Constructs an empty <tt>HashMap</tt> with the specified initial * capacity and the default load factor (0.75). * * @param initialCapacity the initial capacity. * @throws IllegalArgumentException if the initial capacity is negative. */ public HashMap(int initialCapacity) { this(initialCapacity, DEFAULT_LOAD_FACTOR); } /** * Constructs an empty <tt>HashMap</tt> with the default initial capacity * (16) and the default load factor (0.75). */ public HashMap() { this.loadFactor = DEFAULT_LOAD_FACTOR; // all other fields defaulted } /** * Constructs a new <tt>HashMap</tt> with the same mappings as the * specified <tt>Map</tt>. The <tt>HashMap</tt> is created with * default load factor (0.75) and an initial capacity sufficient to * hold the mappings in the specified <tt>Map</tt>. * * @param m the map whose mappings are to be placed in this map * @throws NullPointerException if the specified map is null */ public HashMap(Map<? extends K, ? extends V> m) { this.loadFactor = DEFAULT_LOAD_FACTOR; putMapEntries(m, false); }
2.接下来，我们看一下HashMap的寻值方式，对于一个新插入的数据或者我们需要读取的数据，HashMap需要将它的key按照一定的计算规则计算出它的哈希值，并对我们的数组长度进行取模，结果作为它在数组中的index下标，然后进行查找。在计算机中，取模的代价远远大于位操作的代价，因此HashMap要求这里的数组长度必须为2的n次方，此时它将替代哈希值对2的n-1次方进行与运算，它的结果与我们的取模操作是相同的。HashMap并不要求用户在指定HashMap容量时必须传入一个2的N次方的整数，而是会通过Integer.highestOneBit算出比指定整数小的最大的2N值，我们来看下它的代码：
/** * Returns a power of two size for the given target capacity. */ static final int tableSizeFor(int cap) { int n = cap - 1; n |= n >>> 1; n |= n >>> 2; n |= n >>> 4; n |= n >>> 8; n |= n >>> 16; return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1; }
3.众所周知，HashMap是非线程安全的，该方法并不保证线程安全，而且在多线程并发调用时，可能出现死循环。由于Key的哈希值的分布直接决定了所有数据在哈希表上的分布或者说决定了哈希冲突的可能性，因此为防止糟糕的Key的hashCode实现（例如低位都相同，只有高位不相同，与2^N-1取与后的结果都相同），JDK 1.7的HashMap通过如下方法使得最终的哈希值的二进制形式中的1尽量均匀分布从而尽可能减少哈希冲突。
int h = hashSeed; h ^= k.hashCode(); h ^= (h >>> 20) ^ (h >>> 12); return h ^ (h >>> 7) ^ (h >>> 4);
（1）resize死循环
transfer方法
当HashMap的size超过Capacity*loadFactor时，需要对HashMap进行扩容。具体方法是，创建一个新的，长度为原来Capacity两倍的数组，保证新的Capacity仍为2的N次方，从而保证上述寻址方式仍适用。同时需要通过如下transfer方法将原来的所有数据全部重新插入（rehash）到新的数组中。
void transfer(Entry[] newTable, boolean rehash) { int newCapacity = newTable.length; for (Entry<K,V> e : table) { while(null != e) { Entry<K,V> next = e.next; if (rehash) { e.hash = null == e.key ? 0 : hash(e.key); } int i = indexFor(e.hash, newCapacity); e.next = newTable[i]; newTable[i] = e; e = next; } } }
该方法并不保证线程安全，而且在多线程并发调用时，可能出现死循环。其执行过程如下。从步骤2可见，转移时链表顺序反转。 1. 遍历原数组中的元素 2. 对链表上的每一个节点遍历：用next取得要转移那个元素的下一个，将e转移到新数组的头部，使用头插法插入节点 3. 循环2，直到链表节点全部转移 4. 循环1，直到所有元素全部转移
（2）单线程rehash
单线程情况下，rehash无问题。下图演示了单线程条件下的rehash过程。
（3）多线程并发下的rehash
这里假设有两个线程同时执行了put操作并引发了rehash，执行了transfer方法，并假设线程一进入transfer方法并执行完next = e.next后，因为线程调度所分配时间片用完而“暂停”，此时线程二完成了transfer方法的执行。此时状态如下。
接着线程1被唤醒，继续执行第一轮循环的剩余部分
e.next = newTable[1] = null newTable[1] = e = key(5) e = next = key(9)
结果如下图所示：
接着执行下一轮循环，结果状态图如下所示
继续下一轮循环，结果状态图如下所示
此时循环链表形成，并且key(11)无法加入到线程1的新数组。在下一次访问该链表时会出现死循环。
（4）Fast-fail
产生原因
在使用迭代器的过程中如果HashMap被修改，那么ConcurrentModificationException将被抛出，也即Fast-fail策略。
当HashMap的iterator()方法被调用时，会构造并返回一个新的EntryIterator对象，并将EntryIterator的expectedModCount设置为HashMap的modCount（该变量记录了HashMap被修改的次数）。
HashIterator() { expectedModCount = modCount; if (size > 0) { // advance to first entry Entry[] t = table; while (index < t.length && (next = t[index++]) == null) ; } }
在通过该Iterator的next方法访问下一个Entry时，它会先检查自己的expectedModCount与HashMap的modCount是否相等，如果不相等，说明HashMap被修改，直接抛出`ConcurrentModificationException`。该Iterator的remove方法也会做类似的检查。该异常的抛出意在提醒用户及早意识到线程安全问题。
4.接下来，介绍一下ConcurrentHashMap。
（1）Java 8基于CAS的ConcurrentHashMap
Java7中的ConcurrentHashMap的底层数据结构仍然是数组和链表。与HashMap不同的是，ConcurrentHashMap最外层不是一个大的数组，而是一个Segment的数组。每个Segment包含一个与HashMap数据结构差不多的链表数组。整体数据结构如下图所：
a.寻址方式
在读写某个Key时，先取该Key的哈希值。并将哈希值的高N位对Segment个数取模从而得到该Key应该属于哪个Segment，接着如同操作HashMap一样操作这个Segment。为了保证不同的值均匀分布到不同的Segment，需要通过如下方法计算哈希值。
private int hash(Object k) { int h = hashSeed; if ((0 != h) && (k instanceof String)) { return sun.misc.Hashing.stringHash32((String) k); } h ^= k.hashCode(); h += (h << 15) ^ 0xffffcd7d; h ^= (h >>> 10); h += (h << 3); h ^= (h >>> 6); h += (h << 2) + (h << 14); return h ^ (h >>> 16); }
同样为了提高取模运算效率，通过如下计算，ssize即为大于concurrencyLevel的最小的2的N次方，同时segmentMask为2^N-1。这一点跟上文中计算数组长度的方法一致。对于某一个Key的哈希值，只需要向右移segmentShift位以取高sshift位，再与segmentMask取与操作即可得到它在Segment数组上的索引。
int sshift = 0; int ssize = 1; while (ssize < concurrencyLevel) { ++sshift; ssize <<= 1; } this.segmentShift = 32 - sshift; this.segmentMask = ssize - 1; Segment<K,V>[] ss = (Segment<K,V>[])new Segment[ssize];
b.同步方式
Segment继承自ReentrantLock，所以我们可以很方便的对每一个Segment上锁。
对于读操作，获取Key所在的Segment时，需要保证可见性(请参考如何保证多线程条件下的可见性)。具体实现上可以使用volatile关键字，也可使用锁。但使用锁开销太大，而使用volatile时每次写操作都会让所有CPU内缓存无效，也有一定开销。ConcurrentHashMap使用如下方法保证可见性，取得最新的Segment。
Segment<K,V> s = (Segment<K,V>)UNSAFE.getObjectVolatile(segments, u)
获取Segment中的HashEntry时也使用了类似方法
HashEntry<K,V> e = (HashEntry<K,V>) UNSAFE.getObjectVolatile (tab, ((long)(((tab.length - 1) & h)) << TSHIFT) + TBASE)
对于写操作，并不要求同时获取所有Segment的锁，因为那样相当于锁住了整个Map。它会先获取该Key-Value对所在的Segment的锁，获取成功后就可以像操作一个普通的HashMap一样操作该Segment，并保证该Segment的安全性。 同时由于其它Segment的锁并未被获取，因此理论上可支持concurrencyLevel（等于Segment的个数）个线程安全的并发读写。 获取锁时，并不直接使用lock来获取，因为该方法获取锁失败时会挂起（参考[可重入锁](http://www.jasongj.com/java/multi_thread/#重入锁)）。事实上，它使用了自旋锁，如果tryLock获取锁失败，说明锁被其它线程占用，此时通过循环再次以tryLock的方式申请锁。如果在循环过程中该Key所对应的链表头被修改，则重置retry次数。如果retry次数超过一定值，则使用lock方法申请锁。 这里使用自旋锁是因为自旋锁的效率比较高，但是它消耗CPU资源比较多，因此在自旋次数超过阈值时切换为互斥锁。
c.size操作
put、remove和get操作只需要关心一个Segment，而size操作需要遍历所有的Segment才能算出整个Map的大小。一个简单的方案是，先锁住所有Sgment，计算完后再解锁。但这样做，在做size操作时，不仅无法对Map进行写操作，同时也无法进行读操作，不利于对Map的并行操作。
为更好支持并发操作，ConcurrentHashMap会在不上锁的前提逐个Segment计算3次size，如果某相邻两次计算获取的所有Segment的更新次数（每个Segment都与HashMap一样通过modCount跟踪自己的修改次数，Segment每修改一次其modCount加一）相等，说明这两次计算过程中无更新操作，则这两次计算出的总size相等，可直接作为最终结果返回。如果这三次计算过程中Map有更新，则对所有Segment加锁重新计算Size。该计算方法代码如下
public int size() { final Segment<K,V>[] segments = this.segments; int size; boolean overflow; // true if size overflows 32 bits long sum; // sum of modCounts long last = 0L; // previous sum int retries = -1; // first iteration isn't retry try { for (;;) { if (retries++ == RETRIES_BEFORE_LOCK) { for (int j = 0; j < segments.length; ++j) ensureSegment(j).lock(); // force creation } sum = 0L; size = 0; overflow = false; for (int j = 0; j < segments.length; ++j) { Segment<K,V> seg = segmentAt(segments, j); if (seg != null) { sum += seg.modCount; int c = seg.count; if (c < 0 || (size += c) < 0) overflow = true; } } if (sum == last) break; last = sum; } } finally { if (retries > RETRIES_BEFORE_LOCK) { for (int j = 0; j < segments.length; ++j) segmentAt(segments, j).unlock(); } } return overflow ? Integer.MAX_VALUE : size; }
d.不同之处
ConcurrentHashMap与HashMap相比，有以下不同点
ConcurrentHashMap线程安全，而HashMap非线程安全
HashMap允许Key和Value为null，而ConcurrentHashMap不允许
HashMap不允许通过Iterator遍历的同时通过HashMap修改，而ConcurrentHashMap允许该行为，并且该更新对后续的遍历可见
（2）Java 8基于CAS的ConcurrentHashMap
注：本章的代码均基于JDK 1.8.0_111
数据结构 Java 7为实现并行访问，引入了Segment这一结构，实现了分段锁，理论上最大并发度与Segment个数相等。Java 8为进一步提高并发性，摒弃了分段锁的方案，而是直接使用一个大的数组。同时为了提高哈希碰撞下的寻址性能，Java 8在链表长度超过一定阈值（8）时将链表（寻址时间复杂度为O(N)）转换为红黑树（寻址时间复杂度为O(long(N))）。其数据结构如下图所示
a.寻址方式
Java 8的ConcurrentHashMap同样是通过Key的哈希值与数组长度取模确定该Key在数组中的索引。同样为了避免不太好的Key的hashCode设计，它通过如下方法计算得到Key的最终哈希值。不同的是，Java 8的ConcurrentHashMap作者认为引入红黑树后，即使哈希冲突比较严重，寻址效率也足够高，所以作者并未在哈希值的计算上做过多设计，只是将Key的hashCode值与其高16位作异或并保证最高位为0（从而保证最终结果为正整数）。
static final int spread(int h) { return (h ^ (h >>> 16)) & HASH_BITS; }
b.同步方式
对于put操作，如果Key对应的数组元素为null，则通过CAS操作将其设置为当前值。如果Key对应的数组元素（也即链表表头或者树的根元素）不为null，则对该元素使用synchronized关键字申请锁，然后进行操作。如果该put操作使得当前链表长度超过一定阈值，则将该链表转换为树，从而提高寻址效率。
对于读操作，由于数组被volatile关键字修饰，因此不用担心数组的可见性问题。同时每个元素是一个Node实例（Java 7中每个元素是一个HashEntry），它的Key值和hash值都由final修饰，不可变更，无须关心它们被修改后的可见性问题。而其Value及对下一个元素的引用由volatile修饰，可见性也有保障。
static class Node<K,V> implements Map.Entry<K,V> { final int hash; final K key; volatile V val; volatile Node<K,V> next; }
对于Key对应的数组元素的可见性，由Unsafe的getObjectVolatile方法保证。
static final <K,V> Node<K,V> tabAt(Node<K,V>[] tab, int i) { return (Node<K,V>)U.getObjectVolatile(tab, ((long)i << ASHIFT) + ABASE); }
c.size操作
put方法和remove方法都会通过addCount方法维护Map的size。size方法通过sumCount获取由addCount方法维护的Map的size。
五、多线程并发与线程安全总结
一张图总结
