搞 iOS 的，面试官问 Hash 干嘛？原因远比我下面要介绍的多

1496次阅读  |  发布于4年以前

作者：在路上重名了啊

一、了解hash的重要性

在 iOS开发中 随处可见 Hash 的身影，难道我们不好奇吗？

下图只是列出了部分知识点（Hash在iOS中的应用分析整理）

摘自知乎的一句话：

算法、数据结构、通信协议、文件系统、驱动等，虽然自己不写那些东西，但是了解其原理对于排错、优化自己的代码有很大帮助，就好比虽然你不设计制造汽车，但如果你了解发动机、变速器、安全气囊等几项原理，对于你驾车如何省油、延长使用寿命、保证自身安全有很大好处学而不思则罔、思而不学则殆，开发人员就是个随波而进的行业，无论何时何地，保持学习的深度和广度对于自身发展是很重要的，谁都不想60岁退休了还停留在增删查改的层面。

1.1、关联对象的实现原理：

详细的原理可以查阅其他资料，这里只介绍一下实现中使用的基本数据结构。关联对象采用的是HashMap嵌套HashMap的结构存储数据的，简单来说就是根据对象从第一个HashMap中取出存储对象所有关联对象的第二个HashMap，然后根据属性名从第二个HashMap中取出属性对应的值和策略。

设计关联对象的初衷是，通过传入 对象 + 属性名字 ，就可以找到属性值。方案设计实现好后，查找一个对象的关联对象的基本步骤：

参考资料：

iOS底层原理总结 - 关联对象实现原理

关联对象 AssociatedObject 完全解析

1.2、weak的实现原理：

同样详细的原理可以查阅其他资料，这里只介绍一下实现中使用的基本数据结构。weak采用的是一个全局的HashMap嵌套数组的结构存储数据的，销毁对象（weak指针指向的对象）的时候，根据对象从HashMap中找到存放所有指向该对象的weak指针的数组，然后将数组中的所有元素（weak指针）都置为nil。

weak的最大特点就是在对象销毁的时候，自动置nil，减少访问野指针的风险，这也是设计weak的初衷。方案设计实现好后，weak指针置nil的基本步骤：

苹果对于weak的实现其实类似于通知的实现，指明谁（weak指针）要监听谁（赋值对象）什么事件（dealloc操作）执行什么操作（置nil）。

参考资料：

iOS 底层解析weak的实现原理（包含weak对象的初始化，引用，释放的分析） weak实现原理

1.3、KVO实现使用的基本数据结构

比较复杂，一个对象可以被n个对象观察，一对象的n个属性又可以分别被n个对象观察。

详细参考： GNUstep KVC/KVO探索（二）：KVO的内部实现

1.4、iOS App签名的原理

一句话：一致性哈希算法 + 非对称加解密算法

详细参考： iOS App 签名的原理

1.5、对象的引用计数存储的位置

具体参考 ：苹果iOS系统源码思考：对象的引用计数存储在哪里？--从runtime源码得到的启示

if 对象支持TaggedPointer {
    return 直接将对象的指针值作为引用计数返回
} 
else if 设备是64位环境 && Objective-C2.0 {
    return 对象isa指针的一部分空间(bits_extra_rc)
}
else {
    return hash表
}

1.6、Runloop与线程的存储关系

线程和 RunLoop 之间是一一（子线程可以没有）对应的，其关系是保存在一个全局的 Dictionary 里。线程刚创建时并没有 RunLoop，如果你不主动获取，那它一直都不会有。RunLoop 的创建是发生在第一次获取时，RunLoop 的销毁是发生在线程结束时。你只能在一个线程的内部获取其 RunLoop（主线程除外）。

1.7、NSDictionary的原理：

解释完Hash表后，下面简单解释下

二、哈希表

桶排序

2.1、哈希表定义

哈希表（hash table，也叫散列表），是根据键（key）直接访问访问在内存储存位置的数据结构。哈希表本质是一个数组，数组中的每一个元素成为一个箱子，箱子中存放的是键值对。根据下标index从数组中取value。关键是如何获取index，这就需要一个固定的函数（哈希函数），将key转换成index。不论哈希函数设计的如何完美，都可能出现不同的key经过hash处理后得到相同的hash值，这时候就需要处理哈希冲突。

2.2、哈希表优缺点

优点 ：哈希表可以提供快速的操作。

缺点 ：哈希表通常是基于数组的，数组创建后难于扩展。也没有一种简便的方法可以以任何一种顺序〔例如从小到大）遍历表中的数据项。

综上，如果不需要有序遍历数据，井且可以提前预测数据量的大小。那么哈希表在速度和易用性方面是无与伦比的。

2.3、哈希查找步骤

2.4、哈希表存储过程：

hash("张三") = 23;
hash("李四") = 30;
hash("王五") = 23;

