背景
关于自动释放池，这个在第一次写iOS程序的时候，就能看到main.m中有@autoreleasepool字样。所以它到底是干什么的，内部结构怎样，又是通过什么机制释放的？这是这篇文章主要解答的几个问题。
1. autoreleasepool内部结构
将mian.m文件编译为C++代码时候，可以看到起内部的实现是借助__AtAutoreleasePool进行实现，内部结构是AutoreleasePoolPage，如下源码所示：
/*@autoreleasepool */ { __AtAutoreleasePool __autoreleasepool;
return UIApplicationMain(argc, argv, __null, NSStringFromClass(((Class (*)(id, SEL))(void *)objc_msgSend)((id)objc_getClass("AppDelegate"), sel_registerName("class"))));
}
// -----
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;
};
从上述源码中，可以看到__AtAutoreleasePool的构造函数，调用的是内部objc_autoreleasePoolPush、objc_autoreleasePoolPop方法，从上述extern可知，可以从源码中查看其内部实现情况：
void *
objc_autoreleasePoolPush(void)
{
return AutoreleasePoolPage::push();
}
void
objc_autoreleasePoolPop(void *ctxt)
{
AutoreleasePoolPage::pop(ctxt);
}
查看相应的类结构如下（精简后）：
class AutoreleasePoolPage
{
magic_t const magic;
id *next;
pthread_t const thread;
AutoreleasePoolPage * const parent;
AutoreleasePoolPage *child;
uint32_t const depth;
uint32_t hiwat;
}
从上述结构可以得出一下几个直观的结论：
- 一个AutoreleasePoolPage对象，对应一个thread；
- 从parent和child的类型知，AutoreleasePoolPage是一个双向链表；
- 表中的下一成员由next指针指向等。
通过在main.m中@autoreleasepool处添加断点，查看其内部汇编代码如下图1.1所示：
从上图1.1中可以查看代码下一步执行的代码是：调用地址0x10d2718d2处的指令，内部进行一系列的push和jmp指令操作，即图1.1中的注释：
objc_autoreleasePoolPush的操作；从图1.1 中的35行，也可以看出，还有一个相对应的objc_autoreleasePoolPop与之对应。感兴趣的可以查看源代码进行分析一下具体的流程。
在测试类中，添加如下的测试代码：
NSAutoreleasePool *pool1 = [[NSAutoreleasePool alloc] init];
Person *per1 = [[[Person alloc] init] autorelease];
NSLog(@"11111111111-%p", per1);
_objc_autoreleasePoolPrint();
[pool1 drain];
在代码中将_objc_autoreleasePoolPrint();声明为外部调用的函数，即可以借助该函数可以查看其内部的存储在AutoreleasePoolPage中的情况。该函数是源码内部中的日志函数。结果如下所示（精简之后）：
//objc[21609]: [0x7fea5d046d40] ################ POOL 0x7fea5d046d40
//objc[21609]: [0x7fea5d046d48] 0x604000009a90 Person
//objc[21609]: ##############
从其中可以看出，当调用autorelease方法时，内部是将该对象的地址存储在page中的。当表释放后，该对象从表中移除。那么该表是何时释放的呢？这是之后需要讨论的问题。
2. autoreleasepool中的对象何时释放
2.1 主线程
通过在主线程中打印当前runloop中的对象，可以看到如下的情况：
observers = (
"<CFRunLoopObserver 0x60000013eaa0 [0x1111c4bb0]>{valid = Yes, activities = 0x1, repeats = Yes, order = -2147483647, callout = _wrapRunLoopWithAutoreleasePoolHandler (0x111373276), context = <CFArray 0x600000440f90 [0x1111c4bb0]>{type = mutable-small, count = 1, values = (\n\t0 : <0x7fa794002048>\n)}}",
"<CFRunLoopObserver 0x60400013e320 [0x1111c4bb0]>{valid = Yes, activities = 0x20, repeats = Yes, order = 0, callout = _UIGestureRecognizerUpdateObserver (0x1119611a9), context = <CFRunLoopObserver context 0x6040000c32c0>}",
"<CFRunLoopObserver 0x60000013eb40 [0x1111c4bb0]>{valid = Yes, activities = 0xa0, repeats = Yes, order = 1999000, callout = _beforeCACommitHandler (0x1113a2fdc), context = <CFRunLoopObserver context 0x7fa793701f00>}",
"<CFRunLoopObserver 0x60400013e8c0 [0x1111c4bb0]>{valid = Yes, activities = 0xa0, repeats = Yes, order = 2000000, callout = _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv (0x116d1d648), context = <CFRunLoopObserver context 0x0>}",
"<CFRunLoopObserver 0x60000013ea00 [0x1111c4bb0]>{valid = Yes, activities = 0xa0, repeats = Yes, order = 2001000, callout = _afterCACommitHandler (0x1113a3057), context = <CFRunLoopObserver context 0x7fa793701f00>}",
"<CFRunLoopObserver 0x60000013e960 [0x1111c4bb0]>{valid = Yes, activities = 0xa0, repeats = Yes, order = 2147483647, callout = _wrapRunLoopWithAutoreleasePoolHandler (0x111373276), context = <CFArray 0x600000440f90 [0x1111c4bb0]>{type = mutable-small, count = 1, values = (\n\t0 : <0x7fa794002048>\n)}}"
),
在日志中，搜索autoreleasepool字样，可以看到主线程runloop中的observer在监听到activities = 0x1, 0xa0状态时，会调用：callout = _wrapRunLoopWithAutoreleasePoolHandler。
/* Run Loop Observer Activities */
typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
kCFRunLoopEntry = (1UL << 0),
kCFRunLoopBeforeTimers = (1UL << 1),
kCFRunLoopBeforeSources = (1UL << 2),
kCFRunLoopBeforeWaiting = (1UL << 5),
kCFRunLoopAfterWaiting = (1UL << 6),
kCFRunLoopExit = (1UL << 7),
kCFRunLoopAllActivities = 0x0FFFFFFFU
};
其中0x1, 0xa0对应着三种状态：进入kCFRunLoopEntry, kCFRunLoopBeforeWaiting和kCFRunLoopExit三种状态。通过上述的断点就可以查看，对象的真正释放是在runloop的kCFRunLoopBeforeWaiting和kCFRunLoopExit两种状态进行操作的。而关于具体的细节，到底是如何进行释放的，可以进行查看相应的源码进行自主分析。
这是主线程有runloop的情况。此时会立刻想到，子线程的runloop在没有手动开启时，又是通过什么机制进行操作的呢？
2.2 子线程
可以简单的通过如下代码开启一个子线程执行相应的操作：
[[[NSThread alloc] initWithTarget:self selector:@selector(testThreadRelease) object:nil] start];
- (void)testThreadRelease
{
@autoreleasepool {
Person *per1 = [[Person alloc] init];
NSLog(@"11111111111-%p", per1);
_objc_autoreleasePoolPrint();
}
NSLog(@"%s", __func__);
}
通过在@autoreleasepool处打断点，查看汇编代码进行单步调试，可以来到autoreleaseNewPage，接着是：autoreleaseNoPage，关键代码就在该函数中（精简之后）：
static __attribute__((noinline))
id *autoreleaseNoPage(id obj)
{
// Install the first page.
AutoreleasePoolPage *page = new AutoreleasePoolPage(nil);
setHotPage(page);
// Push a boundary on behalf of the previously-placeholder'd pool.
if (pushExtraBoundary) {
page->add(POOL_BOUNDARY);
}
// Push the requested object or pool.
return page->add(obj);
}
可以看到，是重新新建了一个AutoreleasePoolPage作为当前活跃的页表结构，进而将该page进行类似入栈的操作。
从上述代码执行的捕捉过程来看，子线程中对象借助自动释放池进行释放的时机是和runloop无关的。
- demo基本在例子中有详细的说明，因此如果有谁需要代码，可以发我邮件。
- 在阅读中，如果发现文章有不合理的地方，欢迎提出疑问至邮箱:B12050217@163.com.
- 原创文章，转载请注明：转自：Try_Try_Try
- OK, game over.
好了，以上内容就是简单的探索过程。
参考的文章有：
《iOS与OS+X多线程和内存管理》
