【JAVA】关于HASH算法更深入的阐述

写在前面的

   最近在项目上碰到一些问题，经常接触工业生产的同志们应该都会碰到过—如何快速准确的进行产品追溯。也就是如何在非常短的时间内，从几十亿条数据中定位到组成我这个产品的零件的属性以及当时工业生产的一些记录等等。由于甲方框架并不允许使用第三方插件，在经过了对硬件性能以及数据库中存储过程的语法以及SQL查询语句的优化之后，我尝试着在代码中加入了HASH的部分概念，识图经过这种唯一编码的寻址能够继续提升效率。但是事与愿违，在一定程度上HASH的确能够帮助我们的系统提高效率，但是当数据量达到一定量级的时候，HASH好像并没有想象中的那么给力。究竟是为什么呢？

原因

   当参考一些HASH算法的核心思想和一些大神们自己的看法之后，我也渐渐明白了HASH算法的里层远远不止复杂度为O(1)那么简单，我们其实被HASH的外表所欺骗了。

   的确，在绝大多数或者称“一般”的业务场景中，HASH算法所带来的查找定位的复杂度确实是O（1），这就给我们造成了一个错觉，HASH简直就是神一般的存在，因为在我们常用的缓存Redeis和Memcached中也是通过这种理念快速定位和查找的，但是我们非常容易忽略一个问题—HASH真的不需要遍历么？答案当然是肯定的，HASH也需要遍历！

   由于HASH内部采用HashCode自动进行编码，其对于一些相同性质的数据，HashCode采用类似对象头部的标识符来形成编码的一部分，也就是HASH将这些数据暗地里进行了分类，这样就形成了专业术语所说的“桶”，多笔性质相同的数据就会根据HashCode被分在同一个“桶”里。当我们进行定位的时候，首先找到符合数据性质的“桶”，然后再依次遍历“桶”中的符合条件的数据，最后将其定位。

   说到这里，基本上我们就可以理解，为什么当数据量达到一定的量级之后，HASH并没有预期的那样强大了吧。由于同一个“桶”中的数据量不断的增大，导致遍历该“桶”的时间增多，HASH的性能也就慢慢的低了下来。这也正是（个人认为）只有少部分数据存储结构采用HASH来做索引的原因。

   最后可能还会有一个问题那为什么无论多大的数据量而Redis和Memcahced会很快呢？因为这两个货从其他方面弥补了HASH的一些缺陷，推荐一篇文章，大家可以简单的了解一部分。点击这里

总结

   总之，就像我们常说的，永远没有一个框架或者算法可以成为“万金油”，只有扎实的功底才能解决关键性的问题，毕竟框架就是这些原理堆砌而成的嘛！