概念的陈述

autoReleasepool是我们iOS开发项目中及其重要的一个内存管理机制，自从我们是用ARC后，我们再也不用开启一个内容分配给某个对象，我们只管做我们开发应该做的事情，内存的分配和释放都交给autoReleasepool去处理，这样既方便也省事，所以autoReleasepool的概念就不多叙述了，自动内存释放池，相信只要做iOS开发的都能明白其作用的重要性。

AutoReleasepool的内部结构

 magic_t const magic;                      magic_t const magic; 
  id *next;                                 id *next;  
 .....                                      NSString *string49;
 NSString *...;                             NSString *string50;
 NSString *...;                             pthread_t const thread;
 NSString *string3;                         ......       
 NSString *string2;                         ......
 NSString *string1;
  pthread_t const thread;
  AutoreleasePoolPage * const 
  AutoreleasePoolPage *child;
  uint32_t const depth;
  uint32_t hiwat;
  PAGE_MAX_SIZE;
  COUNT;
  POOL_BOUNDARY;

  Page 1   //第一页                               page2//第二页           ...

1,AutoreleasePool并没有单独的结构，而是由若干个AutoreleasePoolPage以双向链表的形式组成
2,AutoreleasePoolPage每个对象会开辟4096字节内存（也就是虚拟内存一页的大小），除了上面的实例变量所占空间，剩下的空间全部用来储存autorelease对象的地址

Runloop与AutoReleasepool的关系

  NSLog(@"相关的关系 %@",[NSRunLoop currentRunLoop]);

当我们在程序中用日志打印相关数据的时候，显示的日志是

