File tree Expand file tree Collapse file tree 1 file changed +6
-1
lines changed Expand file tree Collapse file tree 1 file changed +6
-1
lines changed Original file line number Diff line number Diff line change 99| 扩容之后容量为原来的1.5倍| 无|
1010
1111### HashMap
12- 1 . JDK 1.8 以前 HashMap 的实现是 数组+链表 ,即使哈希函数取得再好,也很难达到元素百分百均匀分布。当 HashMap 中有大量的元素都存放到同一个桶中时,这个桶下有一条长长的链表,这个时候 HashMap 就相当于一个单链表,假如单链表有 n 个元素,遍历的时间复杂度就是 O(n),完全失去了它的优势。针对这种情况,JDK 1.8 中引入了红黑树(查找时间复杂度为 O(logn))来优化这个问题
12+ 1 . JDK 1.8 以前 HashMap 的实现是 数组+单链表 ,即使哈希函数取得再好,也很难达到元素百分百均匀分布。当 HashMap 中有大量的元素都存放到同一个桶中时,这个桶下有一条长长的链表,这个时候 HashMap 就相当于一个单链表,假如单链表有 n 个元素,遍历的时间复杂度就是 O(n),完全失去了它的优势。针对这种情况,JDK 1.8 中引入了红黑树(查找时间复杂度为 O(logn))来优化这个问题
13132 . 为什么线程不安全?多线程PUT操作时可能会覆盖刚PUT进去的值;扩容操作会让链表形成环形数据结构,形成死循环
14143 . 容量的默认大小是 16,负载因子是 0.75,当 HashMap 的 size > 16* 0.75 时就会发生扩容(容量和负载因子都可以自由调整)。
15154 . 为什么容量是2的倍数?在根据hashcode查找数组中元素时,取模性能远远低于与性能,且和2^n-1进行与操作能保证各种不同的hashcode对应的元素也能均匀分布在数组中
1616
17+ ### HashMap rehash过程:
18+ 1 . 空间不够用了,所以需要分配一个大一点的空间,然后保存在里面的内容需要重新计算 hash
19+ 2 . 如果两个线程都发现HashMap需要重新调整大小了,它们会同时试着调整大小
20+ 3 . 在调整大小的过程中,存储在链表中的元素的次序会反过来,因为移动到新的bucket位置的时候,HashMap并不会将元素放在链表的尾部,而是放在头部,这是为了避免尾部遍历(tail traversing)。如果条件竞争发生了,那么就死循环了
21+
1722### ConcurrentHashMap原理
1823[ http://www.jasongj.com/java/concurrenthashmap/ ] ( http://www.jasongj.com/java/concurrenthashmap/ )
1924
You can’t perform that action at this time.
0 commit comments