MRC与ARC再回顾
在前面,我们简单学了MRC与ARC。MRC指手动内存管理,需要开发者使用retain
、release
等手动管理对象的引用计数,确保对象在必要时被释放。ARC指自动内存管理,由编译器自动管理对象的引用计数,开发者不需要手动管理内存。
哪些对象需要我们进行内存管理呢?
- 任何继承了NSObject的对象需要进行内存管理
- 而其他非对象类型(int、char、float、double、struct、enum等) 不需要进行内存管理
这是因为
- 继承了NSObject的对象的存储在操作系统的堆里边。而操作系统的堆一般由程序员分配释放。
- 非OC对象一般放在操作系统的栈里面,操作系统的栈由操作系统自动分配释放。
例:
int main(int argc, const char * argv[])
{@autoreleasepool {int a = 10; // 栈int b = 20; // 栈// Person对象(计数器==1) : 堆Person *p = [[Person alloc] init];// p(局部指针变量): 栈}// 经过上面代码后, 栈里面的变量a、b、p 都会被回收// 但是堆里面的Person对象还会留在内存中,因为它是计数器依然是1return 0;
}
MRC深入
首先,先回顾空指针和野指针;
空指针、野指针
空指针:
空指针指的是没有指向存储空间的指针(里面存的是 nil, 也就是 0)。
给空指针发消息是没有任何反应的,也不会报错
空指针比如:
NSObject *a = [[NSObject alloc] init]; //执行完引用计数为1
[a release]; //执行完引用计数为 0,实例对象被释放。
a = nil; //此时,a变为了空指针。
[a release]; // 再给空指针a发送消息就不会报错了。
[a release]; // 这段代码不会报错
野指针:
只要一个对象被释放了,我们就称这个对象为“僵尸对象(不能再使用的对象)”。
当一个指针指向一个僵尸对象,我们就称这个指针为「野指针」。
只要给一个野指针发送消息就会报错(EXC_BAD_ACCESS 错误)。
MRC避免循环引用
定义两个了类Person和Dog
Person类:
#import <Foundation/Foundation.h>
NS_ASSUME_NONNULL_BEGIN
@class Dog;
@interface Person : NSObject
@property (nonatomic, assign) Dog *dog;
@endNS_ASSUME_NONNULL_END
Dog类:
#import <Foundation/Foundation.h>
NS_ASSUME_NONNULL_BEGIN
@class Person;
@interface Dog : NSObject
@property (nonatomic, retain) Person *person;
@endNS_ASSUME_NONNULL_END
主函数:
Person *p = [[Person alloc] init];
Dog *d = [[Dog alloc] init];p.dog = d;
d.person = p;[p release];
[d release];
我们看上面的代码,会出现 A 对象要拥有 B 对象,而 B 对应又要拥有 A 对象,此时会形成循环 retain,导致 A 对象和 B 对象永远无法释放。
要解决这个问题的话:不要让 A retain B,B retain A,所以其中一方不要做retain方法。当两端互相引用时,应该一端用 retain,一端用 assign。
ARC深入
在之前的博客里,已经学习了ARC许多知识,包括修饰符、规则、属性和简单实现。可以看我的博客:iOS——【自动引用计数】ARC规则及实现
现在我们更深入的了解它的实现。
在Objective C中,有三种类型是ARC适用的:
1. block
2. objective 对象,id, Class, NSError*等
3. 由attribute((NSObject))标记的类型。
*像double ,CFStringRef等不是ARC适用的,仍然需要手动管理内存。
Tips: 以CF开头的(Core Foundation)的对象往往需要手动管理内存。
ARC在编译期和运行期分别做了什么?
先说结论:
1. 在编译期,ARC会把互相抵消的retain、release、autorelease操作约简。
2. ARC包含有运行期组件,可以在运行期检测到autorelease和retain这一对多余的操作。为了优化代码,在方法中返回自动释放的对象时,要执行一个特殊函数。
接下来我们来探究这个结论:
ARC的实现
ARC的底层是怎么工作的
首先根据前面的学习,我们知道,ARC有一套命名规则:若方法名以alloc、new、copy、mutableCopy开头,则方法的调用者需要负责保留和释放使用该方法返回的对象,在MRC中,就需要我们手动保留和释放返回的对象。如果不以上面这些开头,则不用调用者保留和释放,因为方法内部会自动执行autorelease方法。
下面用实例说明:
实例1
首先,我们创建一个Person类,这个类有两个类方法,一个是用creat开头的,一个是用new开头的,现在调用这两个方法:
#import "Person.h"@implementation Person+ (instancetype)creatPerson {return [[self alloc] init];
}
+ (instancetype)newPerson {return [[self alloc] init];
}@end
#import <Foundation/Foundation.h>
#import "Person.h"int main(int argc, const char * argv[]) {[Person creatPerson];[Person newPerson];
}
接下来我们查看它的汇编代码:
可以看见,在newPerson
方法下,首先用objc_megSend
向newPerson
发送消息,然后有一个objc_release
的标志位,这个标志位意味着系统在这个位置会调用objc_release
函数。
而在creatPerson
方法下,creatPerson中ARC修改后的代码大致逻辑是:
//Person.m
+ (instancetype)creatPerson {id temp = [self new]; return objc_autoreleaseReturnValue(temp);
}
//main.m
- (void)testForARC { objc_unsafeClaimAutoreleasedReturnValue([Person creatPerson]);
}
在create中多了objc_autoreleaseReturnValue,这是因为ARC规则,无需手动释放的内部自动autorelease。
objc_autoreleaseReturnValue: 这个函数的作用相当于代替我们手动调用 autorelease, 创建了一个autorelease对象。编译器会检测之后的代码, 根据返回的对象是否执行 retain操作, 来设置全局数据结构中的一个标志位, 来决定是否会执行 autorelease操作。该标记有两个状态, ReturnAtPlus0代表执行 autorelease, 以及ReturnAtPlus1代表不执行 autorelease。
objc_unsafeClaimAutoreleasedReturnValue
函数作用是对autorelease对象不做处理仅仅返回,对非autorelease对象调用objc_release函数并返回。所以本情景中它创建时执行了 autorelease操作了,就不会对其进行 release操作了。只是返回了对象,在合适的实际autoreleasepool会对其进行释放的。
实例2
我们再给出下面的例子:
id temp2 = [Person newPerson];
查看汇编代码:
可以看出来,与前面不同的是多了一个objc_storeStrong
的标志位。因此可知,编译器在这里调用了该函数。我们在objc库里看看这个函数的实现。在objc4的NSObject.mm中:
void
objc_storeStrong(id *location, id obj)
{id prev = *location;if (obj == prev) {return;}objc_retain(obj);*location = obj;objc_release(prev);
}
说一下这个函数:objc_storeStrong
函数是用于管理强引用的一个函数,主要用于更新一个指向对象的强引用,并确保正确的内存管理。
在上面这段代码里:首先获取旧对象的引用(prev)。然后进行比较,如果新对象和旧对象相同,则返回。否则,保留新对象,并将新对象的引用+1。然后更新指针*location,指向新对象。最后释放旧对象。使用这个函数是因为:temp2是一个强引用变量。编译器会将上述代码转换为类似以下内容:
id newObject = [Person newPerson];
objc_storeStrong(&temp2, newObject);
而同样的,在creatPerson
方法中:
id temp1 = [Person creatPerson];
它的汇编代码:
这里同样使用了objc_storeStrong
函数,但是多了一个objc_retainAutoreleasedReturnValue
函数,这个函数将替代 MRC中的 retain方法, 此函数也会检测刚才提到的那个标志位, 如果为ReturnAtPlus0执行该对象的 retain操作,否则直接返回对象本身。
在这个例子中, 由于代码中没有对对象进行保留, 所以创建时objc_autoreleaseReturnValue
函数设置的标志位状态是应该是ReturnAtPlus0。所以, 该函数在此处是会进行 retain操作的。
实例3
有如下代码:
#import "strat.h"
#import "Person.h"@interface strat ()@property (nonatomic, strong) id temp1;
@property (nonatomic, strong) id temp2;@end@implementation strat- (void)gogo {self.temp1 = [Person creatPerson];self.temp2 = [Person newPerson];
}@end
我们先看temp2的汇编代码:
可以看出,这段代码相比于实例2的代码,多了一个megSend:objc_msgSend$setTemp2
,这个是setter方法的函数,所以其实这里相当于多了一个setter操作。因此这里ARC的补充的代码大概是:
- (void)setTemp2:(id)newValue {objc_storeStrong(&_temp2, newValue);
}
temp1与temp2被补充的部分差不多。
自动释放池
自动释放池(autorelease)是 Objective-C 内存管理的重要特性之一。
简单来说它允许开发者推迟对象的释放时间,通常在下一个事件循环中才执行释放操作。
自动释放池之前在博客 中学习过,现在来深入学习一下。
MRC下的自动释放池
在MRC下使用自动释放池是通过NSAutoreleasePool实现的(如果编译器版本是LLVM.3.0以上,那么@autorelease{…}也可以使用),其生命周期相当于c语言变量的作用域。对于所有调用过 autorelease方法的对象,在废弃 NSAutoreleasePool对象时,都将调用 release实例方法。
int main(int argc, const char * argv[]) {@autoreleasepool {//创建并使pool持有一个自动释放池NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];//创建Person实例对象pPerson *p = [[Person alloc] init];//将实例对象p加入pool持有的自动释放池[p autorelease];//废弃NSAutoreleasePool对象;//并向pool池中的所有对象发送消息,让它们调用release方法。这里相当于也[p release]了[pool drain];//这里会报错,因为p已被释放NSLog(@"%@", p);}return 0;
}
报错内容:Thread 1: EXC_BAD_ACCESS (code=1, address=0x370001a2b46808)
这里我当时有一个问题:当调用[p autorelease]的时候,是怎么判断当前的自动释放池是pool持有的那个的?
这是因为:运行时系统维护了一个全局的栈来跟踪所有的自动释放池。当一个新的 NSAutoreleasePool 对象被创建时,它会被推入栈顶。随后,当调用 -autorelease 方法时,当前的栈顶的自动释放池会接收该对象。
理解 NSAutoreleasePool对象的生命周期,如下图所示:
ARC下使用自动释放池
ARC环境不能使用 NSAutoreleasePool
类也不能调用autorelease
方法,代替它们实现对象自动释放的是 @autoreleasepool
块和__autoreleasing
修饰符。比较两种环境下的代码差异如下图:
ARC环境下使用自动释放池:
@autoreleasepool {id obj = [[NSObject alloc] init];NSLog(@"%@", obj);
}
ARC的很多情况下,即使是不显式的使用 __autoreleasing,也能实现对象被注册到释放池中。主要包括以下几种情况:
编译器会进行优化,检查方法名是否以 alloc/new/copy/mutableCopy开始,如果不是则自动将返回对象注册到 Autoreleasepool;
访问附有 __weak修饰符的变量时,实际上必定要访问注册到 Autoreleasepool的对象,即会自动加入 Autoreleasepool;
id的指针或对象的指针(id*,NSError **),在没有显式地指定修饰符时候,会被默认附加上 __autoreleasing修饰符,加入 Autoreleasepool。
AutoreleasePool的具体实现
有以下自动释放池的代码:
int main(int argc, const char * argv[]) {@autoreleasepool {NSLog(@"hello");}return 0;
}
将其转化为cpp代码:
int main(int argc, const char * argv[]) {/* @autoreleasepool */ { __AtAutoreleasePool __autoreleasepool; NSLog((NSString *)&__NSConstantStringImpl__var_folders_mr_nr_xs_2x079d0zxp68ymmm4c0000gn_T_main_82a790_mi_0);}return 0;
}
可以发现,自动释放池在底层中对应的是一个__AtAutoreleasePool的结构体,我们再在源码中可以找到这个结构体的定义:
extern "C" __declspec(dllimport) void * objc_autoreleasePoolPush(void);
extern "C" __declspec(dllimport) void objc_autoreleasePoolPop(void *);struct __AtAutoreleasePool {__AtAutoreleasePool() {atautoreleasepoolobj = objc_autoreleasePoolPush();}~__AtAutoreleasePool() {objc_autoreleasePoolPop(atautoreleasepoolobj);}// 边界对象(指针),用来标识自动释放池的开始和结束。这个对象在创建和销毁自动释放池时分别被推入和弹出。void * atautoreleasepoolobj;
};
可以看见,在这个结构体中有一个构造函数内部调用objc_autoreleasePoolPush()
,和一个析构函数内部调用objc_autoreleasePoolPop(atautoreleasepoolobj)
,以及一个atautoreleasepoolobj
边界对象。
objc_autoreleasePoolPush()
用于返回边界对象objc_autoreleasePoolPop(atautoreleasepoolobj)
用于传入边界对象
边界对象其实就是 nil的别名,而它的作用事实上也就是为了起到一个标识的作用。
AutoreleasePoolPage
我们继续深入对objc_autoreleasePoolPush()
和objc_autoreleasePoolPop(atautoreleasepoolobj)
进行学习,发现它们实际上是对AutoreleasePoolPage对应的静态方法 push和 pop的封装。
在NSObject的源码中可以发现以下代码:
void *
objc_autoreleasePoolPush(void)
{return AutoreleasePoolPage::push();
}NEVER_INLINE
void
objc_autoreleasePoolPop(void *ctxt)
{AutoreleasePoolPage::pop(ctxt);
}
AutoreleasePoolPage是C++的一个类,在NSObject.mm中可以找到它的代码,这是它的一部分核心代码:
class AutoreleasePoolPage {
# define EMPTY_POOL_PLACEHOLDER ((id*)1) //空池占位
# define POOL_BOUNDARY nil //边界对象(即哨兵对象)static pthread_key_t const key = AUTORELEASE_POOL_KEY;static uint8_t const SCRIBBLE = 0xA3; // 0xA3A3A3A3 after releasingstatic size_t const SIZE =
#if PROTECT_AUTORELEASEPOOLPAGE_MAX_SIZE; // must be multiple of vm page size
#elsePAGE_MAX_SIZE; // size and alignment, power of 2
#endifstatic size_t const COUNT = SIZE / sizeof(id);magic_t const magic; //校验AutoreleasePagePoolPage结构是否完整id *next; //指向新加入的autorelease对象的下一个位置,初始化时指向begin()pthread_t const thread; //当前所在线程,AutoreleasePool是和线程一一对应的AutoreleasePoolPage * const parent; //指向父节点page,第一个结点的parent值为nilAutoreleasePoolPage *child; //指向子节点page,最后一个结点的child值为niluint32_t const depth; //链表深度,节点个数uint32_t hiwat; //数据容纳的一个上限//......
};
每个自动释放池都是是由若干个 AutoreleasePoolPage组成的双向链表结构,如下图所示:
AutoreleasePoolPage中拥有 parent和 child指针,分别指向上一个和下一个 page;当前一个 page的空间被占满(每个 AutorelePoolPage的大小为4096字节)时,就会新建一个 AutorelePoolPage对象并连接到链表中,后来的 Autorelease对象也会添加到新的 page中;
另外,当 next==begin()时,表示 AutoreleasePoolPage为空;
当 next ==end(),表示 AutoreleasePoolPage已满。
AutoreleasePool子线程上的释放时机
子线程默认不开启 RunLoop,那么其中的延时对象该如何释放呢?其实这依然要从 Thread和 AutoreleasePool的关系来考虑:
Each thread (including the main thread) maintains its own stack of NSAutoreleasePool objects.
也就是说,每一个线程都会维护自己的 Autoreleasepool栈,所以子线程虽然默认没有开启 RunLoop,但是依然存在 AutoreleasePool,在子线程退出的时候会去释放 autorelease对象。
前面讲到过,ARC会根据一些情况进行优化,添加 __autoreleasing修饰符,其实这就相当于对需要延时释放的对象调用了 autorelease方法。从源码分析的角度来看,如果子线程中没有创建 AutoreleasePool ,而一旦产生了 Autorelease对象,就会调用 autoreleaseNoPage方法自动创建 hotpage,并将对象加入到其栈中。所以,一般情况下,子线程中即使我们不手动添加自动释放池,也不会产生内存泄漏。
weak修饰符补充
在前面的博客中,我们知道了weak指针的一个生命周期是objc_initWeak
函数到objc_destroyWeak
函数,但其实这两个函数中都引用了另一个runtime的函数storeWeak
,这个函数和我们刚刚见到的storeStrong
函数是对应的,现在我们到NSObject.mm中看看他们的源码:
id
objc_initWeak(id *location, id newObj)
{if (!newObj) {*location = nil;return nil;}return storeWeak<DontHaveOld, DoHaveNew, DoCrashIfDeallocating>(location, (objc_object*)newObj);
}void
objc_destroyWeak(id *location)
{(void)storeWeak<DoHaveOld, DontHaveNew, DontCrashIfDeallocating>(location, nil);
}
storeWeak:
static id
storeWeak(id *location, objc_object *newObj)
{ASSERT(haveOld || haveNew); // 断言必须有旧值或新值if (!haveNew) ASSERT(newObj == nil); // 如果没有新值,断言新对象为 nilClass previouslyInitializedClass = nil; // 之前初始化的类id oldObj; // 旧对象SideTable *oldTable; // 旧对象的 SideTableSideTable *newTable; // 新对象的 SideTable// 获取旧值和新值的锁。按锁地址排序以防止锁排序问题。// 如果旧值在操作过程中发生变化,重试。retry:if (haveOld) {oldObj = *location; // 获取旧对象oldTable = &SideTables()[oldObj]; // 获取旧对象的 SideTable} else {oldTable = nil; // 没有旧值}if (haveNew) {newTable = &SideTables()[newObj]; // 获取新对象的 SideTable} else {newTable = nil; // 没有新值}SideTable::lockTwo<haveOld, haveNew>(oldTable, newTable); // 获取旧值和新值的锁if (haveOld && *location != oldObj) {SideTable::unlockTwo<haveOld, haveNew>(oldTable, newTable); // 如果旧值在操作过程中发生变化,解锁并重试goto retry;}// 为了防止弱引用机制与 +initialize 机制之间的死锁,确保没有弱引用的对象具有未初始化的 isa。if (haveNew && newObj) {Class cls = newObj->getIsa(); // 获取新对象的类if (cls != previouslyInitializedClass && !((objc_class *)cls)->isInitialized()) // 如果类未初始化{SideTable::unlockTwo<haveOld, haveNew>(oldTable, newTable); // 解锁class_initialize(cls, (id)newObj); // 初始化类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 ? CrashIfDeallocating : ReturnNilIfDeallocating); // 在弱引用表中登记新对象// weak_register_no_lock 如果弱存储应被拒绝,则返回 nil// 在引用计数表中设置 is-weakly-referenced 位。if (!_objc_isTaggedPointerOrNil(newObj)) {newObj->setWeaklyReferenced_nolock(); // 设置新对象为弱引用}// 不要在其他地方设置 *location。这会引入竞争条件。*location = (id)newObj; // 更新位置指针为新对象}else {// 没有新值。存储没有变化。}SideTable::unlockTwo<haveOld, haveNew>(oldTable, newTable); // 解锁旧值和新值的 SideTable// 这个操作必须在解锁后调用,因为它可能会调用任意代码。// 特别是,即使 _setWeaklyReferenced 没有实现,resolveInstanceMethod: 可能实现,并可能回调到弱引用机制。callSetWeaklyReferenced((id)newObj); // 调用设置弱引用的方法return (id)newObj; // 返回新对象
}
这段代码的主要思路是管理弱引用对象,首先获取旧对象和新对象并锁定相关表以防止多线程冲突,接着检查并确保新对象的类已初始化,然后从弱引用表中解除旧对象的登记,再将新对象登记到弱引用表并设置弱引用标志,最后解锁并调用设置弱引用的方法,从而安全地更新和管理弱引用对象。
弱引用表是Objective-C中用来管理和追踪弱引用对象的数据结构。在Objective-C的内存管理中,弱引用是一种不会增加对象引用计数的引用类型,这意味着当对象没有强引用时,弱引用不会阻止对象被释放。
弱引用表的主要作用包括三个方面:首先,它能够跟踪记录被弱引用的对象,并存储这些弱引用的位置;其次,当对象的所有强引用都被释放后,系统会自动将这些对象从弱引用表中移除,并将弱引用设置为nil,从而防止悬挂指针问题的发生;最后,通过弱引用表,可以有效地防止因循环引用而导致的内存泄漏,因为弱引用不会增加对象的引用计数,也不会导致对象无法释放。
ARC不会优化的场景。
ARC适用于绝大多数场景,但并不是万能的,例如performSelect系列有许多方法,带有选择子,编译器不知道选择子具体是什么,必须到了运行期才能确定,因此在编译时,不知道其方法名,没法利用ARC内存规则来判断是否释放。
如果这时我们使用selector(newTest)就会造成内存泄漏,因为ARC此时不会帮助我们添加release。