記憶體管理在APP開發過程中佔據著一個很重要的地位，在iOS中，系統為我們提供了ARC的開發環境，幫助我們做了很多記憶體管理的內容。本章我們先來看一下，平時開發中使用最多的weak在底層是如何進行實現的
weak作用
我們通過例子?來看一下__strong、__weak、__unsafe_unretained的區別在哪裡.
首先是看如下例子，可以知道在臨時作用域結束之後，生成的物件就會進行銷燬，我們在作用域外部用修飾符來持有物件，再來看一下物件的銷燬情況
NSLog(@"臨時作用域開始");
{
LGPerson *person = [[LGPerson alloc] init];
NSLog(@"person物件：%@", person);
}
NSLog(@"臨時作用域結束");
***************************列印結果******************************
2020-01-19 10:57:13.910542+0800 objc-debug[74175:19740208] 臨時作用域開始
2020-01-19 10:57:13.911181+0800 objc-debug[74175:19740208] person物件：<LGPerson: 0x10221c900>
2020-01-19 10:57:13.911277+0800 objc-debug[74175:19740208] LGPerson -[LGPerson dealloc]
2020-01-19 10:57:13.911367+0800 objc-debug[74175:19740208] 臨時作用域結束
複製程式碼先來看一下用__strong修飾的結果。可以發現修飾的物件在作用域結束之後並沒有銷燬，說明該物件的引用計數增加了
__strong LGPerson *strongPerson;
NSLog(@"臨時作用域開始");
{
LGPerson *person = [[LGPerson alloc] init];
NSLog(@"person物件：%@", person);
strongPerson = person;
}
NSLog(@"臨時作用域結束");
NSLog(@"strongPerson：%@", strongPerson);
***************************列印結果******************************
2020-01-19 11:54:44.079292+0800 objc-debug[74452:19777011] 臨時作用域開始
2020-01-19 11:54:44.080060+0800 objc-debug[74452:19777011] person物件：<LGPerson: 0x101945ae0>
2020-01-19 11:54:44.080172+0800 objc-debug[74452:19777011] 臨時作用域結束
2020-01-19 11:54:44.080292+0800 objc-debug[74452:19777011] strongPerson：<LGPerson: 0x101945ae0>
複製程式碼再來看一下__weak修飾的結果。通過下面的執行我們可以發現，用__weak修飾後，並沒有增加引用計數，並且作用域結束，物件釋放後，修飾的物件為nil，沒有造成野指標的崩潰，可以說是一種安全的方案
__weak LGPerson *weakPerson;
NSLog(@"臨時作用域開始");
{
LGPerson *person = [[LGPerson alloc] init];
NSLog(@"person物件：%@", person);
weakPerson = person;
}
NSLog(@"臨時作用域結束");
NSLog(@"weakPerson：%@", weakPerson);
***************************列印結果******************************
2020-01-19 11:58:08.842409+0800 objc-debug[74479:19780263] 臨時作用域開始
2020-01-19 11:58:08.843151+0800 objc-debug[74479:19780263] person物件：<LGPerson: 0x101712030>
2020-01-19 11:58:08.843382+0800 objc-debug[74479:19780263] LGPerson -[LGPerson dealloc]
2020-01-19 11:58:08.843572+0800 objc-debug[74479:19780263] 臨時作用域結束
2020-01-19 11:58:08.843762+0800 objc-debug[74479:19780263] weakPerson：(null)
複製程式碼最後我們來看一下，平時開發使用較少的__unsafe_unretained和上面兩個的區別在哪。我們通過結果可以發現，在作用域消失，物件就進行了銷燬，並且在出作用域列印修飾物件時，出現了野指標的崩潰EXC_BAD_ACCESS
所以這樣就看出了__weak和__unsafe_unretained的區別就是前者會在物件被釋放的時候自動置為nil，而後者卻不行。
__unsafe_unretained LGPerson *unsafePerson;
NSLog(@"臨時作用域開始");
{
LGPerson *person = [[LGPerson alloc] init];
NSLog(@"person物件：%@", person);
unsafePerson = person;
}
NSLog(@"臨時作用域結束");
NSLog(@"unsafePerson：%@", unsafePerson);
***************************列印結果******************************
2020-01-19 12:02:34.428120+0800 objc-debug[74513:19785153] 臨時作用域開始
2020-01-19 12:02:34.428813+0800 objc-debug[74513:19785153] person物件：<LGPerson: 0x1019159f0>
2020-01-19 12:02:34.428901+0800 objc-debug[74513:19785153] LGPerson -[LGPerson dealloc]
2020-01-19 12:02:34.429015+0800 objc-debug[74513:19785153] 臨時作用域結束
複製程式碼小結
__strong修飾後，物件的引用計數會增加，在作用域外不會銷燬__weak修飾後，物件引用計數不會增加，在作用域外會自動置為nil__unsafe_unretained修飾後，引用計數不會增加，在作用域外不會置空，會造成野指標崩潰
通過上面例子基本瞭解了__weak的作用，那麼__weak是如何進行建立和銷燬的呢，下面通過原始碼進行深度探索
weak的建立
還是使用剛才的例子，直接跟蹤彙編和打符號斷點，發現底層庫調了objc_initWeak函式
objc_initWeak
其中兩個引數location和newObj的含義如下
location：表示__weak指標的地址，即例子中的weak指標取地址：&weakObjc。它是一個指標的地址。之所以要儲存指標的地址，是因為最後我們要講__weak指標指向的內容置為nil，如果僅儲存指標的話，是不能夠完成這個功能的。newObj：所引用的物件，即例子中的person。
id
objc_initWeak(id *location, id newObj)
{
if (!newObj) {
*location = nil;
return nil;
}
return storeWeak<DontHaveOld, DoHaveNew, DoCrashIfDeallocating>
(location, (objc_object*)newObj);
}
複製程式碼storeWeak
檢視storeWeak原始碼，根據註釋，可以知道如下幾點
HaveOld：weak指標之前是否已經指向了一個弱引用HaveNew：weak指標是否需要指向一個新引用CrashIfDeallocating：如果被弱引用的物件正在析構，此時再弱引用該物件，是否應該crash。
// Update a weak variable.
// If HaveOld is true, the variable has an existing value
// that needs to be cleaned up. This value might be nil.
// If HaveNew is true, there is a new value that needs to be
// assigned into the variable. This value might be nil.
// If CrashIfDeallocating is true, the process is halted if newObj is
// deallocating or newObj's class does not support weak references.
// If CrashIfDeallocating is false, nil is stored instead.
enum CrashIfDeallocating {
DontCrashIfDeallocating = false, DoCrashIfDeallocating = true
};
template <HaveOld haveOld, HaveNew haveNew,
CrashIfDeallocating crashIfDeallocating>
static id
storeWeak(id *location, objc_object *newObj)
{
assert(haveOld || haveNew);
if (!haveNew) assert(newObj == nil);
Class previouslyInitializedClass = nil;
id oldObj;
SideTable *oldTable;
SideTable *newTable;
// Acquire locks for old and new values.
// Order by lock address to prevent lock ordering problems.
// Retry if the old value changes underneath us.
retry:
✅// 如果weak指標之前弱引用過一個obj，則將這個obj所對應的SideTable取出，賦值給oldTable
if (haveOld) {
oldObj = *location;
oldTable = &SideTables()[oldObj];
} else {
// 沒有弱引用過，則oldTable = nil
oldTable = nil;
}
✅// 如果weak指標要弱引用一個新的obj，則將該obj對應的SideTable取出，賦值給newTable
if (haveNew) {
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;
}
// Prevent a deadlock between the weak reference machinery
// and the +initialize machinery by ensuring that no
// weakly-referenced object has an un-+initialized isa.
if (haveNew && newObj) {
Class cls = newObj->getIsa();
✅// 如果cls還沒有初始化，先初始化，再嘗試設定弱引用
if (cls != previouslyInitializedClass &&
!((objc_class *)cls)->isInitialized())
{
SideTable::unlockTwo<haveOld, haveNew>(oldTable, newTable);
_class_initialize(_class_getNonMetaClass(cls, (id)newObj));
// If this class is finished with +initialize then we're good.
// If this class is still running +initialize on this thread
// (i.e. +initialize called storeWeak on an instance of itself)
// then we may proceed but it will appear initializing and
// not yet initialized to the check above.
// Instead set previouslyInitializedClass to recognize it on retry.
✅// 完成初始化後進行標記
previouslyInitializedClass = cls;
✅// newObj 初始化後，重新獲取一遍newObj
goto retry;
}
}
// Clean up old value, if any.
✅// 如果weak指標之前弱引用過別的物件oldObj，則呼叫weak_unregister_no_lock，在oldObj的weak_entry_t中移除該weak指標地址
if (haveOld) {
weak_unregister_no_lock(&oldTable->weak_table, oldObj, location);
}
// Assign new value, if any.
✅// 如果weak指標需要弱引用新的物件newObj
if (haveNew) {
✅ // 呼叫weak_register_no_lock方法，將weak指標的地址記錄到newObj對應的weak_entry_t中
newObj = (objc_object *)
weak_register_no_lock(&newTable->weak_table, (id)newObj, location,
crashIfDeallocating);
// weak_register_no_lock returns nil if weak store should be rejected
// Set is-weakly-referenced bit in refcount table.
✅// 更新newObj的isa指標的weakly_referenced bit標誌位
if (newObj && !newObj->isTaggedPointer()) {
newObj->setWeaklyReferenced_nolock();
}
// Do not set *location anywhere else. That would introduce a race.
✅// *location 賦值，也就是將weak指標直接指向了newObj，而且沒有將newObj的引用計數+1
*location = (id)newObj;
}
else {
// No new value. The storage is not changed.
}
SideTable::unlockTwo<haveOld, haveNew>(oldTable, newTable);
return (id)newObj;
}
複製程式碼因為我們這裡是第一次呼叫，所以是一個新的物件，也就是haveNew的情況，獲取到的是新的雜湊表SideTable，主要執行了weak_register_no_lock方法來進行插入。
weak_register_no_lock
接著我們來分析weak_register_no_lock函式，是怎麼註冊弱引用的。
我們發現函式內部主要進行了isTaggedPointer和deallocating的判斷等前置條件，這些都是不能進行弱引用的情況。
如果可以被弱引用，則將被弱引用物件所在的weak_table中的weak_entry_t雜湊陣列中取出對應的weak_entry_t，如果weak_entry_t不存在，則會新建一個。然後將指向被弱引用物件地址的指標referrer通過函式append_referrer插入到對應的weak_entry_t引用陣列。至此就完成了弱引用。
id weak_register_no_lock(weak_table_t *weak_table, id referent_id,
id *referrer_id, bool crashIfDeallocating)
{
✅//首先獲取需要弱引用物件
objc_object *referent = (objc_object *)referent_id;
objc_object **referrer = (objc_object **)referrer_id;
✅// 如果被弱引用物件referent為nil 或者被弱引用物件採用了TaggedPointer計數方式，則直接返回
if (!referent || referent->isTaggedPointer()) return referent_id;
// ensure that the referenced object is viable
✅// 確保被引用的物件可用（沒有在析構，同時應該支援weak弱引用）
bool deallocating;
if (!referent->ISA()->hasCustomRR()) {
deallocating = referent->rootIsDeallocating();
}
else {
BOOL (*allowsWeakReference)(objc_object *, SEL) =
(BOOL(*)(objc_object *, SEL))
object_getMethodImplementation((id)referent,
SEL_allowsWeakReference);
if ((IMP)allowsWeakReference == _objc_msgForward) {
return nil;
}
deallocating =
! (*allowsWeakReference)(referent, SEL_allowsWeakReference);
}
✅// 如果是正在析構的物件，那麼不能夠被弱引用
if (deallocating) {
if (crashIfDeallocating) {
_objc_fatal("Cannot form weak reference to instance (%p) of "
"class %s. It is possible that this object was "
"over-released, or is in the process of deallocation.",
(void*)referent, object_getClassName((id)referent));
} else {
return nil;
}
}
// now remember it and where it is being stored
✅// 在 weak_table 中找到被弱引用物件 referent 對應的 weak_entry,並將 referrer 加入到 weak_entry 中
weak_entry_t *entry;
if ((entry = weak_entry_for_referent(weak_table, referent))) {
✅// 如果能找到 weak_entry,則講 referrer 插入到 weak_entry 中
append_referrer(entry, referrer);
}
else {
✅// 如果找不到 weak_entry，就新建一個
weak_entry_t new_entry(referent, referrer);
weak_grow_maybe(weak_table);
weak_entry_insert(weak_table, &new_entry);
}
// Do not set *referrer. objc_storeWeak() requires that the
// value not change.
return referent_id;
}
複製程式碼append_referrer
這一步主要是找到弱引用物件的對應的weak_entry雜湊陣列中，基本就是個遍歷插入的過程，原理比較簡單
static void append_referrer(weak_entry_t *entry, objc_object **new_referrer)
{
✅// 如果weak_entry 使用靜態陣列 inline_referrers
if (! entry->out_of_line()) {
// Try to insert inline.
✅// 嘗試將 referrer 插入陣列
for (size_t i = 0; i < WEAK_INLINE_COUNT; i++) {
if (entry->inline_referrers[i] == nil) {
entry->inline_referrers[i] = new_referrer;
return;
}
}
// Couldn't insert inline. Allocate out of line.
✅// 如果inline_referrers的位置已經存滿了，則要轉型為 referrers，動態陣列
weak_referrer_t *new_referrers = (weak_referrer_t *)
calloc(WEAK_INLINE_COUNT, sizeof(weak_referrer_t));
// This constructed table is invalid, but grow_refs_and_insert
// will fix it and rehash it.
for (size_t i = 0; i < WEAK_INLINE_COUNT; i++) {
new_referrers[i] = entry->inline_referrers[i];
}
entry->referrers = new_referrers;
entry->num_refs = WEAK_INLINE_COUNT;
entry->out_of_line_ness = REFERRERS_OUT_OF_LINE;
entry->mask = WEAK_INLINE_COUNT-1;
entry->max_hash_displacement = 0;
}
assert(entry->out_of_line());
✅// 如果動態陣列中元素個數大於或等於陣列總空間的3/4，則擴充套件陣列空間為當前長度的一倍，然後將 referrer 插入陣列
if (entry->num_refs >= TABLE_SIZE(entry) * 3/4) {
return grow_refs_and_insert(entry, new_referrer);
}
✅// 如果不需要擴容，直接插入到weak_entry中
✅// & (entry->mask) 保證 begin 的位置只能大於或等於陣列的長度
size_t begin = w_hash_pointer(new_referrer) & (entry->mask);
size_t index = begin;
size_t hash_displacement = 0;
while (entry->referrers[index] != nil) {
hash_displacement++;
index = (index+1) & entry->mask;
if (index == begin) bad_weak_table(entry);
}
if (hash_displacement > entry->max_hash_displacement) {
entry->max_hash_displacement = hash_displacement;
}
weak_referrer_t &ref = entry->referrers[index];
ref = new_referrer;
entry->num_refs++;
}
複製程式碼weak_unregister_no_lock
如果weak指標在指向obj之前，已經弱引用了其他的物件，則需要先將weak指標從其他物件的weak_entry_t的hash陣列中移除。在storeWeak方法中會呼叫weak_unregister_no_lock函式來做移除操作，我們來看一下weak_unregister_no_lock函式原始碼
weak_unregister_no_lock函式首先會在weak_table中找出以前被弱引用的物件referent對應的weak_entry_t，在weak_entry_t中移除被弱引用的物件referrer。移除元素後，判斷此時weak_entry_t中是否還有元素。如果此時weak_entry_t已經沒有元素了，則需要將weak_entry_t從weak_table中移除。
void weak_unregister_no_lock(weak_table_t *weak_table, id referent_id,
id *referrer_id)
{
✅// 拿到以前弱引用的物件和物件的地址
objc_object *referent = (objc_object *)referent_id;
objc_object **referrer = (objc_object **)referrer_id;
weak_entry_t *entry;
if (!referent) return;
✅// 查詢到以前弱引用的物件 referent 所對應的 weak_entry_t
if ((entry = weak_entry_for_referent(weak_table, referent))) {
✅// 在以前弱引用的物件 referent 所對應的 weak_entry_t 的 hash 陣列中，移除弱引用 referrer
remove_referrer(entry, referrer);
✅// 移除元素之後， 要檢查一下 weak_entry_t 的 hash 陣列是否已經空了
bool empty = true;
if (entry->out_of_line() && entry->num_refs != 0) {
empty = false;
}
else {
for (size_t i = 0; i < WEAK_INLINE_COUNT; i++) {
if (entry->inline_referrers[i]) {
empty = false;
break;
}
}
}
✅// 如果 weak_entry_t 的hash陣列已經空了，則需要將 weak_entry_t 從 weak_table 中移除
if (empty) {
weak_entry_remove(weak_table, entry);
}
}
// Do not set *referrer = nil. objc_storeWeak() requires that the
// value not change.
}
複製程式碼至此，一個物件的弱引用過程已經結束
weak的銷燬
通過開頭的例子，我們知道，出作用域，物件dealloc後，會自動把弱引用物件置空，那麼他是怎麼實現的，我們可以簡單檢視下類的dealloc流程
_objc_rootDealloc
- (void)dealloc {
_objc_rootDealloc(self);
}
**********************************
void _objc_rootDealloc(id obj)
{
assert(obj);
obj->rootDealloc();
}
***********************************
inline void objc_object::rootDealloc()
{
//✅如果是Tagged Pointer，就直接返回
if (isTaggedPointer()) return; // fixme necessary?
/*
✅如果同時滿足
1. 是優化過的isa、
2. 沒有被weak指標引用過、
3. 沒有關聯物件、
4. 沒有C++解構函式、
5. 沒有sideTable，
就可以直接釋放記憶體free()
*/
if (fastpath(isa.nonpointer &&
!isa.weakly_referenced &&
!isa.has_assoc &&
!isa.has_cxx_dtor &&
!isa.has_sidetable_rc))
{
assert(!sidetable_present());
free(this);
}
else {//否則的話就需要通過下面的函式處理
object_dispose((id)this);
}
}
複製程式碼我們這裡顯然不滿足上述條件，因為我們弱引用過，繼續跟進object_dispose
object_dispose
object_dispose函式中呼叫了objc_destructInstance
id
object_dispose(id obj)
{
if (!obj) return nil;
objc_destructInstance(obj);
free(obj);
return nil;
}
***********************************
複製程式碼objc_destructInstance
我們可以看到內部會做銷燬C++解構函式以及移除關聯物件的操作，看來弱引用要在clearDeallocating中了
void *objc_destructInstance(id obj)
{
if (obj) {
// Read all of the flags at once for performance
bool cxx = obj->hasCxxDtor();
bool assoc = obj->hasAssociatedObjects();
// This order is important.
✅ // 如果有C++解構函式，則從執行相關函式
if (cxx) object_cxxDestruct(obj);
✅// 如果有關聯物件，則移除所有的關聯物件，並將其自身從Association Manager的map中移除
if (assoc) _object_remove_assocations(obj);
✅// 繼續清理其它相關的引用
obj->clearDeallocating();
}
return obj;
}
複製程式碼clearDeallocating
inline void
objc_object::clearDeallocating()
{
if (slowpath(!isa.nonpointer)) {
// Slow path for raw pointer isa.
✅// 如果要釋放的物件沒有采用了優化過的isa引用計數
sidetable_clearDeallocating();
}
else if (slowpath(isa.weakly_referenced || isa.has_sidetable_rc)) {
// Slow path for non-pointer isa with weak refs and/or side table data.
✅// 如果要釋放的物件採用了優化過的isa引用計數，並且有弱引用或者使用了sideTable的輔助引用計數
clearDeallocating_slow();
}
assert(!sidetable_present());
}
複製程式碼clearDeallocating_slow
我們現在一般都是使用優化的isa引用計數,所以我們以此為目的繼續探索。我們通過原始碼可以看到主要是操作為找到對應的SideTable,然後再SideTable的weak_table中，將弱引用物件置空，主要的方法為weak_clear_no_lock
NEVER_INLINE void
objc_object::clearDeallocating_slow()
{
assert(isa.nonpointer && (isa.weakly_referenced || isa.has_sidetable_rc));
✅// 在全域性的SideTables中，以this指標(要釋放的物件)為key，找到對應的SideTable
SideTable& table = SideTables()[this];
table.lock();
if (isa.weakly_referenced) {
✅//要釋放的物件被弱引用了，通過weak_clear_no_lock函式將指向該物件的弱引用指標置為nil
weak_clear_no_lock(&table.weak_table, (id)this);
}
✅//使用了sideTable的輔助引用計數,直接在SideTable中擦除該物件的引用計數
if (isa.has_sidetable_rc) {
table.refcnts.erase(this);
}
table.unlock();
}
複製程式碼weak_clear_no_lock
我們通過原始碼可以看到，這不方法和插入時的方法比較類似，都是找到對應的eak_entry_t陣列，然後通過遍歷找到對應的指標地址，然後置為nil，防止了野指標的報錯
void
weak_clear_no_lock(weak_table_t *weak_table, id referent_id)
{
✅//獲取被弱引用物件的地址
objc_object *referent = (objc_object *)referent_id;
✅// 根據物件地址找到被弱引用物件referent在weak_table中對應的weak_entry_t
weak_entry_t *entry = weak_entry_for_referent(weak_table, referent);
if (entry == nil) {
/// XXX shouldn't happen, but does with mismatched CF/objc
//printf("XXX no entry for clear deallocating %p\n", referent);
return;
}
// zero out references
weak_referrer_t *referrers;
size_t count;
✅// 找出弱引用該物件的所有weak指標地址陣列
if (entry->out_of_line()) {
referrers = entry->referrers;
count = TABLE_SIZE(entry);
}
else {
referrers = entry->inline_referrers;
count = WEAK_INLINE_COUNT;
}
✅// 遍歷取出每個weak指標的地址
for (size_t i = 0; i < count; ++i) {
objc_object **referrer = referrers[i];
if (referrer) {
✅// 如果weak指標確實弱引用了物件 referent，則將weak指標設定為nil
if (*referrer == referent) {
*referrer = nil;
}
✅// 如果所儲存的weak指標沒有弱引用物件 referent，這可能是由於runtime程式碼的邏輯錯誤引起的，報錯
else if (*referrer) {
_objc_inform("__weak variable at %p holds %p instead of %p. "
"This is probably incorrect use of "
"objc_storeWeak() and objc_loadWeak(). "
"Break on objc_weak_error to debug.\n",
referrer, (void*)*referrer, (void*)referent);
objc_weak_error();
}
}
}
weak_entry_remove(weak_table, entry);
}
複製程式碼至此，一個弱引用的銷燬也完成了，並自動置為nil
總結
- 當一個物件obj被weak指標指向時，這個weak指標會以obj作為key，被儲存到
sideTable類的weak_table這個雜湊表上對應的一個weak指標陣列裡面。 - 當一個物件obj的
dealloc方法被呼叫時，Runtime會以obj為key，從sideTable的weak_table雜湊表中，找出對應的weak指標列表，然後將裡面的weak指標逐個置為nil。
建立流程簡圖
建立流程小結：
Runtime維護了一個弱引用表，將所有弱引用obj的指標地址都儲存在obj對應的weak_entry_t中。
- 建立時，先從找到全域性雜湊表
SideTables中對應的弱引用表weak_table - 在
weak_table中被弱引用物件的referent,並建立或者插入對應的weak_entry_t - 然後
append_referrer(entry, referrer)將我的新弱引⽤的物件加進去entry - 最後
weak_entry_insert把entry加⼊到我們的weak_table
銷燬流程簡圖
銷燬流程小結：
- 首先根據物件地址獲取所有weak指標地址的陣列
- 然後遍歷這個陣列把對應的資料清空置為
nil - 同時，將
weak_entry_t移除出弱引用表weak_table。