2.5、常用哈希函数：

哈希查找第一步就是使用哈希函数将键映射成索引。这种映射函数就是哈希函数。如果我们有一个保存0-M数组，那么我们就需要一个能够将任意键转换为该数组范围内的索引（0~M-1）的哈希函数。哈希函数需要易于计算并且能够均匀分布所有键。比如举个简单的例子，使用手机号码后三位就比前三位作为key更好，因为前三位手机号码的重复率很高。再比如使用身份证号码出生年月位数要比使用前几位数要更好。

在实际中，我们的键并不都是数字，有可能是字符串，还有可能是几个值的组合等，所以我们需要实现自己的哈希函数。

要想设计一个优秀的哈希算法并不容易，根据经验，总结了需要满足的几点要求：

2.6、负载因子 = 总键值对数/数组的个数

负载因子是哈希表的一个重要属性，用来衡量哈希表的空/满程度，一定程度也可以提现查询的效率。负载因子越大，意味着哈希表越满，越容易导致冲突，性能也就越低。所以当负载因子大于某个常数（一般是0.75）时，哈希表将自动扩容。哈希表扩容时，一般会创建两倍于原来的数组长度。因此即使key的哈希值没有变化，对数组个数取余的结果会随着数组个数的扩容发生变化，因此键值对的位置都有可能发生变化，这个过程也成为重哈希（rehash）。

哈希表扩容 在数组比较多的时候，需要重新哈希并移动数据，性能影响较大。

哈希表扩容 虽然能够使负载因子降低，但并不总是能有效提高哈希表的查询性能。比如哈希函数设计的不合理，导致所有的key计算出的哈希值都相同，那么即使扩容他们的位置还是在同一条链表上，变成了线性表，性能极低，查询的时候时间复杂度就变成了O(n)。

2.7、哈希冲突的解决方法：

方法一：拉链法

简单来说就是 数组 + 链表 。将键通过hash函数映射为大小为M的数组的下标索引，数组的每一个元素指向一个链表，链表中的每一个结点存储着hash出来的索引值为结点下标的键值对。

Java 8解决哈希冲突采用的就是拉链法。在处理哈希函数设计不合理导致链表很长时（链表长度超过8切换为红黑树，小于6重新退化为链表）。将链表切换为红黑树能够保证插入和查找的效率，缺点是当哈希表比较大时，哈希表扩容会导致瞬时效率降低。

Redis解决哈希冲突采用的也是拉链法。通过增量式扩容解决了Java 8中的瞬时扩容导致的瞬时效率降低的缺点，同时拉链法的实现方式（新插入的键值对放在链表头部）带来了两个好处：

方法二：开放定址线性探测发

使用两个大小为N的数组（一个存放keys，另一个存放values）。使用数组中的空位解决碰撞，当碰撞发生时（即一个键的hash值对应数组的下标被两外一个键占用）直接将下标索引加一（index += 1），这样会出现三种结果：

拉链法的优点

与开放定址线性探测发相比，拉链法有如下几个优点：

拉链法的缺点

指针需要额外的空间，故当结点规模较小时，开放定址线性探测发较为节省空间，而若将节省的指针空间用来扩大散列表的规模，可使装填因子变小，这又减少了开放定址线性探测发中的冲突，从而提高平均查找速度。

开放定址线性探测法缺点

2.8、Hash表的平均查找长度

Hash表的平均查找长度包括查找成功时的平均查找长度和查找失败时的平均查找长度。

查找成功时的平均查找长度=表中每个元素查找成功时的比较次数之和/表中元素个数；

查找不成功时的平均查找长度相当于在表中查找元素不成功时的平均比较次数，可以理解为向表中插入某个元素，该元素在每个位置都有可能，然后计算出在每个位置能够插入时需要比较的次数，再除以表长即为查找不成功时的平均查找长度。

例子：

给定一组数据{32，14，23，01，42，20，45，27，55，24，10，53}，假设散列表的长度为13（最接近n的质数），散列函数为H(k) = k%13。分别画出用 线性探测法 和 拉链法 解决冲突时构造的哈希表，并求出在等概率下情况，这两种方法查找成功和查找不成功的平均查找长度。

一、拉链法

查找成功时的平均查找长度：

ASL = (1*6+2*4+3*1+4*1)/12 = 7/4

查找不成功时的平均查找长度：

ASL = (4+2+2+1+2+1)/13

二、线性探测法

查找成功时查找次数=插入元素时的比较次数，查找成功的平均查找长度：

ASL = (1+2+1+4+3+1+1+1+3+9+1+1+3)/12=2.5

查找不成功时的查找次数=第n个位置不成功时的比较次数为，第n个位置到第1个没有数据位置的距离：如第0个位置取值为1，第1个位置取值为2.查找不成功时的平均查找长度：

