本篇的内容是围绕哈希表来展开的，主要是通对HashMap，Hashtable，ConcurrentHashMap三者的特点去了解这它们之间的区别以及运用场景
目录
ConcurrentHashMap做出的优化（以JDK8为例）
1. HashMap
HashMap是继承与Map集合类的，其内部的方法是没有对线程安全进行处理的，所以HashMap是线程不安全的，在当今高并发的时代需要处理线程安全问题显然这种场景再使用HashMap就已经不太合适了。
所以针对多线程的开发环境就有了Hashtable和ConcurrentHashMap这两个线程安全的HashMap
2. Hashtable
Hashtable类做出的主要是针对HashMap类的主要的方法进行简单的加锁，用synchronized关键字对主要的方法进行修饰保证线程安全
原码：
put方法：
remove方法：
get方法：
优点：弥补了普通HashMap不能保证线程安全的缺点
缺点：
锁太粗问题：
通过原码我们看到为了保证map的线程安全只是给方法直接加synchronized关键字，但是这样的操作显然效率很低；
1. 因为每一个synchronized的锁对象都是this，都是调用方法的对象本身，此时在多线程下不管同时进行任何加锁操作都需要串行执行，就算是通过get多线程操作拿value值也是串行执行的，但本身只拿的话其实并不涉及到线程安全，白白损耗效率。
2. 我们都知道每个key的哈希桶里的值都互不相关，比如key为1的元素和key为2的元素分别在不同的哈希桶里本身就是分开的，此时我们同时对不同key关键字的桶里put元素也不换有线程安全问题，但是Hashtable每个方法的锁对象都是this，所以即使互不相关也会产生锁冲突串行执行，白白损耗效率
图：
3. 扩容机制问题
Hashtable 的扩容机制是，当负载因子达到扩容条件时，那么该线程就会重新创建一个新map再把原map中的所有元素都一次性的全部拷贝到新map上然后在进行替换，这个过程涉及到大量元素拷贝过程，也是效率很低
当map太大且进行到当前扩容操作时，此时此次操作就会花费很长时间，影响使用
3. ConcurrentHashMap
ConcurrentHashMap 也是一种线程安全的哈希表，并且在老大哥Hashtable的基础上做出了很多优化，现在ConcurrentHashMap已经被广泛使用在高并发的场景下了
图：
ConcurrentHashMap做出的优化（以JDK8为例）
1. 读操作优化：
读操作取消了加锁操作，但是使用了volatile关键字保证了内存的可见性，即使其他线程更改了数据，也能感知到
2. 锁的粗细优化：
ConcurrentHashMap让key的哈希桶都有一个单独的锁来控制，这个锁是当前当前key的第一个元素，可以保证多线程下每次对该桶进行操作加锁的都是这个锁对象，保证操作的线程安全，且桶与桶之间的操作由于是不同锁对象控制所以不存在锁竞争，大大提高了并发的程度
3. 扩容机制优化（化整为零）：
参考分摊的思想理解：
哈希表在负载因子过高导致扩容时，一次性把所以元素拷贝到位的效率太低了，可能会导致当前步骤导致时间卡顿，由于哈希表的put和get等操作都是O(1)，只是扩容这一步操作消耗的时间很多，那么把扩容这个步骤拆分为多个小块，分摊到每次操作的步骤中。
ConcurrentHashMap就不会一次性直接把所有元素拷贝到位，而是先创建好新的map,再拷贝一小部分元素到新的map里，在后续每次操作map时都拷贝一部分元素到新的map中，直到老的map全部被拷贝完，再舍弃老的map，只保留新的map
细节：那么在扩容期间就存在新老两个map了，进行put操作时会直接往新的map中放，删除和查找则是都是在新老两个map中找到元素
4.三者区别
HashMap：多线程使用的环境下存在线程安全问题
Hashtable: 保证了线程安全，但是由于所有方法都同用一把锁（this）导致锁的粒度过粗，没有很好的并发效果，且在扩容时效率低下
ConcurrentHashMap：保证了线程安全，且在Hashtable上做出了很多优化(介绍主要的几点)
1. 每个桶的锁进行了分离，分别控制加锁解锁
2. 取消了读加锁的机制，通过使用volatile关键字保证了内存可见性
3. 扩容是采用了分摊，不在让这一次的高消耗一次性执行完，而是分摊到后续的操作中，进而抵消时间损耗的峰值，让每次操作都变的效率比较高
本篇文章介绍到这里就结束了，欢迎各位友友的补充和纠错！
7397
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
