分离链接散列法的吸引力

其实，细说起来，对于缓存的处理，一个类是很难做好的，特别是稍微复杂点的系统，不太可能说指望一个xxhelper就搞定了。就拿博客园来说，Blog可能需要BlogCacheDataProvider来封装缓存请求，Article需要ArticleCacheDataProvider，而且他们获取都是继承自 ICacheDataProvider接口，这是针对你的假设来做的代码设计。其主要思想就是“依赖倒置原则”，缓存的调用不依赖于具体的缓存实现，而以来与上层抽象接口。我也提到了是开多个进程来处理并发，一般开20个就足够了。因为php or ruby等页面生命周期非常短暂，20个足够处理大量请求。 因为生命周期内不会同时出现非常多的请求，这和连接池的道理相同。
其实我只是拿这个来开个玩笑而已，和本题没太大关系。
包括IIS的Web Garden，我们现实中又有几个人在用？用的可能性非常小吧？ 而典型的LAMP架构里又有谁不用apache的进程模式或混合模式？ 所以，我说的也是普遍现象，大家都大致了解就行了。俗话说 “差不多就行了” 我查了下资料，Dict的hash算法确实和hashtable是不一样的。
更节约空间的方法：分离链接散列法(separate chaining hashing)。

采用分离链接法的 Dictionary<TKey, TValue> 会在内部维护一个链表数组。对于这个链表数组 L0,L1,...，LM-1,散列函数将告诉我们应当把元素 X 插入到链表的什么位置。然后在 find 操作时告诉我们哪一个表中包含了 X。这种方法的思想在于：尽管搜索一个链表是线性操作，但如果表足够小，搜索非常快(事实也的确如此，同时这也是查找，插入，删除等操作并非总是 O(1) 的原因)。特别是，它不受装填因子的限制。


分离链接散列法的吸引力不仅在于适度增加装填因子时，性能不受影响，而且可以在扩容时避免再次散列(这相当耗时)。