也是键值对形式来存储数据
public interface ConcurrentMap<K, V> extends Map<K, V>
实现自Map接口，及Map中所有的接口ConcurrentMap同样具有
//如果指定键已经不在和某个值关联，则他和给定值关联
V putIfAbsent(K key, V value);
//只有目前将键映射到给定的value时，才移除该键值对 返回值Boolean类型， true:成功 false：失败
boolean remove(Object key, Object value);
//只有当key和oldValue同时存在时，才会将oldValue替换为newValue
boolean replace(K key, V oldValue, V newValue);
//只有在集合中存在该key,才完成替换
V replace(K key, V value);
提供的原子操作方法。
//用来存储数据 是一个Segment数组
final Segment<K,V>[] segments;
//segment是继承自ReentrantLock，实现了锁机制
static final class Segment<K,V> extends ReentrantLock implements Serializable {
//重入次数 加锁操作发送冲突需要考虑重入问题
static final int MAX_SCAN_RETRIES =
Runtime.getRuntime().availableProcessors() > 1 ? 64 : 1;
//数据存放在table中，是volatile修饰
transient volatile HashEntry<K,V>[] table;
Segment(float lf, int threshold, HashEntry<K,V>[] tab) {
this.loadFactor = lf;
this.threshold = threshold;
this.table = tab;
}
}
static final class HashEntry<K,V> {
final int hash;
final K key;
volatile V value;
volatile HashEntry<K,V> next;
HashEntry(int hash, K key, V value, HashEntry<K,V> next) {
this.hash = hash;
this.key = key;
this.value = value;
this.next = next;
}
}
ConcurrentHashMap的高并发主要来源于：
1、采用分段锁实现多个线程间的共享访问。
2、用HashEntry对象的不变性来降低执行读操作的线程在遍历链表期间对加锁的要求。
3、对于同一个volatile变量的读/写操作，协调不同线程间的读写内存的可见性问题。
1.8之后底层换成了CAS，把锁分段机制放弃了，CAS基本上是可以达到无锁境界
CAS + volatile无锁编程
在数据结构上， JDK1.8 中的ConcurrentHashMap 选择了与 HashMap 相同的Node数组+链表+红黑树结构；在锁的实现上，抛弃了原有的 Segment 分段锁，采用CAS + synchronized实现更加细粒度的锁。
将锁的级别控制在了更细粒度的哈希桶数组元素级别，也就是说只需要锁住这个链表头节点（红黑树的根节点），就不会影响其他的哈希桶数组元素的读写，大大提高了并发度。
在 JDK1.6 中，对 synchronized 锁的实现引入了大量的优化，并且 synchronized 有多种锁状态，会从无锁 ->
偏向锁 -> 轻量级锁 -> 重量级锁一步步转换。
减少内存开销 。假设使用可重入锁来获得同步支持，那么每个节点都需要通过继承AQS来获得同步支持。但并不是每个节点都需要获得同步支持的，只有链表的头节点（红黑树的根节点）需要同步，这无疑带来了巨大内存浪费。
ConcurrentHashMap的put方法流程（JDK1.7）：
public V put(K key, V value) {
//key，value不能为null
Segment<K,V> s;
if (value == null)
throw new NullPointerException();
//通过key进行哈希到对应segment位置
int hash = hash(key);
int j = (hash >>> segmentShift) & segmentMask;
//通过位置j获取当前的对应segment起始位置
if ((s = (Segment<K,V>)UNSAFE.getObject // nonvolatile; recheck
(segments, (j << SSHIFT) + SBASE)) == null) // in ensureSegment
s = ensureSegment(j);
return s.put(key, hash, value, false);
}
#内部类Segment下的put方法
final V put(K key, int hash, V value, boolean onlyIfAbsent) {
//尝试性加锁
HashEntry<K,V> node = tryLock() ? null :
scanAndLockForPut(key, hash, value);
V oldValue;
try {
//当前segment下的table
HashEntry<K,V>[] tab = table;
//通过key的哈希值进行哈希找到对应table位置
int index = (tab.length - 1) & hash;
HashEntry<K,V> first = entryAt(tab, index);
for (HashEntry<K,V> e = first;;) {
if (e != null) {
K k;
if ((k = e.key) == key ||(e.hash == hash && key.equals(k))) {
oldValue = e.value;
if (!onlyIfAbsent) {
//put方法处理：将新value替换oldvalue
e.value = value;
++modCount;
}
break;
}
e = e.next;
} else {
if (node != null)
node.setNext(first);
else
node = new HashEntry<K,V>(hash, key, value, first);
int c = count + 1;
if (c > threshold && tab.length < MAXIMUM_CAPACITY)
//超过扩容阈值
rehash(node);
else
setEntryAt(tab, index, node);
++modCount;
count = c;
oldValue = null;
break;
}
}
} finally {
//释放锁
unlock();
}
return oldValue;
}
//扩容仅针对某个segment进行扩容，而不是对整个ConcurrentHashMap进行扩容
private void rehash(HashEntry<K,V> node) {
//在segment下的table
HashEntry<K,V>[] oldTable = table;
int oldCapacity = oldTable.length;
//按照原大小2倍关系进行扩容
int newCapacity = oldCapacity << 1;
threshold = (int)(newCapacity * loadFactor);
HashEntry<K,V>[] newTable =(HashEntry<K,V>[]) new HashEntry[newCapacity];
int sizeMask = newCapacity - 1;
//将原有table上的所有hashentry节点进行重新哈希到新table上
for (int i = 0; i < oldCapacity ; i++) {
HashEntry<K,V> e = oldTable[i];
if (e != null) {
HashEntry<K,V> next = e.next;
int idx = e.hash & sizeMask;
if (next == null) // Single node on list
newTable[idx] = e;
else { // Reuse consecutive sequence at same slot
HashEntry<K,V> lastRun = e;
int lastIdx = idx;
for (HashEntry<K,V> last = next;
last != null;
last = last.next) {
int k = last.hash & sizeMask;
if (k != lastIdx) {
lastIdx = k;
lastRun = last;
}
}
newTable[lastIdx] = lastRun;
// Clone remaining nodes
for (HashEntry<K,V> p = e; p != lastRun; p = p.next) {
V v = p.value;
int h = p.hash;
int k = h & sizeMask;
HashEntry<K,V> n = newTable[k];
newTable[k] = new HashEntry<K,V>(h, p.key, v, n);
}
}
}
}
int nodeIndex = node.hash & sizeMask; // add the new node
node.setNext(newTable[nodeIndex]);
newTable[nodeIndex] = node;
table = newTable;
}
JDK1.8：
先定位到相应的 Segment ，然后再进行 put 操作。
首先会尝试获取锁，如果获取失败肯定就有其他线程存在竞争，则利用 scanAndLockForPut() 自旋获取锁。
1、尝试自旋获取锁。
2、如果重试的次数达到了 MAX_SCAN_RETRIES 则改为阻塞锁获取，保证能获取成功。
大致可以分为以下步骤：
1、根据 key 计算出 hash 值；
2、判断是否需要进行初始化；
3、定位到 Node，拿到首节点 f，判断首节点 f：
1、如果为 null ，则通过 CAS 的方式尝试添加；
2、如果为 f.hash = MOVED = -1 ，说明其他线程在扩容，参与一起扩容；
3、如果都不满足 ，synchronized 锁住 f 节点，判断是链表还是红黑树，遍历插入；
4、当在链表长度达到 8 的时候，数组扩容或者将链表转换为红黑树。
ConcurrentHashMap 的 get 方法是否要加锁，为什么？
get 方法不需要加锁。因为 Node 的元素 value 和指针 next 是用 volatile 修饰的，在多线程环境下线程A修改节点的 value 或者新增节点的时候是对线程B可见的。
这也是它比其他并发集合比如 Hashtable、用 Collections.synchronizedMap()包装的 HashMap 效率高的原因之一。
至于 ConcurrentHashMap 中的 key 为什么也不能为 null 的问题，源码就是这样写的，哈哈。如果面试官不满意，就回答因为作者Doug不喜欢 null ，所以在设计之初就不允许了 null 的 key 存在。
ConcurrentHashMap 的并发度是什么？
并发度可以理解为程序运行时能够同时更新 ConccurentHashMap且不产生锁竞争的最大线程数。在JDK1.7中，实际上就是ConcurrentHashMap中的分段锁个数，即Segment[]的数组长度，默认是16，这个值可以在构造函数中设置。
如果自己设置了并发度，ConcurrentHashMap 会使用大于等于该值的最小的2的幂指数作为实际并发度，也就是比如你设置的值是17，那么实际并发度是32。
如果并发度设置的过小，会带来严重的锁竞争问题；如果并发度设置的过大，原本位于同一个Segment内的访问会扩散到不同的Segment中，CPU cache命中率会下降，从而引起程序性能下降。
在JDK1.8中，已经摒弃了Segment的概念，选择了Node数组+链表+红黑树结构，并发度大小依赖于数组的大小。
ConcurrentHashMap 迭代器是强一致性还是弱一致性？
与 HashMap 迭代器是强一致性不同，ConcurrentHashMap 迭代器是弱一致性。
ConcurrentHashMap 的迭代器创建后，就会按照哈希表结构遍历每个元素，但在遍历过程中，内部元素可能会发生变化，如果变化发生在已遍历过的部分，迭代器就不会反映出来，而如果变化发生在未遍历过的部分，迭代器就会发现并反映出来，这就是弱一致性。
这样迭代器线程可以使用原来老的数据，而写线程也可以并发的完成改变，更重要的，这保证了多个线程并发执行的连续性和扩展性，是性能提升的关键。
JDK1.7 与 JDK1.8 中ConcurrentHashMap 的区别？