HashMap真的是大于8就转换成红黑树,小于6就变成链表吗???

这篇文章仅限小编个人的理解,小编不是Java方向的,只是对Java有很高的学习兴趣
如果有什么不对的地方还望大佬指点
QQ交流群: 99979568

HashMap的底层是数组+链表,(很多人应该都知道了)
JDK1.7的是数组+链表
(1.7只是一个例子,以前的话也是这样后面就以1.7为例子了)
首先是一个数组,然后数组的类型是链表
元素是头插法
JDK1.8的是数组+链表 或者 数组+红黑树
首先是一个数组,然后数组的类型是链表
在链表的元素大于8的时候,会变成红黑树
在红黑树的元素小于6的时候会变成链表
(这里需要注意,不是元素小于6的时候一定会变成链表,只有resize的时候才会根据UNTREEIFY_THRESHOLD 进行转换,同样也不是到8的时候就变成红黑树 链表与红黑树的转换详情
元素进行尾插

HaspMap的数组默认大小为16
数组也叫做Hash桶
(貌似听说这个值和阿里巴巴Java开发手册好像有点关系)

HashMap元素的下标是
HashCode(元素) & (数组的长度-1)

HashMap的扩容 Resize

扩容的话,这里有一个值叫做loadFactor(阈值),默认值为0.75;
当数组的 元素数量>数组大小(默认16)* loadFactor(默认0.75)
就会触发扩容,扩容是二倍扩容的 (默认是16扩容后就是32)
这时原来每个元素的下标也会改变的(因为数组的长度变了)
然后就要把每个元素重新分配下标,重新加入链表或者红黑树

HashMap线程不安全
在put的时候,Resize(扩容)会造成数据的覆盖
JDK1.7 因为是头插法,可能会造成循环链表
JDK1.8 是尾插法

使用HashMap怎么才能让他线程安全
使用ConcurrentHashMap,
JDK1.7的是分段数组,有Segment锁(继承于ReentrantLock)加速一小段保证并发
JDK1.8 是和HashMap一样了,数组+链表(或者红黑树)
Synchronized(锁)and CAS(compare and swap)
(JVM在1.6对Synchronize的优化很好)
CAS通俗易懂,比较并替换
(CAS是一种无锁算法,CAS有3个操作数,内存值V,旧的预期值A,要修改的新值B。当且仅当预期值A和内存值V相同时,将内存值V修改为B,否则什么都不做)
(无锁化的修改值的操作,他可以大大降低锁代理的性能消耗。这个算法的基本思想就是不断地去比较当前内存中的变量值与你指定的 一个变量值是否相等,如果相等,则接受你指定的修改的值,否则拒绝你的操作。因为当前线程中的值已经不是最新的值,你的修改很可能会覆盖掉其他线程修改的结果。这一点与乐观锁,SVN的思想是比较类似的)

使用HashTable(基本是废弃的)
HashTable就是把HashMap套上了一个Synchronized

Collections.synchronizedMap()包装
使用synchronized 加上,但是这个是对某个Hash桶(数组的某个值)加锁,并不是整个map加锁,在锁定的时候别的线程也可以进行访问

小编暂时就了解这个多了,有什么遗漏的还望大佬评论

猜你喜欢

转载自blog.csdn.net/weixin_46285416/article/details/107555123