hashmap

Java 8 HashMap的分离链表 从Java 2到Java 1.7，HashMap在分离链表上的改变并不多，他们的算法基本上是相同的。如果我们假设对象的Hash值服从平均分布，那么获取一个对象需要的次数时间复杂度应该是 O ( N M ) O(NM)（原为 E ( N M ) E(NM)，但数学期望应改为 E ( N 2 M ) E(N2M)疑有误，译者注）。 Java 8 在没有降低哈希冲突的度的情况下，使用 红黑树 代替 链表 ，将这个值降低到了 O ( log ( N M ) ) O(log⁡(NM))（与上同，疑有误，译者注）。 数据越多， O ( N M ) O(NM)和 O ( log ( N M ) ) O(log⁡(NM))的差别就会越明显。此外，在实践中，Hash值的分布并非均匀的，正如”生日问题”所描述那样，哈希值有时也会集中在几个特定值上。因此使用平衡树比如红黑树有着比使用链表更强的性能。 使用链表还是树，与一个哈希桶中的元素数目有关。 下面的代码展示了Java 8的HashMap在使用树和使用链表之间切换的阈值。 当冲突的元素数增加到8时，链表变为树； 当减少至6时，树切换为链表。 中间有2个缓冲值的原因是避免频繁的切换浪费计算机资源。 static final int TREEIFY_THRESHOLD = 8; static final int

HashMap，HashTable，ConcurrentHashMap 一.HashTable 底层数组+链表实现，无论key还是value都不能为null，线程安全，实现线程安全的方式是在修改数据时锁住整个HashTable，效率低，ConcurrentHashMap做了相关优化 初始size为11，扩容：newsize = olesize*2+1 计算index的方法：index = (hash & 0x7FFFFFFF) % tab.length 二.HashMap 1.7版本以前底层数组+链表实现，1.8版本后为数组+链表/红黑树，可以存储null键和null值，线程不安全 初始size为16，扩容：newsize = oldsize*2，size一定为2的n次幂 扩容针对整个Map，每次扩容时，原来数组中的元素依次重新计算存放位置，并重新插入 插入元素后才判断该不该扩容，有可能无效扩容（插入后如果扩容，如果没有再次插入，就会产生无效扩容） 当Map中元素总数超过Entry数组的75%，触发扩容操作，为了减少链表长度，元素分配更均匀 计算index方法：index = hash & (tab.length – 1) HashMap的初始值还要考虑加载因子: 哈希冲突：若干Key的哈希值按数组大小取模后，如果落在同一个数组下标上，将组成一条Entry链

记得曾经有个著名大师谁谁谁曾经说过：你有一个思想，我有一个思想，我们交换一下，一人就有两个思想；你有一个苹果，我有一个苹果，我们交换一下，一人还是一个苹果。那既然这样的话，用我的iPhone 7 换你的 iPhone 11 如何？ 这次给大家带来的是HashMap原理第二篇之——HashMap扩容的底层代码和算法分析。需要说明的是本文是基于jdk1.8来进行展开的，今后有机会会和大家分享在jdk1.7中HashMap的实现方式和1.8有哪些区别（扩容方式是其中的区别之一）。有朋友会说，既然HashMap是基于数组+单向链表+红黑树的底层数据结构，链表可以无限地延伸啊，红黑树也可以不停滴往里面放东西啊，还扩容干什么？这样的说法既对也不对，说对是因为HashMap确实是基于单向链表和红黑树的，但是有没有想过不断地往链表上添加元素或者不断地往树里面加东西会怎么样？是不是会导致链表过长以及树的深度增大？是不是进而会提高遍历链表或者红黑树的时间复杂度？最终导致从表现上来看插入和查找操作会越来越慢？所以，到了一定程度对数组扩容还是很有必要的。那又有朋友会问：扩容很简单啊，需要的时候从数组两端往外延伸一下内存空间不就可以了吗？……想啥呢？数组不是拉面，需要的时候从两边往外抻一下，不存在的！数组扩容只能开辟出一个更大的内存空间出来，将原来的内容迁移到新的内存空间里面。OK