2020-07-30 10:38:49.003092+0800 VVeboTableViewDemo[1522:62613] 相关的关系 <CFRunLoop 0x600001ce0300 [0x7fff8062d750]>{wakeup port = 0x1903, stopped = false, ignoreWakeUps = false, 
current mode = kCFRunLoopDefaultMode,
common modes = <CFBasicHash 0x600002eba1f0 [0x7fff8062d750]>{type = mutable set, count = 2,
entries =>
    0 : <CFString 0x7fff869c52a0 [0x7fff8062d750]>{contents = "UITrackingRunLoopMode"}
    2 : <CFString 0x7fff80640a20 [0x7fff8062d750]>{contents = "kCFRunLoopDefaultMode"}
}
,
common mode items = <CFBasicHash 0x600002eba370 [0x7fff8062d750]>{type = mutable set, count = 11,
entries =>
    0 : <CFRunLoopSource 0x6000015e8000 [0x7fff8062d750]>{signalled = No, valid = Yes, order = -1, context = <CFRunLoopSource context>{version = 0, info = 0x0, callout = PurpleEventSignalCallback (0x7fff38c3a9b2)}}
    1 : <CFRunLoopSource 0x6000015f00c0 [0x7fff8062d750]>{signalled = No, valid = Yes, order = -1, context = <CFRunLoopSource context>{version = 1, info = 0x2e03, callout = PurpleEventCallback (0x7fff38c3a9be)}}
    2 : <CFRunLoopSource 0x6000015fc000 [0x7fff8062d750]>{si

但是相关控制台打印的数据是

0 : <CFRunLoopSource 0x6000015e8000 [0x7fff8062d750]>{signalled = No, valid = Yes, order = -1, context = <CFRunLoopSource context>{version = 0, info = 0x0, callout = PurpleEventSignalCallback (0x7fff38c3a9b2)}}
    1 : <CFRunLoopSource 0x6000015f00c0 [0x7fff8062d750]>{signalled = No, valid = Yes, order = -1, context = <CFRunLoopSource context>{version = 1, info = 0x2e03, callout = PurpleEventCallback (0x7fff38c3a9be)}}
    2 : <CFRunLoopSource 0x6000015fc000 [0x7fff8062d750]>{signalled = No, valid = Yes, order = -1, context = <CFRunLoopSource context>{version = 0, info = 0x600001bf84e0, callout = __handleEventQueue (0x7fff493c2e6e)}}
    3 : <CFRunLoopObserver 0x6000011fc1e0 [0x7fff8062d750]>{valid = Yes, activities = 0xa0, repeats = Yes, order = 2147483647, callout = _wrapRunLoopWithAutoreleasePoolHandler (0x7fff4931eaa4), context = <CFArray 0x600002edf570 [0x7fff8062d750]>{type = mutable-small, count = 1, values = (
    0 : <0x7fbfa580d048>
)}}
    4 : <CFRunLoopObserver 0x6000011fc000 [0x7fff8062d750]>{valid = Yes, activities = 0xa0, repeats = Yes, order = 1999000, callout = _beforeCACommitHandler (0x7fff4934fa4f), context = <CFRunLoopObserver context 0x7fbfa4c052c0>}
    5 : <CFRunLoopObserver 0x6000011f80a0 [0x7fff8062d750]>{valid = Yes, activities = 0x20, repeats = Yes, order = 0, callout = _UIGestureRecognizerUpdateObserver (0x7fff48eaa99e), context = <CFRunLoopObserver context 0x600000bf8e00>}
    6 : <CFRunLoopSource 0x6000015fc0c0 [0x7fff8062d750]>{signalled = No, valid = Yes, order = -2, context = <CFRunLoopSource context>{version = 0, info = 0x600002ea8db0, callout = __handleHIDEventFetcherDrain (0x7fff493c2edd)}}
    7 : <CFRunLoopSource 0x6000015e0000 [0x7fff8062d750]>{signalled = Yes, valid = Yes, order = 0, context = <CFRunLoopSource context>{version = 0, info = 0x6000004e0540, callout = FBSSerialQueueRunLoopSourceHandler (0x7fff36d82bd5)}}
    8 : <CFRunLoopObserver 0x6000011fc0a0 [0x7fff8062d750]>{valid = Yes, activities = 0xa0, repeats = Yes, order = 2001000, callout = _afterCACommitHandler (0x7fff4934fab8), context = <CFRunLoopObserver context 0x7fbfa4c052c0>}
    9 : <CFRunLoopObserver 0x6000011ec320 [0x7fff8062d750]>{valid = Yes, activities = 0xa0, repeats = Yes, order = 2000000, callout = _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv (0x7fff2b477daa), context = <CFRunLoopObserver context 0x0>}
    12 : <CFRunLoopObserver 0x6000011fc140 [0x7fff8062d750]>{valid = Yes, activities = 0x1, repeats = Yes, order = -2147483647, callout = _wrapRunLoopWithAutoreleasePoolHandler (0x7fff4931eaa4), context = <CFArray 0x600002edf570 [0x7fff8062d750]>{type = mutable-small, count = 1, values = (
    0 : <0x7fbfa580d048>
)}}

第一个监听的是activities 是 NSRunLoopEntry状态，说明当runloop进入entry状态的时候，会调用_wrapRunLoopWithAutoreleasePoolHandler
，其内部会调用_objc_autoreleasePoolPush()创建自动释放池。
第二个监听的activities是 NSRunLoopBeforeWaiting 和NSRunLoopExit，BeforeWaiting 其回调方法_wrapRunLoopWithAutoreleasePoolHandler内部会调用先调用pop操作，然后再push 创建一个新的自动释放池。Exit会调用pop操作。

autoreleasepool的执行顺序就是Entry-->push ---> BeforeWaiting--->pop-->push -->Exit-->pop，按照这样的顺便，保证了，每一次push都对应一个pop。autoreleasepool释放操作在每一次runloop 的BeforeWaiting和exit的时候执行的

AutoreleasePool并没有单独的结构，而是由若干个AutoreleasePoolPage以双向链表的形式组合而成（分别对应结构中的parent指针和child指针）
AutoreleasePool是按线程一一对应的（结构中的thread指针指向当前线程）
AutoreleasePoolPage每个对象会开辟4096字节内存（也就是虚拟内存一页的大小），除了上面的实例变量所占空间，剩下的空间全部用来储存autorelease对象的地址
上面的id *next指针作为游标指向栈顶最新add进来的autorelease对象的下一个位置
一个AutoreleasePoolPage的空间被占满时，会新建一个AutoreleasePoolPage对象，连接链表，后来的autorelease对象在新的page加入
所以，若当前线程中只有一个AutoreleasePoolPage对象，并记录了很多autorelease对象地址时内存如下图：

图中的情况，这一页再加入一个autorelease对象就要满了（也就是next指针马上指向栈顶），这时就要执行上面说的操作，建立下一页page对象，与这一页链表连接完成后，新page的next指针被初始化在栈底（begin的位置），然后继续向栈顶添加新对象。

所以，向一个对象发送- autorelease消息，就是将这个对象加入到当前AutoreleasePoolPage的栈顶next指针指向的位置。

所以runloop 和AutoReleasepool是通过线程的方式一一对应的

什么情况下需要创建自动释放池？

其实自动释放池存在的意义是为了延迟释放一些对象，延迟向对象发送release消息。在实际的开发中，有两种情况是需要手动创建自动释放池的。

1、在多线程中，因为子线程中可能会使用便利构造器等方法来创建对象（类方法），那么这些对象的释放只能放在自动释放池中，此时需要在子线程中添加自动释放池。

使用便利构造器等方法来创建对象是autorelease的对象，需要制动释放池才能释放

主线程已经添加过自动释放池，在main函数里面。

2、就是如果一段代码里面（比如for循环）大量使用便利构造器创建对象，也需要手动添加自动释放池。

什么是便利构造器？

便利构造器在初始化方法的基础上前进了一⼩小步。封装了对象创建过程。

便利构造器是“+”方法,返回本类型的实例,方法名以类名开头，其实一些类中的静态方法也是便利构造器。

可以有0到多个参数。内部实现:封装了alloc和初始化方法。使用起来更加简洁。

runloop和 autorelease pool

先提出一个问题，在Iphone项目中，大家会看到一个默认的Autorelease pool，程序开始时创建，程序退出时销毁，按照对Autorelease的理解，岂不是所有autorelease pool里的对象在程序退出时才release，这样跟内存泄露有什么区别？结果是，对于每一个Runloop，系统会隐式创建一个Autorelease pool，这样所有的release pool会构成一个象CallStack一样的一个栈式结构，在每一个Runloop结束时，当前栈顶的Autorelease pool会被销毁，这样这个pool里的每个Object会被release。

那什么是一个runloop？一个UI事件，一个timer，一个系统delegate都称之为runloop(不是NSRunloop)，runloop实际上是从接收消息，然后处理完消息的一个完整过程。

为了更加形象说明auto release pool机制，下面举例：

NSString＊ str1是assign。

UI事件：UIButton的target－action机制，在action中创建一个autorelease的UILabel对象，并赋值，在action中打印出值，action执行完毕，这个时候runloop结束，autorelease pool被释放，label也被释放，所以再调用这个对象的值时，出现bad_exec_access。

RunLoop与AutoReleasepool的关系学习