05_hashmap的个人总结
hashmap<K,V> jdk10 土味翻译
hash表基于map接口的继承。这个继承提供了所有的map操作,允许空值和空键.hashmap类大致有hashtable,除了它不能并发和允许空值。这个类不能保证map的顺序,尤其是它不能保证数据的顺序一直不变。对于get和put的执行时间是常量,假如hash功能合适的分散在集合中。集合上的迭代需要时间和hashmap实例的容量成比例。因此,如果迭代性能很重要,不要设置初始容量太大或者装载因子太小。
hashmap的实例有两个因素去影响它的性能:初始容量和装载因子。容量是hashtable中使成组的数量,初始容量是hashtable创建时的容量。装载因子是衡量hashmap有多满.当添加的数据的数量超过装载因子和现在的数量,hashtable的容量将会被扩大两倍。
通常规则,默认装载因子提供一个好的权衡在时间和空间消耗。更多的值降低了空间成本但是增加了查找成本。添加数据的数量和装载因子应该被考虑当设置初始容量,因此最小化hash操作的数量。如果最初容量大于数据的最大值/装载因子。
如果许多集合存储在hashmap实例,用足够大的容量有效存储比执行的时候自动扩大容量效率更高。使用许多有相同hashcode的键是一个好的方式去降低hash表的性能。去减低影响,当键是可比较的,类可以使用可比较的顺序在键来帮助打破关系。
这种继承不是并发的,如果多线程访问一个hashmap同时,至少其中一个线程修改map在结构上修改map,它必须外部并发。这是典型地实现通过并发封装在map中的对象。如果没有这种对象存在,map应该被包装使用collections.synchronizedMap方法。这是最好的在创建时间,阻止意外的非并发访问map.
Map m = Collections.synchronizedMap(new HashMap(...));这种类的集合方法返回的迭代器是失败的。如果map在结构上被修改在迭代器被创建之后,以任何方式除了通过迭代器自己的删除方法,迭代器将会抛出一个并发修改异常。因此,面对并发修改,迭代器没有快而简洁的,而是任意增加,在未来在不确定的时间用不确定的行为。迭代器的快速故障行为不能得到保证,进一步说,不可能去绝对保证当高并发修改。快速故障迭代器抛出ConcurrentModificationException异常在在最大努力的基础上。因此,写一个项目取决于它的正确性的异常是错误的,迭代器的快速故障行为被用来仅仅探测异常。这个类是java集合框架的一个成员。
overhead:成本
synchronize:并发
disperse:分散
performance:性能
load factor:装载因子
proportional:成比例的
rehash:再哈希
structural:结构的