1、HashMap的底层和详解:
1、transient Node<k,v>[] table; Node对象的属性: final int hash; final K key; V value; Node<k,v> next;
2、查找时,先通过哈希定位,然后遍历链表,对每个key进行equals逐一比对(链表越少性能越高)。
3、默认initialCapacity=16;loadFactory=0.75;当桶中链表节点数大于8时将链表转换为红黑树,小于6时退化成链表;最小的树化容量是64(键值对大于64时才转红黑树,防止前期多个kv恰好放在同一个桶,做不必要的转化)
4、多线程环境下操作HashMap的问题:并发环境下的增删(只并发读不会有问题),rehash过程可能会带来循环链表,一旦存在循环链表,get/put等操作会导致死循环,致使线程挂掉、CPU打满。
2、HashTable的底层:
类似1.7的hashMap,每个方法加上了synchronized同步。
3、ConcurrentHashMap的底层:
1、1.7和1.8的对比:
1.7:final Segment<K,V>[] segments; Segment分段锁,继承了ReentrantLock可重入锁。
1.8:transient volatile Node<k,v>[] table; 改回Node<k,v>;去掉了分段锁,改为synchronized锁该Node的头节点,降低锁的粒度; 新增链表转红黑树逻辑。
2、底层类似HashMap(数组+链表/红黑树,也会数组扩容、链表转红黑树)。 异:value和next增加volatile修饰;synchronized锁头节点。
3、concurrencyLevel:并发级别,默认16,表示Segment的个数,CHM创建完成之后不可改(1.7final数组的原因),扩容过程改变的是每个Segment的大小。当Segment越来越大时,锁的粒度也变大。
4、get操作全程不用加锁,效率很高:利用volatile的可见性。同时,ConcurrentHashMap通过final属性和CAS操作提高效率。
5、分段锁的优缺:
优:操作不同段map的时候可以并发,减小直接synchronized的粒度
缺:分多段时内存不连续,碎片化。定位元素位置时需要hash两次。同一个分段锁竞争小时,可重入锁降低了效率;竞争大时,锁性能下降。
7、spring自己的缓存是基于ConcurrentHashMap实现的
4、TreeMap的底层:
底层通过红黑树 实现;Node的排序是根据key的值来比较的;为了维护红黑树的结构,每次增删节点时可能会重排
5、Fast-Fail机制:modCount,使用迭代器时,其他线程修改了,便直接报错。
6、遍历map: ketSet(); entrySet();(优)
一、HashMap和HashTable的区别
1.底层数据结构: HashMap:数组+链表/红黑树,HashTable:数组+链表+synchronized。是否线程安全。
2.父类:HashMap-->AbstractMap类,HashTable-->老Dictionary类,都实现了Map接口。
3.是否允许null:HashMap可以一个key为null或者多个value为null,HashTable的k/v都不能,如果有null会报空指针。
4.内部数组扩容方式: HashMap默认size16且扩容时必须是2的整数次幂,HashTable默认11扩容时2n+1
二、hashMap和treeMap的区别
底层数据结构不同(哈希表和红黑树)。treeMap适用于需要对key进行排序的场景,hashMap的增删改查比treeMap快(数据结构原因)。 都线程不安全。
三、Hashtable和ConcurrentHashMap底层区别
底层数据结构的区别;加锁方式的区别;
四、Hashmap的扩容机制
数组默认size=16,默认负载因子=0.75,当hashMap里面存的数据>数组size*0.75时,数组扩容。频繁的数组扩容非常影响效率,如果在初始化的时候大概知道大小的话,创建的时候附默认值能提高性能。 扩容时,size都是2的整数次幂,方便提升性能(通过限制length是一个2的幂数,h & (length-1)和h % length结果是一致的,位运算&的速度比取余%效率高)
五、ConcurrentHashMap的桶分割原理
一、谈谈你理解的 HashMap,讲讲其中的 get put 过程。
二、1.8 做了什么优化?
三、是线程安全的吗?
四、不安全会导致哪些问题?
五、如何解决?有没有线程安全的并发容器?
六、ConcurrentHashMap 是如何实现的? 1.7、1.8 实现有何不同?为什么这么做?