HASH GAME - Online Skill Game GET 300

　　第一，填装因子，所谓的填装因子是指哈希表中已存入的数据元素个数与哈希地址空间大小的比值，即α=n/m，α越小，冲突的可能性就越小，相反则冲突可能性越大；但是α越小，哈希表的存储空间利用率也就很低，α越大，存储空间的利用率也就越高，为了兼顾哈希冲突和存储空间利用率，通常将α控制在0.6-0.9之间（JDK中取0.75），而的Hashtable则直接将α的最大值定义为0.72（注：虽然微软官方MSDN中声明Hashtable默认填装因子为1.0，事实上所有的填装因子都为0.72的倍数）；

　　.NET中实现了哈希表的类分别是HashtableDictionaryTKey, TValueHashtable由包含集合元素的存储桶组成，存储桶是Hashtable中各元素的虚拟子组，与大多数集合中进行的搜索相比，存储桶可使搜索更为便捷。Dictionary则是泛型版本的哈希表，与Hashtable的功能相同，对于值类型，特定类型（不包括Object）的性能优先于Hashtable，这是因为Hashtable的元素属于Object类型，所以在存储或者检索类型时通常发生装箱和拆箱操作；除此之外，虽然微软宣称Hashtable是线程安全的，可以允许多个读线程或一个写线程访问，但是事实是它也并非线程安全，在.NET Framework 2.0新引入的Dictionary仍旧为解决这个问题，其中限于公共静态方法是线程安全的，因此可以说Dictionary是非线程安全的，而且对整个集合的枚举过程对二者而言都不是线程安全的，因为当出现枚举与写访问互相争用这种情况发生时，则必须在整个枚举过程中对整个集合加锁。如果我们在使用.NET Framework 4.0以上版本，我们可以使用线程安全的ConcurrentDictionary；另一个比较重要的区别在于，虽然它们都实现了哈希表，但是二者却使用了完全不同的哈希冲突解决方法，Hashtable解决冲突的方式是开放定址法，而Dictionary则采用了链表法。

　　插入元素[40, “elem3”]，此时的哈希表进行扩容，为什么会在此时扩容呢，哈希表的填装因子为2/3=0.66并未超过0.72，在.NET中，微软对填装因子进行了换算，通过填装因子与哈希表大小的乘积取整获得哈希表的最佳填装量即：3×0.72=2。扩容后的哈希表大小为原表容量大小的2倍后的质数，在本例中再次扩容后哈希表大小为7。进行扩容之后，原哈希表的已经存储的元素必须按照新的哈希表的哈希函数（其实哈希函数本身没有发生变动，发生变动的是哈希表的长度）进行计算，重新寻址，扩容后的哈希表如下：

　　删除元素[20, “elem1”]，在删除元素时，同样需要根据哈希函数来进行寻址，如果有冲突，则进行二度哈希，但是值得注意的一点是，删除冲突标记元素（即元素的hash_coll值为负数）和非冲突标记元素是有差别的，在删除非冲突标记元素时，则直接将要删除的元素的键和值修改为null并将hash_coll置0即可，但是在删除冲突标记元素时，需将hash_coll的hash部分（即0-30位）置0以及将元素的值置为null，还需将该元素的键指向整个哈希表，之所以这样做是因为当索引为0的元素也出现冲突时，将无法判断该位置是一个空位还是非空位，那么再次进行插入时很可能将索引为0处的元素覆盖。删除[20， “elem1”]后的结构为：

　　插入元素[55, “elem4”]，此时Dictionary的容量已满，必须进行扩容操作，Dictionary的扩容和Hashtable的扩容策略一致，扩容后的Dictionary的容量大小为原Dictionary容量大小2倍后的质数即也为7，然后根据扩容后的Dictionary重新寻址，这意味着部分数据可能会引起冲突从而导致已有的链表会被打乱重新组织；Dictionary首先会将扩容前Dictionary中的entries中的元素全部复制到新的entries中，紧接着进行重新寻址，对于第一个元素[20, “elem1”]，新的哈希地址为：，于是buckets[6]的值被修改为0（即元素[20, “elem1”]在entries中的索引），同理对于33：，所以，buckets[5]=1，最后处理40，，此时发生冲突，在通过链表法处理冲突时，Dictionary首先将新元素的next指向冲突位置的元素索引buckets[5]，然后再将buckets[5]指向新的元素，此时一条只有两个元素的基于数组的链表形成，因此扩容之后的存储结构如下图：