在 iOS开发中 随处可见 Hash 的身影,难道咱们很差奇吗?html
下图只是列出了部分知识点(Hash
在iOS中的应用分析整理) ios
摘自知乎的一句话:git
算法、数据结构、通讯协议、文件系统、驱动等,虽然本身不写那些东西,可是
了解其原理
对于排错
、优化本身的代码
有很大帮助,就比如虽然你不设计制造汽车,但若是你了解发动机、变速器、安全气囊等几项原理,对于你驾车如何省油
、延长使用寿命
、保证自身安全
有很大好处学而不思则罔、思而不学则殆,开发人员就是个随波而进的行业,不管什么时候何地,保持学习的深度和广度对于自身发展是很重要的,谁都不想60岁退休了还停留在增删查改的层面。github
详细的原理能够查阅其余资料,这里只介绍一下实现中使用的基本数据结构。关联对象采用的是
HashMap
嵌套HashMap
的结构存储数据的,简单来讲就是根据对象从第一个HashMap
中取出存储对象全部关联对象的第二个HashMap
,而后根据属性名从第二个HashMap
中取出属性对应的值和策略。算法
设计关联对象的初衷是,经过传入 对象 + 属性名字 ,就能够找到属性值。方案设计实现好后,查找一个对象的关联对象的基本步骤:swift
- - 一、 已知条件一:对象 ,所以引出第一个
HashMap
(AssociationsHashMap
),用一个能惟一表明对象的值做为key
,用存储对象的全部关联对象的结构(名字:值+策略)做为value
- - 二、 已知条件二:属性名字 ,所以引出第二个
HashMap
(ObjectAssociationMap
),用属性名字做为key
,用属性名字对应的结构体(值+策略)做为value
一样详细的原理能够查阅其余资料,这里只介绍一下实现中使用的基本数据结构。
weak
采用的是一个全局的HashMap
嵌套数组的结构存储数据的,销毁对象(weak指针
指向的对象)的时候,根据对象从HashMap
中找到存放全部指向该对象的weak指针
的数组,而后将数组中的全部元素(weak指针
)都置为nil。bash
weak
的最大特色就是在对象销毁的时候,自动置nil
,减小访问野指针的风险
,这也是设计weak
的初衷。方案设计实现好后,weak
指针置nil
的基本步骤:数据结构
- 一、对象
dealloc
的时候,从全局的HashMap
中,根据一个惟一表明对象的值做为key
,找到存储全部指向该对象的weak
指针的数组- 二、将数组中的全部元素都置为
nil
苹果对于weak的实现其实相似于通知的实现,指明谁(
weak指针
)要监听谁(赋值对象
)什么事件(dealloc操做
)执行什么操做(置nil
)。
iOS 底层解析weak的实现原理(包含weak对象的初始化,引用,释放的分析) weak实现原理
比较复杂,一个对象能够被n个对象观察,一对象的n个属性又能够分别被n个对象观察。
详细参考: GNUstep KVC/KVO探索(二):KVO的内部实现
一句话:
一致性哈希算法
+非对称加解密算法
详细参考: iOS App 签名的原理
具体参考 :苹果iOS系统源码思考:对象的引用计数存储在哪里?--从runtime源码获得的启示
if 对象支持TaggedPointer {
return 直接将对象的指针值做为引用计数返回
}
else if 设备是64位环境 && Objective-C2.0 {
return 对象isa指针的一部分空间(bits_extra_rc)
}
else {
return hash表
}
复制代码
线程和
RunLoop
之间是一一(子线程能够没有)对应的,其关系是保存在一个全局的Dictionary
里。线程刚建立时并无RunLoop
,若是你不主动获取,那它一直都不会有。RunLoop
的建立是发生在第一次获取时,RunLoop
的销毁是发生在线程结束时。你只能在一个线程的内部获取其RunLoop
(主线程除外)。
解释完Hash表后,下面简单解释下
哈希表(
hash table
,也叫散列表),是根据键(key
)直接访问访问在内存储存位置的数据结构。 哈希表本质是一个数组,数组中的每个元素成为一个箱子,箱子中存放的是键值对。根据下标index
从数组中取value
。关键是如何获取index
,这就须要一个固定的函数(哈希函数),将key
转换成index
。不论哈希函数设计的如何完美,均可能出现不一样的key
通过hash
处理后获得相同的hash
值,这时候就须要处理哈希冲突。
优势 :哈希表能够提供快速的操做。
缺点 :哈希表一般是基于数组的,数组建立后难于扩展。 也没有一种简便的方法能够以任何一种顺序〔例如从小到大)遍历表中的数据项。
综上,若是不须要有序遍历数据,井且能够提早预测数据量的大小。那么哈希表在速度和易用性方面是无与伦比的。
- 一、使用哈希函数将被查找的键映射(转换)为数组的索引,理想状况下(hash函数设计合理)不一样的键映射的数组下标也不一样,全部的查找时间复杂度为O(1)。可是实际状况下不是这样的,因此哈希查找的第二步就是处理哈希冲突。
- 二、处理哈希碰撞冲突。处理方法有不少,好比拉链法、线性探测法。
- 一、使用hash函数根据key获得哈希值h
- 二、若是箱子的个数为n,那么值应该存放在底(h%n)个箱子中。h%n的值范围为[0, n-1]。
- 三、若是该箱子非空(已经存放了一个值)即不一样的key获得了相同的h产生了哈希冲突,此时须要使用拉链法或者开放定址线性探测法解决冲突。
hash("张三") = 23;
hash("李四") = 30;
hash("王五") = 23;
复制代码
哈希查找第一步就是使用哈希函数将键映射成索引。这种映射函数就是哈希函数。若是咱们有一个保存0-M数组,那么咱们就须要一个可以将任意键转换为该数组范围内的索引(0~M-1)的哈希函数。哈希函数须要易于计算而且可以均匀分布全部键。好比举个简单的例子,使用手机号码后三位就比前三位做为key更好,由于前三位手机号码的重复率很高。再好比使用身份证号码出生年月位数要比使用前几位数要更好。
在实际中,咱们的键并不都是数字,有多是字符串,还有多是几个值的组合等,因此咱们须要实现本身的哈希函数。
- - 一、直接寻址法
- - 二、数字分析法
- - 三、平方取中法
- - 四、折叠法
- - 五、随机数法
- - 六、除留余数法
要想设计一个优秀的哈希算法并不容易,根据经验,总结了须要知足的几点要求:
- 从哈希值不能反向推导出原始数据(因此哈希算法也叫单向哈希算法);
- 对输入数据很是敏感,哪怕原始数据只修改了一个 Bit,最后获得的哈希值也大不相同;
- 散列冲突的几率要很小,对于不一样的原始数据,哈希值相同的几率很是小;
- 哈希算法的执行效率要尽可能高效,针对较长的文本,也能快速地计算出哈希值。
负载因子是哈希表的一个重要属性,用来衡量哈希表的空/满程度,必定程度也能够提现查询的效率。负载因子越大,意味着哈希表越满,越容易致使冲突,性能也就越低。因此当负载因子大于某个常数(通常是0.75)时,哈希表将自动扩容。哈希表扩容时,通常会建立两倍于原来的数组长度。所以即便key的哈希值没有变化,对数组个数取余的结果会随着数组个数的扩容发生变化,所以键值对的位置都有可能发生变化,这个过程也成为重哈希(
rehash
)。
哈希表扩容 在数组比较多的时候,须要从新哈希并移动数据,性能影响较大。
哈希表扩容 虽然可以使负载因子下降,但并不老是能有效提升哈希表的查询性能。好比哈希函数设计的不合理,致使全部的
key
计算出的哈希值都相同,那么即便扩容他们的位置仍是在同一条链表上,变成了线性表,性能极低,查询的时候时间复杂度就变成了O(n)
。
简单来讲就是 数组 + 链表 。将键经过hash函数映射为大小为M的数组的下标索引,数组的每个元素指向一个链表,链表中的每个结点存储着hash出来的索引值为结点下标的键值对。
Java 8
解决哈希冲突采用的就是拉链法。在处理哈希函数设计不合理致使链表很长时(链表长度超过8
切换为红黑树,小于6
从新退化为链表)。将链表切换为红黑树可以保证插入和查找的效率,缺点是当哈希表比较大时,哈希表扩容会致使瞬时效率下降。
Redis
解决哈希冲突采用的也是拉链法。经过增量式扩容解决了Java 8
中的瞬时扩容致使的瞬时效率下降的缺点,同时拉链法的实现方式(新插入的键值对放在链表头部)带来了两个好处:
- - 1、头插法能够节省插入耗时。若是插到尾部,则须要时间复杂度为
O(n)
的操做找到链表尾部,或者须要额外的内存地址来保存尾部链表的位置。- - 2、头插法能够节省查找耗时。对于一个数据系统来讲,最新插入的数据每每可能频繁的被查询。
使用两个大小为N的数组(一个存放keys,另外一个存放values)。使用数组中的空位解决碰撞,当碰撞发生时(即一个键的hash值对应数组的下标被两外一个键占用)直接将下标索引加一(
index += 1
),这样会出现三种结果:
- - 一、未命中(数组下标中的值为空,没有占用)。
keys[index] = key
,values[index] = value
。- - 二、命中(数组下标中的值不为空,占用)。
keys[index] == key
,values[index] == value
。- - 三、命中(数组下标中的值不为空,占用)。
keys[index] != key
,继续index += 1
,直到遇到结果1或2中止。
与开放定址线性探测发相比,拉链法有以下几个优势:
- - ①、拉链法处理冲突简单,且无堆积现象,即非同义词决不会发生冲突,所以平均查找长度较短;
- - ②、因为拉链法中各链表上的结点空间是动态申请的,故它更适合于造表前没法肯定表长的状况;
- - ③、开放定址线性探测发为减小冲突,要求装填因子α较小,故当结点规模较大时会浪费不少空间。而拉链法中可取α≥1,且结点较大时,拉链法中增长的指针域可忽略不计,所以节省空间;
- ④、在用拉链法构造的散列表中,删除结点的操做易于实现。只要简单地删去链表上相应的结点便可。而对开放定址线性探测发构造的散列表,删除结点不能简单地将被删结 点的空间置为空,不然将截断在它以后填人散列表的同义词结点的查找路径。这是由于各类开放定址线性探测发中,空地址单元(即开放地址)都是查找失败的条件。所以在用开放定址线性探测发处理冲突的散列表上执行删除操做,只能在被删结点上作删除标记,而不能真正删除结点。
指针须要额外的空间,故当结点规模较小时,开放定址线性探测发较为节省空间,而若将节省的指针空间用来扩大散列表的规模,可以使装填因子变小,这又减小了开放定址线性探测发中的冲突,从而提升平均查找速度。
- - 一、容易产生堆积问题;
- - 二、不适于大规模的数据存储;
- - 三、散列函数的设计对冲突会有很大的影响;
- - 四、插入时可能会出现屡次冲突的现象,删除的元素是多个冲突元素中的一个,须要对后面的元素做处理,实现较复杂;
- - 五、结点规模很大时会浪费不少空间;
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
复制代码
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
存放到链表中,遍历链表的时间
上面的结论和对应的解释彷佛很合理?看看下面的分析再说也不迟!
开放定址线性探测法
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
设置的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
在使用过程当中老是会很快的被释放,不会长期占用内存;
解决哈希冲突的拉链法和开放定址线性探测法,Apple都是用了。具体使用哪种是根据存储数据的生命周期和特性决定的。
@synchronized
使用的是拉链法。拉链法多用于存储的数据是通用类型,可以被反复利用,就像@synchronized存储的是锁是一种无关业务的实现结构,程序运行时多个对象使用同一个锁的几率至关高,有效的节省了内存。weak对象
associatedObject
采用的是开放定址线性探测法。开放定址线性探测法用于存储的数据是临时的,用完尽快释放,就像associatedObject,weak。具体参考我写的另外一篇博客:iOS笔记:进一步认识 ==、isEqual、hash
- (void)setObject:(id)anObject forKey:(id <NSCopying>)aKey;
能够看出key必须遵循NSCopy
协议,也就是说NSDictionary
的key是copy一份新的,而value是浅拷贝的(若是想深拷贝可使用NSMapTable)。NSObject
,而且重写-(NSUInteger)hash;
和-(BOOL)isEqual:(id)object;
两个方法。第一个函数用于计算hash值,第二个函数用来判断当哈希值相同的时候value是否相同(解决哈希冲突)。NSDictionary和NSMutableArray底层原理(哈希表和环形缓冲区)