iOS 字典的实现原理
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了iOS 字典的实现原理相关的知识，希望对你有一定的参考价值。
参考技术A 一、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表的某一个下标位置了。
lucene字典实现原理
1 lucene字典
使用lucene进行查询不可避免都会使用到其提供的字典功能，即根据给定的term找到该term所对应的倒排文档id列表等信息。实际上lucene索引文件后缀名为tim和tip的文件实现的就是lucene的字典功能。
怎么实现一个字典呢？我们马上想到排序数组，即term字典是一个已经按字母顺序排序好的数组，数组每一项存放着term和对应的倒排文档id列表。每次载入索引的时候只要将term数组载入内存，通过二分查找即可。这种方法查询时间复杂度为Log(N)，N指的是term数目，占用的空间大小是O(N*str(term))。排序数组的缺点是消耗内存，即需要完整存储每一个term，当term数目多达上千万时，占用的内存将不可接受。
2 常用字典数据结构
很多数据结构均能完成字典功能，总结如下。
| 数据结构 | 优缺点 |
| 排序列表Array/List | 使用二分法查找，不平衡 |
| HashMap/TreeMap | 性能高，内存消耗大，几乎是原始数据的三倍 |
| Skip List | 跳跃表，可快速查找词语，在lucene、redis、Hbase等均有实现。相对于TreeMap等结构，特别适合高并发场景（Skip List介绍） |
| Trie | 适合英文词典，如果系统中存在大量字符串且这些字符串基本没有公共前缀，则相应的trie树将非常消耗内存（数据结构之trie树） |
| Double Array Trie | 适合做中文词典，内存占用小，很多分词工具均采用此种算法（深入双数组Trie） |
| Ternary Search Tree | 三叉树，每一个node有3个节点，兼具省空间和查询快的优点（Ternary Search Tree） |
| Finite State Transducers (FST) | 一种有限状态转移机，Lucene 4有开源实现，并大量使用 |
3 FST原理简析
lucene从4开始大量使用的数据结构是FST（Finite State Transducer）。FST有两个优点：1）空间占用小。通过对词典中单词前缀和后缀的重复利用，压缩了存储空间；2）查询速度快。O(len(str))的查询时间复杂度。
下面简单描述下FST的构造过程（工具演示：http://examples.mikemccandless.com/fst.py?terms=&cmd=Build+it%21）。我们对“cat”、 “deep”、 “do”、 “dog” 、“dogs”这5个单词进行插入构建FST（注：必须已排序）。
1）插入“cat”
插入cat，每个字母形成一条边，其中t边指向终点。
2）插入“deep”
与前一个单词“cat”进行最大前缀匹配，发现没有匹配则直接插入，P边指向终点。
3）插入“do”
与前一个单词“deep”进行最大前缀匹配，发现是d，则在d边后增加新边o，o边指向终点。
4）插入“dog”
与前一个单词“do”进行最大前缀匹配，发现是do，则在o边后增加新边g，g边指向终点。
5）插入“dogs”
与前一个单词“dog”进行最大前缀匹配，发现是dog，则在g后增加新边s，s边指向终点。
最终我们得到了如上一个有向无环图。利用该结构可以很方便的进行查询，如给定一个term “dog”，我们可以通过上述结构很方便的查询存不存在，甚至我们在构建过程中可以将单词与某一数字、单词进行关联，从而实现key-value的映射。
4 FST使用与性能评测
我们可以将FST当做Key-Value数据结构来进行使用，特别在对内存开销要求少的应用场景。Lucene已经为我们提供了开源的FST工具，下面的代码是使用说明。
1 public static void main(String[] args) {
2 try {
3 String inputValues[] = {"cat", "deep", "do", "dog", "dogs"};
4 long outputValues[] = {5, 7, 17, 18, 21};
5 PositiveIntOutputs outputs = PositiveIntOutputs.getSingleton(true);
6 Builder<Long> builder = new Builder<Long>(FST.INPUT_TYPE.BYTE1, outputs);
7 BytesRef scratchBytes = new BytesRef();
8 IntsRef scratchInts = new IntsRef();
9 for (int i = 0; i < inputValues.length; i++) {
10 scratchBytes.copyChars(inputValues[i]);
11 builder.add(Util.toIntsRef(scratchBytes, scratchInts), outputValues[i]);
12 }
13 FST<Long> fst = builder.finish();
14 Long value = Util.get(fst, new BytesRef("dog"));
15 System.out.println(value); // 18
16 } catch (Exception e) {
17 ;
18 }
19 }
FST压缩率一般在3倍~20倍之间，相对于TreeMap/HashMap的膨胀3倍，内存节省就有9倍到60倍！（摘自：把自动机用作 Key-Value 存储），那FST在性能方面真的能满足要求吗？
下面是我在苹果笔记本（i7处理器）进行的简单测试，性能虽不如TreeMap和HashMap，但也算良好，能够满足大部分应用的需求。
参考文献
http://sbp810050504.blog.51cto.com/2799422/1361551
http://blog.sina.com.cn/s/blog_4bec92980101hvdd.html
http://blog.mikemccandless.com/2013/06/build-your-own-finite-state-transducer.html