iOS hash
一、iOS hash
下图列出 Hash 在 iOS 中的应用分析整理
知乎上的一句话:
算法、数据结构、通信协议、文件系统、驱动等,虽然自己不写那些东西,但是了解其原理对于排错、优化自己的代码有很大帮助,就好比虽然你不设计制造汽车,但如果你了解发动机、变速器、安全气囊等几项原理,对于你驾车如何省油、延长使用寿命、保证自身安全有很大好处,学而不思则罔、思而不学则殆,开发人员就是个随波而进的行业,无论何时何地,保持学习的深度和广度对于自身发展是很重要的,谁都不想 60 岁退休了还停留在增删查改的层面。
1.1 关联对象的实现原理
关联对象采用的是 HashMap 嵌套 HashMap 的结构存储数据的,简单来说就是根据对象从第一个 HashMap 中取出存储对象所有关联对象的第二个 HashMap,然后根据属性名从第二个 HashMap 中取出属性对应的值和策略。
设计关联对象的初衷:通过传入对象 + 属性名字,就可以找到属性值。方案设计实现好后,查找一个对象的关联对象的基本步骤:
- 已知条件一:对象,因此引出第一个 HashMap(AssociationsHashMap),用一个能唯一代表对象的值作为 key,用存储对象的所有关联对象的结构(名字:值+策略)作为 value
- 已知条件二:属性名字,因此引出第二个 HashMap(ObjectAssociationMap),用属性名字作为key,用属性名字对应的结构体(值+策略)作为 value。
参考资料:
iOS底层原理总结 - 关联对象实现原理
关联对象 AssociatedObject 完全解析
1.2 weak 的实现原理
weak 采用的是一个全局的 HashMap 嵌套数组的结构存储数据的,销毁对象(weak 指针指向的对象)的时候,根据对象从 HashMap 中找到存放所有指向该对象的 weak 指针的数组,然后将数组中的所有元素都置为 nil。
weak 的最大特点就是在对象销毁时,自动置 nil,减少访问野指针的风险,这也是设计 weak 的初衷。方案设计实现好后,weak 指针置 nil 的基本步骤:
- 对象 dealloc 的时候,从全局的 HashMap 中,根据一个唯一代表对象的值作为 key,找到存储所有指向该对象的 weak 指针的数组;
- 将数组中的所有元素都置为 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的原理
参考文章:笔记-集合NSSet、字典NSDictionary的底层实现原理
二、哈希表
2.1 哈希表定义
哈希表(hash table,也叫散列表),是根据键(key)直接访问访问在内存储存位置的数据结构。
哈希表本质是一个数组,数组中的每一个元素成为一个箱子,箱子中存放的是键值对。根据下标 index 从数组中取 value。关键是如何获取 index,这就需要一个固定的函数(哈希函数),将 key 转换成 index。不论哈希函数设计的如何完美,都可能出现不同的 key 经过 hash 处理后得到相同的 hash 值,这时候就需要处理哈希冲突。
2.2 哈希表优缺点
优点
- 哈希表可以提供快速的操作。
缺点
- 哈希表通常是基于数组的,数组创建后难于扩展。
- 没有一种简便的方法可以以任何一种顺序〔例如从小到大)遍历表中的数据项。
综上,如果不需要有序遍历数据,井且可以提前预测数据量的大小。那么哈希表在速度和易用性方面是无与伦比的。
2.3 哈希查找步骤
- 使用哈希函数将被查找的键映射(转换)为数组的索引,理想情况下(hash 函数设计合理)不同的键映射的数组下标也不同,所有的查找时间复杂度为 O(1)。但是实际情况下不是这样的,所以哈希查找的第二步就是处理哈希冲突。
- 处理哈希碰撞冲突。处理方法有很多,比如拉链法、线性探测法。
2.4 哈希表存储过程:
- 使用 hash 函数根据 key 得到哈希值 h
- 如果箱子的个数为 n,那么值应该存放在底(h%n)个箱子中。h%n 的值范围为 [0, n-1]。
- 如果该箱子非空(已经存放了一个值)即不同的 key 得到了相同的h产生了哈希冲突,此时需要使用拉链法或者开放定址线性探测法解决冲突。
2.5 常用哈希函数
哈希查找第一步就是使用哈希函数将键映射成索引。这种映射函数就是哈希函数。如果我们有一个保存 0~M 数组,那么我们就需要一个能够将任意键转换为该数组范围内的索引(0~M-1)的哈希函数。哈希函数需要易于计算并且能够均匀分布所有键。比如举个简单的例子,使用手机号码后三位就比前三位作为 key 更好,因为前三位手机号码的重复率很高。再比如使用身份证号码出生年月位数要比使用前几位数要更好。
在实际中,我们的键并不都是数字,有可能是字符串,还有可能是几个值的组合等,所以我们需要实现自己的哈希函数。
- 直接寻址法
- 数字分析法
- 平方取中法
- 折叠法
- 随机数法
- 除留余数法
要想设计一个优秀的哈希算法并不容易,根据经验,总结了需要满足的几点要求:
- 从哈希值不能反向推导出原始数据(所以哈希算法也叫单向哈希算法);
- 对输入数据非常敏感,哪怕原始数据只修改了一个 Bit,最后得到的哈希值也大不相同;
- 散列冲突的概率要很小,对于不同的原始数据,哈希值相同的概率非常小;
- 哈希算法的执行效率要尽量高效,针对较长的文本,也能快速地计算出哈希值。
2.6 负载因子
负载因子 = 总键值对数/数组的个数
负载因子是哈希表的一个重要属性,用来衡量哈希表的空/满程度,一定程度也可以提现查询的效率。负载因子越大,意味着哈希表越满,越容易导致冲突,性能也就越低。所以当负载因子大于某个常数(一般是0.75)时,哈希表将自动扩容。哈希表扩容时,一般会创建两倍于原来的数组长度。因此即使 key 的哈希值没有变化,对数组个数取余的结果会随着数组个数的扩容发生变化,因此键值对的位置都有可能发生变化,这个过程也成为重哈希(rehash)。
2.7 哈希表扩容
- 在数组比较多的时候,需要重新哈希并移动数据,性能影响较大。
- 虽然能够使负载因子降低,但并不总是能有效提高哈希表的查询性能。比如哈希函数设计的不合理,导致所有的 key 计算出的哈希值都相同,那么即使扩容他们的位置还是在同一条链表上,变成了线性表,性能极低,查询的时候时间复杂度就变成了 O(n)。
2.8 哈希冲突的解决方法
拉链法
简单来说就是数组 + 链表。将键通过 hash 函数映射为大小为 M 的数组的下标索引,数组的每一个元素指向一个链表,链表中的每一个结点存储着 hash 出来的索引值为结点下标的键值对。
Java 8 解决哈希冲突采用的就是拉链法。在处理哈希函数设计不合理导致链表很长时(链表长度超过 8 切换为红黑树,小于 6 重新退化为链表)。将链表切换为红黑树能够保证插入和查找的效率,缺点是当哈希表比较大时,哈希表扩容会导致瞬时效率降低。
Redis 解决哈希冲突采用的也是拉链法。通过增量式扩容解决了 Java 8 中的瞬时扩容导致的瞬时效率降低的缺点,同时拉链法的实现方式(新插入的键值对放在链表头部)带来了两个好处:
- 头插法可以节省插入耗时。如果插到尾部,则需要时间复杂度为 O(n) 的操作找到链表尾部,或者需要额外的内存地址来保存尾部链表的位置。
- 头插法可以节省查找耗时。对于一个数据系统来说,最新插入的数据往往可能频繁的被查询。
开放定址线性探测法
使用两个大小为 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,且结点较大时,拉链法中增加的指针域可忽略不计,因此节省空间;
- 在用拉链法构造的散列表中,删除结点的操作易于实现。只要简单地删去链表上相应的结点即可。而对开放定址线性探测发构造的散列表,删除结点不能简单地将被删结 点的空间置为空,否则将截断在它之后填人散列表的同义词结点的查找路径。这是因为各种开放定址线性探测发中,空地址单元(即开放地址)都是查找失败的条件。因此在用开放定址线性探测发处理冲突的散列表上执行删除操作,只能在被删结点上做删除标记,而不能真正删除结点。
拉链法的缺点
- 指针需要额外的空间,故当结点规模较小时,开放定址线性探测发较为节省空间,而若将节省的指针空间用来扩大散列表的规模,可使装填因子变小,这又减少了开放定址线性探测发中的冲突,从而提高平均查找速度。
开放定址线性探测法缺点
- 容易产生堆积问题;
- 不适于大规模的数据存储;
- 散列函数的设计对冲突会有很大的影响;
- 插入时可能会出现多次冲突的现象,删除的元素是多个冲突元素中的一个,需要对后面的元素作处理,实现较复杂;
- 结点规模很大时会浪费很多空间;
2.9 Hash 表的平均查找长度
Hash 表的平均查找长度包括查找成功时的平均查找长度和查找失败时的平均查找长度。
查找成功时的平均查找长度=表中每个元素查找成功时的比较次数之和/表中元素个数;
查找不成功时的平均查找长度相当于在表中查找元素不成功时的平均比较次数,可以理解为向表中插入某个元素,该元素在每个位置都有可能,然后计算出在每个位置能够插入时需要比较的次数,再除以表长即为查找不成功时的平均查找长度。
例子:
给定一组数据{32,14,23,01,42,20,45,27,55,24,10,53},假设散列表的长度为 13(最接近 n 的质数),散列函数为 H(k) = k。分别画出用 线性探测法 和 拉链法 解决冲突时构造的哈希表,并求出在等概率下情况,这两种方法查找成功和查找不成功的平均查找长度。
拉链法
查找成功时的平均查找长度: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.10 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 存放到链表中,遍历链表的时间
上面的结论和对应的解释似乎很合理?看看下面的分析再说也不迟!
版本二
是对 _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 都是用了。具体使用哪一种是根据存储数据的生命周期和特性决定的。
@synchronized 使用的是拉链法。拉链法多用于存储的数据是通用类型,能够被反复利用,就像@synchronized 存储的是锁是一种无关业务的实现结构,程序运行时多个对象使用同一个锁的概率相当高,有效的节省了内存。
weak 对象 associatedObject 采用的是开放定址线性探测法。开放定址线性探测法用于存储的数据是临时的,用完尽快释放,就像 associatedObject,weak。
2.12 NSDictionary 的存储过程
- 通过方法
- (void)setObject:(id)anObject forKey:(id)aKey;
可以看出key必须遵循 NSCopy 协议,也就是说 NSDictionary 的 key 是 copy 一份新的,而 value 是浅拷贝的(如果想深拷贝可以使用 NSMapTable)。 - key 还必须要继承 NSObject,并且重写
-(NSUInteger)hash;
和-(BOOL)isEqual:(id)object;
两个方法。第一个函数用于计算 hash 值,第二个函数用来判断当哈希值相同的时候 value 是否相同(解决哈希冲突)。
2.13 字符串的 hash 方法
At least there are special circumstances for which this unreliability kicks in.
Comparing [a hash] and [b hash] of two different NSString is safe when:
the strings' length is shorter or equal to 96 characters.
[a length] is different to [b length].
the concatinated first, middle, and last 32 characters of a differ to the concatinated components of b.
Otherwise every difference between the first and the middle 32 chars, as well as every difference between the middle and the last 32 characters, are not used while producing the [NSString hash] value.
[NSString hash]
这个方法对 <=96
个字符的字符串是安全的,如果比 96 个字符长,会大大增加碰撞的概率。
#define HashEverythingLimit 96
#define HashNextFourUniChars(accessStart, accessEnd, pointer) \
{result = result * 67503105 + (accessStart 0 accessEnd) * 16974593 + (accessStart 1 accessEnd) * 66049 + (accessStart 2 accessEnd) * 257 + (accessStart 3 accessEnd); pointer += 4;}
#define HashNextUniChar(accessStart, accessEnd, pointer) \
{result = result * 257 + (accessStart 0 accessEnd); pointer++;}
CF_INLINE CFHashCode __CFStrHashCharacters(const UniChar *uContents, CFIndex len, CFIndex actualLen) {
CFHashCode result = actualLen;
// ****X 这里HashEverythingLimit = 96
if (len <= HashEverythingLimit) {
// ****X 若字符串长度在96以内,对所有的字符做hash运算得到一个结果
const UniChar *end4 = uContents + (len & ~3);
const UniChar *end = uContents + len;
while (uContents < end4) HashNextFourUniChars(uContents[, ], uContents); // First count in fours
while (uContents < end) HashNextUniChar(uContents[, ], uContents); // Then for the last <4 chars, count in ones...
} else {
// ****X 若字符串长度超过96
const UniChar *contents, *end;
// ****X 取前32个字符做hash运算
contents = uContents;
end = contents + 32;
while (contents < end) HashNextFourUniChars(contents[, ], contents);
// ****X 取中间32个字符做hash运算
contents = uContents + (len >> 1) - 16;
end = contents + 32;
while (contents < end) HashNextFourUniChars(contents[, ], contents);
// ****X 取最后32个字符做hash运算
end = uContents + len;
contents = end - 32;
while (contents < end) HashNextFourUniChars(contents[, ], contents);
}
return result + (result << (actualLen & 31));
}
如果长度大于 96,只有前、中、后 32 个字符做了哈希运算,也就是说在这些字符相同的情况下,其他任意位置的字符发生改变,Hash 值都不会变。
在工程中使用字符串的 hash 方法作为数据是否发生改变的依据,发现方法返回的 hash 值为一个很大的负数,这是因为数值大小超出了数据类型能够表达的范围了。
可以使用 md5 算法代替系统的 hash 算法。
文章
浅谈算法和数据结构: 十一 哈希表
NSDictionary和NSMutableArray底层原理(哈希表和环形缓冲区)
Swift中字典的实现原理
深入理解哈希表
解读Objective-C的NSDictionary
iOS重做轮子,写一个NSDictionary(一)
哈希表——线性探测法、链地址法、查找成功、查找不成功的平均长度
哈希表、哈希算法、一致性哈希表
细说@synchronized和dispatch_once
iOS hash的更多相关文章
- NSDictionary实现原理-ios哈希hash和isEqual
NSDictionary实现原理-ios哈希hash和isEqual OC中自定义类的NSCopying实现的注意事项(isEqual & hash实现) http://blog.csdn ...
- iOS开发 之 不要告诉我你真的懂isEqual与hash!
目录 为什么要有isEqual方法? 如何重写自己的isEqual方法? 为什么要有hash方法? hash方法什么时候被调用? hash方法与判等的关系? 如何重写自己的hash方法? 为什么要有i ...
- iOS判断对象相等 重写isEqual、isEqualToClass、hash
相等的概念是探究哲学和数学的核心,并且对道德.公正和公共政策的问题有着深远的影响. 从一个经验主义者的角度来看,两个物体不能依据一些观测标准中分辨出来,它们就是相等的.在人文方面,平等主义者认为相等意 ...
- vue开发关于微信授权登录以及路由mode模式(Hash|History)和手机平台(andriod|IOS)不得不说的故事
引用链接: https://segmentfault.com/a/1190000010753247?utm_source=tuicool&utm_medium=referral
- iOS开发系列--通讯录、蓝牙、内购、GameCenter、iCloud、Passbook系统服务开发汇总
--系统应用与系统服务 iOS开发过程中有时候难免会使用iOS内置的一些应用软件和服务,例如QQ通讯录.微信电话本会使用iOS的通讯录,一些第三方软件会在应用内发送短信等.今天将和大家一起学习如何使用 ...
- IOS开发基础知识碎片-导航
1:IOS开发基础知识--碎片1 a:NSString与NSInteger的互换 b:Objective-c中集合里面不能存放基础类型,比如int string float等,只能把它们转化成对象才可 ...
- [转][iOS]NSHashTable & NSMapTable
NSSet and NSDictionary, along with NSArray are the workhorse collection classes of Foundation. Unlik ...
- 细数iOS上的那些安全防护
细数iOS上的那些安全防护 龙磊,黑雪,蒸米 @阿里巴巴移动安全 0x00 序 随着苹果对iOS系统多年的研发,iOS上的安全防护机制也是越来越多,越来越复杂.这对于刚接触iOS安全的研究人员来说非 ...
- iOS面试题集锦
一.前言部分 文中的问题多收集整理自网络,不保证100%准确,还望斟酌采纳. 1.怎样防止指针的越界使用问题? 答案: 1 .防止数组越界,必须让指针指向一个有效的内存地址, 2. 防止向一块内存中拷 ...
随机推荐
- Ubutun18.04安装Python3.7.6
最近因为环境问题,简单记录下Python3.7的安装过程: 下载地址:http://python.org/ftp/python/3.7.6/Python-3.7.6.tgz 编译安装步骤: sudo ...
- JavaScript,ajax与springboot之间的传参方式
Springboot:@PostMapping("/mDelTest")public String mDelTest (@RequestBody List<String> ...
- 三个值得期待的JavaScript新功能!
让我们来看看JavaScript中一些有用的即将推出的功能.您将看到他们的语法,链接以及时了解他们的进度,我们将编写一个小型测试套件,以展示如何立即开始使用这些提案! JavaScript是如何更新迭 ...
- React解决长列表方案(react-virtualized)
github地址 高效渲染大型列表的响应式组件 使用窗口特性,即在一个滚动的范围内,呈现你给定数据的一小部分,大量缩减了呈现组件所需的时间,以及创建DOM节点的数量. 缺点:滑动过快,可能会出现空白的 ...
- mysql从5.5升级到5.7遇到的坑
在安装mysql5.7时很顺利安装完成,但在启动项目时报错: [Err] 1055 - Expression #1 of ORDER BY clause is not in GROUP BY clau ...
- AI广度优先搜索算法,项目实战北京地图/贪心学院
广度优先搜索算法详解地铁路线 北京很大,附上地铁图,不要迷路!!! 作为一个程序员,在北京,你很有可能住在回龙观地区,经常从龙泽上地铁,然后畅游北京. 当有一天,你老家的朋友来北京了,希望你能够带她去 ...
- Redis(6)——GeoHash查找附近的人
像微信 "附近的人",美团 "附近的餐厅",支付宝共享单车 "附近的车" 是怎么设计实现的呢? 一.使用数据库实现查找附近的人 我们都知道, ...
- 图像IO
图像IO 潜伏期值得思考 - 凯文 帕萨特 在第13章“高效绘图”中,我们研究了和Core Graphics绘图相关的性能问题,以及如何修复.和绘图性能相关紧密相关的是图像性能.在这一章中,我们将研究 ...
- 安装archlinux的另辟蹊径的命令及心得
先说说我为什么开始入坑archlinux的吧,我最喜欢这个系统的一点就是简洁,DIY程度高,可以定制真正属于自己的专用系统.(像gentoo的话,就为了日常使用也没必要那么折腾,除非你是想在折腾的过程 ...
- 数据库中的两个最重要的日志redo log和binlog
mysql整体来看其实只有两部分,一部分是server层,一部分是引擎层. 1.redo log(重做日志):当有一条记录需要更新的时候,InnoDB 引擎就会先把记录写入redo log里面,并更新 ...