一、NSDictionary使用原理
1.NSDictionary（字典）是使用hash表来实现key和value之间的映射和存储的，hash函数设计的好坏影响着数据的查找访问效率。
-(void)setObject:(id)anObject forKey:(id)aKey;
2.Objective-C中的字典NSDictionary底层其实是一个哈希表，实际上绝大多数语言中字典都通过哈希表实现.
二、哈希的原理
1.根据key计算出它的哈希值h。
2.假设箱子的个数为n，那么这个键值对应该放在第(h % n)个箱子中。
3.如果该箱子中已经有了键值对，就使用 开放寻址法 或者 拉链法 解决冲突。
在使用拉链法解决哈希冲突时，每个箱子其实是一个链表，属于同一个箱子的所有键值对都会排列在链表中。
哈希表还有一个重要的属性:负载因子(load factor)，它用来衡量哈希表的空/满程度，一定程度上也可以体现查询的效率，计算公式为:
负载因子=总键值对数/箱子个数
负载因子越大，意味着哈希表越满，越容易导致冲突，性能也就越低。因此，一般来说，当负载因子大于某个常数(可能是1，或者0.75等)时，哈希表将自动扩容。
哈希表在自动扩容时，一般会创建两倍于原来个数的箱子，因此即使key的哈希值不变，对箱子个数取余的结果也会发生改变，因此所有键值对的存放位置都有可能发生改变，这个过程也称为重哈希(rehash)。
哈希表的扩容并不总是能够有效解决负载因子过大的问题。假设所有key的哈希值都一样，那么即使扩容以后他们的位置也不会变化。虽然负载因子会降低，但实际存储在每个箱子中的链表长度并不发生改变，因此也就不能提高哈希表的查询性能。
四、总结，细心的读者可能会发现哈希表的两个问题:
1.如果哈希表中本来箱子就比较多，扩容时需要重新哈希并移动数据，性能影响较大。
2.如果哈希函数设计不合理，哈希表在极端情况下会变成线性表，性能极低。
关于hash表
想想一下，我们有一个数组，数组长度是100个，现在的需求是：给出这个数组是否包含一个对象obj？
如果这是个无序的数组，那么我们只能用遍历的方法来查找是否包含这个对象obj了。这是我们的时间复杂度就是O(n)。
这种查找效率是很低的，所以hash表应运而生。
hash表其实也是一个数组，区别数组的地方是它会建立 存储的值 到 存储的下标 索引的一个映射，也就是散列函数。
我们来举一个通俗易懂的例子：
现在我们有个hash表，表长度count = 16，现在我们依次把3，12，24，30依次存入hash表中。
首先我们来约定一个简单的映射关系：存储的索引下表(index) = 存储值(value) % hash表长度(count)；
[注：实际的映射并不是简单的存储值，而是经过计算得到的hash值]
算下来hash表的存储分布是这样的：hash[3] = 3、hash[12] = 12、hash[8] = 24、hash[14] = 30
还是一样的需求，当我们给出24的时候，求出hash表中是否存有24？
此时，按照原先约定的映射关系：index = 24 % 16 = 8，然后我们在hash[8]查询等于24。这样，通过数组需要O(n)的时间复杂度，通过hash表只需要O(1)；
散列碰撞
上面提到的hash表在存入3，12，24，30后，如果要面临存入19呢？
此时index = 19 % 16 = 3，而之前hash[3] 已经存入了3这个值了！这种情况就是发送了散列碰撞。
此时，我们可以改进一下我们的hash表，让它存储的是一个链表。这样发送散列碰撞的元素就可以以链表的形式共处在hash表的某一个下标位置了。