ASL = （1+2+3+4+5+6+7+8+9+10+11+12）/ 13 = 91/13

2.9、NSDictionary解释版本一：是使用NSMapTable实现的，采用拉链法解决哈希冲突

typedef struct {
   NSMapTable        *table;
   NSInteger          i;
   struct _NSMapNode *j;
} NSMapEnumerator;

上述结构体描述了遍历一个NSMapTable时的一个指针对象，其中包含table对象自身的指针，计数值，和节点指针。

typedef struct {
   NSUInteger (*hash)(NSMapTable *table,const void *);
   BOOL (*isEqual)(NSMapTable *table,const void *,const void *);
   void (*retain)(NSMapTable *table,const void *);
   void (*release)(NSMapTable *table,void *);
   NSString  *(*describe)(NSMapTable *table,const void *);
   const void *notAKeyMarker;
} NSMapTableKeyCallBacks;

上述结构体中存放的是几个函数指针，用于计算key的hash值，判断key是否相等，retain，release操作。

typedef struct {
   void       (*retain)(NSMapTable *table,const void *);
   void       (*release)(NSMapTable *table,void *);
   NSString  *(*describe)(NSMapTable *table, const void *);
} NSMapTableValueCallBacks;

上述存放的三个函数指针，定义在对NSMapTable插入一对key－value时，对value对象的操作。

@interface NSMapTable : NSObject {
   NSMapTableKeyCallBacks   *keyCallBacks;
   NSMapTableValueCallBacks *valueCallBacks;
   NSUInteger             count;
   NSUInteger             nBuckets;
   struct _NSMapNode  **buckets;
}

从上面的结构真的能看出NSMapTable是一个 哈希表 + 链表 的数据结构吗？在NSMapTbale中插入或者删除一个对象的寻找时间 = O(1) + O(m) ，m为最坏时可能为n。

O(1) ：对key进行hash得到bucket的位置

O(m) ：不同的key得到相同的hash值的value存放到链表中，遍历链表的时间

上面的结论和对应的解释似乎很合理？看看下面的分析再说也不迟！

2.10、NSDictionary解释版本二：是对_CFDictionary的封装，解决哈希冲突使用的是开放定址线性探测法

struct __CFDictionary {
    CFRuntimeBase _base;
    CFIndex _count;
    CFIndex _capacity;
    CFIndex _bucketsNum;
    uintptr_t _marker;
    void *_context;
    CFIndex _deletes;
    CFOptionFlags _xflags;
    const void **_keys;    
    const void **_values;
};

从上面的数据结构可以看出NSDictionary内部使用了两个指针数组分别保存keys和values。采用的是连续方式存储键值对。拉链法会将key和value包装成一个结果存储（链表结点），而Dictionary的结构拥有keys和values两个数组（开放寻址线性探测法解决哈希冲突的用的就是两个数组），说明两个数据是被分开存储的，不像是拉链法。

NSDictionary使用开放定址线性探测法解决哈希冲突的原理：

可以看到，NSDictionary设置的key和value，key值会根据特定的hash函数算出建立的空桶数组，keys和values同样多，然后存储数据的时候，根据hash函数算出来的值，找到对应的index下标，如果下标已有数据，开放定址法后移动插入，如果空桶数组到达数据阀值，这个时候就会把空桶数组扩容，然后重新哈希插入。

这样把一些不连续的key-value值插入到了能建立起关系的hash表中，当我们查找的时候，key根据哈希>值算出来，然后根据索引，直接index访问hash表keys和hash表values，这样查询速度就可以和连续线性存储的数据一样接近O(1)了，只是占用空间有点大，性能就很强悍。

如果删除的时候，也会根据_maker标记逻辑上的删除，除非NSDictionary（NSDictionary本体的hash值就是count）内存被移除。

NSDictionary之所以采用这种设计， 其一出于查询性能的考虑；其二NSDictionary在使用过程中总是会很快的被释放，不会长期占用内存;

2.11、Apple方案选择：

解决哈希冲突的拉链法和开放定址线性探测法，Apple都是用了。具体使用哪一种是根据存储数据的生命周期和特性决定的。

2.12、NSDictionary的存储过程：

具体参考我写的另一篇博客：iOS笔记：进一步认识 ==、isEqual、hash

参考博客

浅谈算法和数据结构: 十一 哈希表

NSDictionary和NSMutableArray底层原理（哈希表和环形缓冲区）

Swift中字典的实现原理

深入理解哈希表

解读Objective-C的NSDictionary

iOS重做轮子，写一个NSDictionary（一）

iOS重做轮子，写一个NSDictionary（一）

哈希表——线性探测法、链地址法、查找成功、查找不成功的平均长度

哈希表、哈希算法、一致性哈希表

细说@synchronized和dispatch_once

Copyright© 2013-2020

All Rights Reserved 京ICP备2023019179号-8