HashMap深度解析(二)
来源:互联网 发布:淘宝双十一便宜多少 编辑:程序博客网 时间:2024/05/30 23:31
版权声明:本文为博主原创文章,转载请注明出处http://blog.csdn.net/ghsau。
本文来自:高爽|Coder,原文地址:http://blog.csdn.net/ghsau/article/details/16890151,转载请注明。
上一篇比较深入的分析了HashMap在put元素时的整体过程,Java Collections Framework中实际操作的都是数组或者链表,而我们通常不需要显示的维护集合的大小,而是集合类框架中内部维护,方便的同时,也带来了性能的问题。
HashMap有两个参数影响其性能:初始容量和加载因子。默认初始容量是16,加载因子是0.75。容量是哈希表中桶(Entry数组)的数量,初始容量只是哈希表在创建时的容量。加载因子是哈希表在其容量自动增加之前可以达到多满的一种尺度。当哈希表中的条目数超出了加载因子与当前容量的乘积时,通过调用 rehash 方法将容量翻倍。
HashMap中定义的成员变量如下:
HashMap()
构造一个具有默认初始容量 (16) 和默认加载因子 (0.75) 的空 HashMap。
HashMap(int initialCapacity)
构造一个带指定初始容量和默认加载因子 (0.75) 的空 HashMap。
HashMap(int initialCapacity, float loadFactor)
构造一个带指定初始容量和加载因子的空 HashMap。
HashMap(Map<? extendsK,? extendsV> m)
构造一个映射关系与指定 Map 相同的 HashMap。 看一下第三个构造方法源码,其它构造方法最终调用的都是它。
我们在日常做底层开发时,必须要严格控制入参,可以参考一下Java源码及各种开源项目源码,如果参数不合法,适时的抛出一些运行时异常,最后到应用层捕获。看第14-16行代码,这里做了一个移位运算,保证了初始容量一定为2的幂,假如你传的是5,那么最终的初始容量为8。源码中的位运算随处可见啊=。=!
到现在为止,我们有一个很强烈的问题,为什么HashMap容量一定要为2的幂呢?HashMap中的数据结构是数组+单链表的组合,我们希望的是元素存放的更均匀,最理想的效果是,Entry数组中每个位置都只有一个元素,这样,查询的时候效率最高,不需要遍历单链表,也不需要通过equals去比较K,而且空间利用率最大。那如何计算才会分布最均匀呢?我们首先想到的就是%运算,哈希值%容量=bucketIndex,SUN的大师们是否也是如此做的呢?我们阅读一下这段源码:
通常,默认加载因子 (.75) 在时间和空间成本上寻求一种折衷。加载因子过高虽然减少了空间开销,但同时也增加了查询成本(在大多数 HashMap 类的操作中,包括 get 和 put 操作,都反映了这一点,可以想想为什么)。在设置初始容量时应该考虑到映射中所需的条目数及其加载因子,以便最大限度地降低 rehash 操作次数。如果初始容量大于最大条目数除以加载因子(实际上就是最大条目数小于初始容量*加载因子),则不会发生 rehash 操作。
如果很多映射关系要存储在 HashMap 实例中,则相对于按需执行自动的 rehash 操作以增大表的容量来说,使用足够大的初始容量创建它将使得映射关系能更有效地存储。 当HashMap存放的元素越来越多,到达临界值(阀值)threshold时,就要对Entry数组扩容,这是Java集合类框架最大的魅力,HashMap在扩容时,新数组的容量将是原来的2倍,由于容量发生变化,原有的每个元素需要重新计算bucketIndex,再存放到新数组中去,也就是所谓的rehash。HashMap默认初始容量16,加载因子0.75,也就是说最多能放16*0.75=12个元素,当put第13个时,HashMap将发生rehash,rehash的一系列处理比较影响性能,所以当我们需要向HashMap存放较多元素时,最好指定合适的初始容量和加载因子,否则HashMap默认只能存12个元素,将会发生多次rehash操作。
HashMap所有集合类视图所返回迭代器都是快速失败的(fail-fast),在迭代器创建之后,如果从结构上对映射进行修改,除非通过迭代器自身的 remove 或 add 方法,其他任何时间任何方式的修改,迭代器都将抛出 ConcurrentModificationException。因此,面对并发的修改,迭代器很快就会完全失败。注意,迭代器的快速失败行为不能得到保证,一般来说,存在不同步的并发修改时,不可能作出任何坚决的保证。快速失败迭代器尽最大努力抛出 ConcurrentModificationException。至于为什么通过迭代器自身的remove或add方法就不会出现这个问题,可以参考我之前的文章List比较好玩的操作中第三个和第四个示例。
HashMap是线程不安全的实现,而HashTable是线程安全的实现,关于线程安全与不安全可以参考我之前的文章Java线程(一):线程安全与不安全,所谓线程不安全,就是在多线程情况下直接使用HashMap会出现一些莫名其妙不可预知的问题,多线程和单线程的区别:单线程只有一条执行路径,而多线程是并发执行(非并行),会有多条执行路径。如果HashMap是只读的(加载一次,以后只有读取,不会发生结构上的修改),那使用没有问题。那如果HashMap是可写的(会发生结构上的修改),则会引发诸多问题,如上面的fail-fast,也可以看下这里,这里就不去研究了。
那在多线程下使用HashMap我们需要怎么做,几种方案:
- 在外部包装HashMap,实现同步机制
- 使用Map m = Collections.synchronizedMap(new HashMap(...));,这里就是对HashMap做了一次包装
- 使用java.util.HashTable,效率最低
- 使用java.util.concurrent.ConcurrentHashMap,相对安全,效率较高
本文来自:高爽|Coder,原文地址:http://blog.csdn.net/ghsau/article/details/16890151,转载请注明。
- HashMap深度解析(二)
- HashMap深度解析(二)
- HashMap深度解析(二)
- HashMap深度解析(二)
- HashMap深度解析(二)
- HashMap深度解析(二)
- HashMap深度解析(二)
- HashMap深度解析(二)
- HashMap深度解析(二)
- HashMap深度解析(二)
- HashMap深度解析(二)
- HashMap深度解析(二)
- HashMap深度解析(一)
- HashMap深度解析
- HashMap深度解析(一)
- HashMap深度解析(一)
- HashMap深度解析(一)
- HashMap深度解析(一)
- 冒泡排序
- C++的可移植性和跨平台开发
- Java中this关键字的几种用法
- Android疯狂ListViw之旅 第二季之 分组排序显示数据
- 数据结构(14)--线索二叉树的实现
- HashMap深度解析(二)
- 字符格式的数字转化为整型数字
- linux打包压缩命令汇总
- Android源码树中C代码的编译
- Git_配置merge工具
- 几个linux 技巧
- Java程序员人生:J2ee的学习流程
- jqgrid---将列表中的字典值转换成中文词义
- UNIX环境高级编程第十七章 高级进程间通信 总结