iOS中属性的关键字
assign
assign常常用来修饰基本数据类型而对象类型则使用weak来修饰的原因:
-
对象开辟的空间是在堆空间,销毁和创建都由程序员手动去完成。
-
指针开辟的空间是在栈上,由系统去销毁。
-
使用assign修饰,当对象销毁时并不会将指针置为nil。
-
所以当堆空间的对象销毁时指向对象的指针仍然存在,会造成野指针,当访问该对象时会crash报错EXC_BAD_ACCESS。
-
因为基本数据类型的空间开辟也在栈空间,同样由系统进行销毁,所以不存在野指针的情况。
-
使用weak修饰对象时当对象销毁时指针也会被置为nil,所以用weak不会造成野指针。
strong
指向并持有该对象,引用计数会加1。引用计数为0销毁,可以通过将变量强制赋值 nil 来进行销毁。
weak
指向但是并不持有该对象,引用计数不会加1。在 Runtime 中对该属性进行了相关操作,无需处理,可以自动销毁。
weak的实现
- 初始化时:runtime会调用objc_initWeak函数,初始化一个新的weak指针指向对象的地址。
- 添加引用时:objc_initWeak函数会调用objc_storeWeak() 函数, objc_storeWeak()的作用是更新指针指向,创建对应的弱引用表。
- 释放时,调用weak_unregister_no_lock函数。weak_unregister_no_lock函数首先根据对象地址获取所有weak指针地址的数组,然后遍历这个数组把其中的数据设为nil,最后把这个entry从weak表中删除,最后清理对象的记录。
clang 其实对 __weak 做了转换,将声明方式做出了如下调整。
1
NSObject objc_initWeak(&p, 对象指针);
在Runtime源码中,是这样定义的:
1
2
3
4
5
6
7
8
9
10
11
12
13
id objc_initWeak(id *location, id newObj) {
// 查看对象实例是否有效
// 无效对象直接导致指针释放
if (!newObj) {
*location = nil;
return nil;
}
// 这里传递了三个 bool 数值
// 使用 template 进行常量参数传递是为了优化性能
return storeWeak<false/*old*/, true/*new*/, true/*crash*/>
(location, (objc_object*)newObj);
}
objc_storeWeak() 的实现:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
// HaveOld: true - 变量有值
// false - 需要被及时清理,当前值可能为 nil
// HaveNew: true - 需要被分配的新值,当前值可能为 nil
// false - 不需要分配新值
// CrashIfDeallocating: true - 说明 newObj 已经释放或者 newObj 不支持弱引用,该过程需要暂停
// false - 用 nil 替代存储
template <bool HaveOld, bool HaveNew, bool CrashIfDeallocating>
static id storeWeak(id *location, objc_object *newObj) {
// 该过程用来更新弱引用指针的指向
// 初始化 previouslyInitializedClass 指针
Class previouslyInitializedClass = nil;
id oldObj;
// 声明两个 SideTable
// ① 新旧散列创建
SideTable *oldTable;
SideTable *newTable;
// 获得新值和旧值的锁存位置(用地址作为唯一标示)
// 通过地址来建立索引标志,防止桶重复
// 下面指向的操作会改变旧值
retry:
if (HaveOld) {
// 更改指针,获得以 oldObj 为索引所存储的值地址
oldObj = *location;
oldTable = &SideTables()[oldObj];
} else {
oldTable = nil;
}
if (HaveNew) {
// 更改新值指针,获得以 newObj 为索引所存储的值地址
newTable = &SideTables()[newObj];
} else {
newTable = nil;
}
// 加锁操作,防止多线程中竞争冲突
SideTable::lockTwo<HaveOld, HaveNew>(oldTable, newTable);
// 避免线程冲突重处理
// location 应该与 oldObj 保持一致,如果不同,说明当前的 location 已经处理过 oldObj 可是又被其他线程所修改
if (HaveOld && *location != oldObj) {
SideTable::unlockTwo<HaveOld, HaveNew>(oldTable, newTable);
goto retry;
}
// 防止弱引用间死锁
// 并且通过 +initialize 初始化构造器保证所有弱引用的 isa 非空指向
if (HaveNew && newObj) {
// 获得新对象的 isa 指针
Class cls = newObj->getIsa();
// 判断 isa 非空且已经初始化
if (cls != previouslyInitializedClass &&
!((objc_class *)cls)->isInitialized()) {
// 解锁
SideTable::unlockTwo<HaveOld, HaveNew>(oldTable, newTable);
// 对其 isa 指针进行初始化
_class_initialize(_class_getNonMetaClass(cls, (id)newObj));
// 如果该类已经完成执行 +initialize 方法是最理想情况
// 如果该类 +initialize 在线程中
// 例如 +initialize 正在调用 storeWeak 方法
// 需要手动对其增加保护策略,并设置 previouslyInitializedClass 指针进行标记
previouslyInitializedClass = cls;
// 重新尝试
goto retry;
}
}
// ② 清除旧值
if (HaveOld) {
weak_unregister_no_lock(&oldTable->weak_table, oldObj, location);
}
// ③ 分配新值
if (HaveNew) {
newObj = (objc_object *)weak_register_no_lock(&newTable->weak_table,
(id)newObj, location,
CrashIfDeallocating);
// 如果弱引用被释放 weak_register_no_lock 方法返回 nil
// 在引用计数表中设置若引用标记位
if (newObj && !newObj->isTaggedPointer()) {
// 弱引用位初始化操作
// 引用计数那张散列表的weak引用对象的引用计数中标识为weak引用
newObj->setWeaklyReferenced_nolock();
}
// 之前不要设置 location 对象,这里需要更改指针指向
*location = (id)newObj;
}
else {
// 没有新值,则无需更改
}
SideTable::unlockTwo<HaveOld, HaveNew>(oldTable, newTable);
return (id)newObj;
}
引用计数和弱引用依赖表 SideTable
1
2
3
4
5
6
7
8
struct SideTable {
// 保证原子操作的自旋锁
spinlock_t slock;
// 引用计数的 hash 表
RefcountMap refcnts;
// weak 引用全局 hash 表
weak_table_t weak_table;
}
1
2
3
4
5
6
7
8
9
10
struct weak_table_t {
// 保存了所有指向指定对象的 weak 指针
weak_entry_t *weak_entries;
// 存储空间
size_t num_entries;
// 参与判断引用计数辅助量
uintptr_t mask;
// hash key 最大偏移值
uintptr_t max_hash_displacement;
};
atomic一定是线程安全的吗
atomic所说的线程安全只是保证了getter和setter存取方法的线程安全,并不能保证整个对象是线程安全的。当使用 atomic 时,虽然对属性的读和写是原子的,但是仍然可能出现线程错误:
-
当线程 A 进行写操作,这时其他线程的读或写操作会因为该操作的进行而等待。当 A 线程的写操作结束后,B 线程进行写操作,然后当 A 线程进行读操作时,却获得了在 B 线程中的值,这就破坏了线程安全。
-
如果有线程 C 在 A 线程读操作前 release 了该属性, 那么还会导致程序崩溃。
所以仅仅使用 atomic 并不会使得线程安全, 我们还需要为线程添加 lock 来确保线程的安全。
例子:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
//@property (atomic, assign) int number;
_number = 10;
__weak typeof(self) weakSelf = self;
dispatch_async(mySerialQueue, ^{
weakSelf.number += 2;
for (int i = 0; i < 1000; i++) {
NSLog(@"test = %d",i);
}
NSLog(@"第一次赋值:%d", weakSelf.number);
});
dispatch_async(mySerialQueue, ^{
weakSelf.number += 5;
NSLog(@"第二次赋值:%d", weakSelf.number);
});
从打印结果来看,第一次赋值和第二次赋值_number的值都是17。这是因为打印第一次赋值时,上面进行了耗时的操作(for循环打印), 也就是 A 线程进行读操作时,却获得了在 B 线程中的值。