哈希表的设计主要是为了查找，为了对内存中的数据进行快速查找，它的查找时间复杂度是O（1）。设计一个哈希表的关键有三个：怎么控制哈希表的长度，怎么设计哈希函数，怎么处理哈希冲突
今天这篇文章先来讨论一下如何设计我们的哈希表的大小
哈希表的长度一般是定长的，在存储数据之前我们应该知道我们存储的数据规模是多大，应该尽可能地避免频繁地让哈希表扩容。但是如果设计的太大，那么就会浪费空间，因为我们跟不用不到那么大的空间来存储我们当前的数据规模；如果设计的太小，那么就会很容易发生哈希冲突，体现不出哈希表的效率。所以，我们设计的哈希表的大小，必须要做到尽可能地减小哈希冲突，并且也要尽可能地不浪费空间，选择合适的哈希表的大小是提升哈希表性能的关键。
当我们选择哈希函数的时候，经常会选择除留余数法，即用存储数据的key值除以哈希表的总长度，得到的余数就是它的哈希值。常识告诉我们，当一个数除以一个素数的时候，会产生最分散的余数。由于我们通常使用表的大小对哈希函数的结果进行模运算，如果表的大小是一个素数，那么这样我们就会尽可能地产生分散的哈希值。
另外，哈希表中还有一个概念就是表的装填因子（负载因子），它的值一般被定义为：
装填因子 a = 总键值对数（下标占用数） / 哈希表总长度
至于为什么要设计这样一个概念，我们可以像，如果一个哈希表中的数据装的越多，是不是越容易发生哈希冲突。如果当哈希表中满到只剩下一个下标可以插入的时候，这个时候我们还要往这个哈希表中插入数据，于是我们可能会达到一个O（n）级别的插入效率，我们甚至要遍历整个哈希表才可能找到那个能存储的位置。
通常，我们关注的是使哈希表平均查找长度最小，把平均查找长度保证在O（1）级别。装填因子a的取值越小，产生冲突的机会就越小，但是也不能取太小，这样我们会造成较大的空间浪费。即如果我们a取0.1，而我们哈希表的长度为100，那我们只装了10个键值对就存不下了，就要对哈希表进行扩容，而剩下90个键值对空间其实是浪费了的。通常，只要a取的合适（一般取0.7-0.8之间），哈希表的平均查找长度就会是常数也就是O（1）级别的。
当然，根据数据量的不同，会有不同的哈希表的大小。当数据量小的时候，最好就是能够实现哈希表扩容的机制，即达到了哈希表当前长度的装填因子，我们就需要扩大哈希表大小，一般都是乘2。
下面，对上面这些观点进行一个总结，来设计一个效率尽可能高的哈希表大小
- 确保哈希表长度是一个素数，这样会产生最分散的余数，尽可能减少哈希冲突
- 设计好哈希表装填因子，一般控制在0.7-0.8
- 确认我们的数据规模，如果确认了数据规模，可以将数据规模除以装填因子，根据这个结果来寻找一个可行的哈希表大小
- 当数据规模可能会动态变化，不确定的时候，这个时候我们也需要能够根据数据规模的变化来动态给我们的哈希表扩容，所以一开始需要自己确定一个哈希表的大小作为基数，然后在此基础上达到装填因子规模时对哈希表进行扩容。
一般来说，可能地哈希表长度取值如下：
const int_PrimeSize= 28;
static const unsigned long_PrimeList[_PrimeSize] =
{
//ul代表这个数是unsigned long
53ul, 97ul, 193ul, 389ul, 769ul,
1543ul, 3079ul, 6151ul, 12289ul, 24593ul,
49157ul, 98317ul, 196613ul, 393241ul, 786433ul,
1572869ul, 3145739ul, 6291469ul, 12582917ul, 25165843ul,
50331653ul, 100663319ul, 201326611ul, 402653189ul, 805306457ul,
1610612741ul, 3221225473ul, 4294967291ul
};