什么是Hash
Hash,也可以称为“散列”,就是把任意长度的输入,通过散列算法,变换成固定长度的输出,该输出就是散列值。这是一种压缩映射,也就是,散列值的空间通常远小于输入的空间,不同的输入可能会散列成相同的输出(也就是多对一的关系)。
哈希表的构造
在所有的线性数据结构中,数组的定位速度最快,因为它可通过数组下标直接定位到相应的数组空间,就不需要一个个查找。而哈希表就是利用数组这个能够快速定位数据的结构解决以上的问题的。
"数组可以通过下标直接定位到相应的空间”,对就是这句,哈希表的做法其实很简单,就是把Key通过一 个固定的算法函数既所谓的哈希函数转换成一个整型数字,然后就将该数字对数组长度进行取余,取余结果就当作数组的下标,将value存储在以该数字为下标 的数组空间里,而当使用哈希表进行查询的时候,就是再次使用哈希函数将key转换为对应的数组下标,并定位到该空间获取value,如此一来,就可以充分 利用到数组的定位性能进行数据定位。
例如: 如果一个hash函数是这样的,
index = value % 5;
如下图中,左边为一个长度为5的指针数据,下标从0到4,每个数据元素都是一个链表的头指针,这样通过value%5就形成了一种一对多的关系,缩小了查找的范围。
虽然我们不希望发生冲突(同一个key有多个value),但实际上发生冲突的可能性仍是存在的。当关键字值域远大于哈希表的长度,而且事先并不知道关键字的具体取值时。冲突就难免会发生。另外,当关键字的实际取值大于哈希表的长度时,而且表中已装满了记录,如果插入一个新记录,不仅发生冲突,而且还会发生溢出。因此,处理冲突和溢出是哈希技术中的两个重要问题。一般有开放地址法、链地址法。
看到了一个叫做One-Way Hash的算法(来自暴雪的hash算法)。
如果说两个不同的字符串经过一个哈希算法得到的入口点一致有可能,但用三个不同的哈希算法算出的入口点都一致,那几乎可以肯定是不可能的事了,这个几率是1:18889465931478580854784,大概是10的 22.3次方分之一,对一个游戏程序来说足够安全了。第一个hash值作为用来定位,另外两个hash值用来检测。
Hash的实例JDK7与JDK8中HashMap的实现
适用范围
快速查找,删除的基本数据结构,通常需要总数据量可以放入内存。
什么是Map
Map是c++标准库STL提供的一类关联式容器,提供key-value的存储和查找功能。
Map是基于红黑树的(同样set也是)(Java中有基于Hash实现的HashMap和HashSet),那么它的查找速度是log(n)级别的。
它的优点是占用内存小。
Hash与Map的区别
权衡三个因素: 查找速度, 数据量, 内存使用,可扩展性,有序性。
总体来说,hash查找速度会比RB树快,而且查找速度基本和数据量大小无关,属于常数级别;而RB树的查找速度是log(n)级别。并不一定常数就比log(n) 小,hash还有hash函数的耗时,明白了吧,如果你考虑效率,特别是在元素达到一定数量级时,考虑考虑hash。但若你对内存使用特别严格, 希望程序尽可能少消耗内存,那么一定要小心,hash可能会让你陷入尴尬,特别是当你的hash对象特别多时,你就更无法控制了,而且 hash的构造速度较慢。
红黑树并不适应所有应用树的领域。如果数据基本上是静态的,那么让他们待在他们能够插入,并且不影响平衡的地方会具有更好的性能。如果数据完全是静态的,例如,做一个哈希表,性能可能会更好一些。
在实际的系统中,例如,需要使用动态规则的防火墙系统,使用红黑树而不是散列表被实践证明具有更好的伸缩性。Linux内核在管理vm_area_struct时就是采用了红黑树来维护内存块的。
红黑树是有序的,Hash是无序的,根据需求来选择。
拿红黑树实现的Map和Hash实现的HashMap相比:
如果只需要判断Map中某个值是否存在之类的操作,当然是Hash实现的要更加高效。
如果是需要将两个Map求并集交集差集等大量比较操作,就是红黑树实现的Map更加高效。
AVL树与红黑树的区别
如果你google“avl vs. red-black”,第一个返回的页面将在很大程度上回答你的问题。总之,AVL树的高度至多为1.44log(N),低于红黑树的最大高度〜2log(N)。然而,插入后,AVL树可能需要O(log(N))操作来重新平衡树,但是红黑树需要O(1)。这意味着AVL树在搜索上可能更快,而插入速度更慢。此外,红黑树更容易被实现为持久数据结构。Reference:
1. http://www.cnblogs.com/coder2012/p/3386101.html2. http://www.lxway.com/852122226.htm
3. http://46aae4d1e2371e4aa769798941cef698.devproxy.yunshipei.com/u012609067/article/details/35849887
4.https://attractivechaos.wordpress.com/2008/10/02/comparison-of-binary-search-trees/