一、背景
K歌App在8月31号晚上收到了线上大量的用户反馈，应用使用中出现闪退。
收到反馈后，开发同学在TME的火眼APM平台上根据用户id进行搜索判断，是否有共性的Crash堆栈。将所用的用户都检索了后发现，并没有相关的堆栈信息。
没有堆栈又出现闪退，大概率是watchdog或者oom导致。考虑到K歌线上全量开启了MetricKit进行稳定性收集，如果是Watchdog，应该也能够在APM平台上看到。因此将线索定位在了OOM上。
捞取了反馈用户的客户端日志查看，果然能够在用户的日志中看到Memorywarning的打印。
因此，可以确定这次的闪退问题是内存OOM导致的。
![【iOS】一段防护代码引发的内存风暴]( "【iOS】一段防护代码引发的内存风暴")
在灯塔上报与K歌的APM的内存模块上查看内存模块的曲线，也可以看到相关的内存水位与内存警告上报有明显的上涨。
可以注意到，按照页面上报的数据，几乎所有的页面都出现了内存警告次数上涨的情况。
二、问题排查
反馈用户的版本集中在K歌的8.12.38版本上。该版本在线上运行了一个月时间。
现在出现有大量反馈，优先考虑引起的原因是配置下发变更或者前后端代码发布，影响了线上代码分支逻辑。
因此，在细化了内存水位与内存警告的数据后，对比前一天同时段数据进行查看，将怀疑时间集中在了30号的10-12点左右。
拉通各个团队的同学一起排查对应时间点的相关发布，发现在前一天的10点钟，有一个配置发布，在外网开启了针对数组越界的防护代码。
在回滚配置后观察，在上报报表上对比两天同时段的数据，发现内存水位和内存警告数都出现了回落与下降。
![【iOS】一段防护代码引发的内存风暴]( "【iOS】一段防护代码引发的内存风暴")
回滚当天的表现如下
![【iOS】一段防护代码引发的内存风暴]( "【iOS】一段防护代码引发的内存风暴")
因此确定是这个配置修改打开外网的防护开关引起的OOM问题。
三、问题定位
虽然通过回滚配置并对比外网数据，发现问题被解决了，但是具体原因还需要进行分析才能明确。
3.1防护源码
K歌在启动后，会读取后台配置，通过OC的Runtime，将Array相关接口进行hook，进行常见的防护判断。
对不可变数组NSArray，将以下3个方法进行swizzle进行保护。
initWithObjects:count:
objectAtIndex:
objectAtIndexedSubscript:
对可变的NSMutableArray，将这5个方法进行了swizzle替换。
objectAtIndex:
addObject:
removeObjectAtIndex:
replaceObjectAtIndex:withObject:
insertObject:atIndex:
以下是替换至业务层的防护代码实现:
上述的相关防护代码，主要是对业务层增加了参数合法性的前置校验判断，避免出现数组越界访问等会导致应用Crash的情况。
3.2问题复现
首先在本地直接开启相关配置后进行调试，利用Xcode和Instrument查看实时内存水位查看能否复现问题。
启动App并打开相关配置后，将App挂在K歌的直播歌房等场景中，运行一段时间后能观察到应用内存出现了上涨。
尤其是在动画&前后台切换等场景下，内存使用出现了上涨，且在退出相关场景后，内存没有出现对应的下降。
对比正常情况下的表现不一致。因此判断此时已经出现了内存泄露。
通过MemoryGraph，导出了两个对应时间下的内存快照对比。
左侧是使用App约40分钟后，App使用内存在1.55G，右侧则是使用60分钟，App内存增长到了1.83G的。
对比发现，主要是@autoreleasepool content对象，出现了大量增长，由左侧的13w个对象增长到20w个对象。
相关的内存占用从522M增长到了786M，增长了250M的内存空间。总共增长300M，占总增长的80%。
因此可以确定是@autoreleasepool content这个对象在某些场景下出现了内存泄露，不断累积，导致了OOM。
那么，为什么对数组的相关方法Hook后，会导致大量的@autoreleasepool content对象创建呢？且为什么这些对象都不会被释放？
通过Xcode的Malloc Stack Logging选项，可以查看这些@autoreleasepool content对象的创建堆栈。
我们发现@autoreleasepool content对象都集中在NSMutableArray 的 kscrash_objectAtIndex: 方法中被创建。
而这个方法正好是我们进行Hook防护的代码之一。因此基本可以确定是这个方法引入的问题。
四、原因分析
4.1 现象分析
@autoreleasepool content 对象就是我们常说的自动释放池，在系统底层映射的应该就是AutoreleasePoolPage 对象。
4.1.1调用堆栈观察
1. 先关注堆栈的倒数第4层调用，调用创建AutoreleasePoolPage的方法入口就是kscrash_objectAtIndex: 方法。我们可以逆向查看这个方法的二进制实现
可以看到由于对应的源码文件在业务层默认采用的是ARC方式编译。因此编译过程中，编译器会自动插入 autorelease 的调用。所以这个逻辑的最终实现，映射MRC模式下的实现应该是
- (id)kscrash_objectAtIndex:(NSUInteger)index { if (index < self.count) { return [[self kscrash_objectAtIndex:index] autorelease]; } else { return nil; }}
这里可以解释为什么这个方法会与AutoreleasePool有所关联。
2. 再看上一层的调用堆栈。@autoreleasepool content的创建堆栈集中在__CFRunLoopDoObservers函数。少量在其他堆栈中。
可以认为，主要是在__CFRunLoopDoObservers 这个场景下出现了不符合预期的情况。
通过内存快照选中查看单个的@autoreleasepool content对象的内存引用关系，发现有两个现象：
1. 单个@autoreleasepool content中存在对某些对象的多次重复持有。以下是单个引用关系，其中+32 bytes 和 +40 bytes 分别是当前对象的父节点和子节点。
其余的则是被添加到pool中进行内存管理的对象们。
可以看到该对象主要持有了大量的CFRunloopObserver对象，且会对C-FRunloopObserver对象产生多次持有。
如图中，可以看到这个@autoreleasepool content对象存在了对多个CFRunloopObserver的63和62次引用。
2.@autoreleasepool content之间存在非常深的链式持有关系。
每个@autoreleasepool content在运行过程中其实是一个双向链表的结构@autoreleasepool content是固定4KB的内存大小。
在运行过程中，如果当前pool满了，则会创建下一个pool，并会互相持有，分别作为对方的父节点与子节点。
如下图，可以看到我们选中的这个@autoreleasepool content 被大量的父节点持有，同时这个对象也持有了大量的子节点。
4.1.3 正常情况下的表现
此时我们可以对比正常没有进行防护的应用表现，可以发现内存不再增长，观察此时的MemoryGraph。
一，此时内存快照中的@autoreleasepool content的数量没有随着对应用的操作而增长，而是维持在一个相对稳定的数量上。
二，没有发现基于__CFRunLoopDoObservers链路创建的@autorelease-pool content对象。
三，没有发现大量链式持有的@autoreleasepool content集合。
通过对比可以得出结论，是由于这段针对MutableArray 的 objectAtIndex方法进行防护逻辑，使得@autoreleasepool content 对象被大量创建且不释放，不断积累，导致了应用出现OOM。
如果我们能将上述现象解释明白，这个问题的原因也就解决了。
4.2 Runloop的执行
先分析__CFRunLoopDoObservers这个函数。
通过函数名即可知这是在iOS Runloop体系中的一个函数。因为iOS 的Runloop是开源的，省了人工逆向的逻辑，我们直接去appleopensource上下载源码来查看。
Runloop的代码实现在CoreFoundation中，这里是源码地址：
https://opensource.apple.com/source/CF/
其中有不同版本的CoreFoundation代码，我们直接查看最新的那一套。
https://opensource.apple.com/source/CF/CF-1153.18/
4.2.1 __CFRunLoopDoObservers的函数逻辑
下载后，可以在CFRunLoop.c 这个文件中找到Runloop的实现。直接搜索__CFRunLoopDoObservers，即可找到对应实现。
简单解释下__CFRunLoopDoObservers的代码逻辑，函数参数为当前Runloop对象 rl，当前的RunloopMode 对象 rlm，和当前的状态activity。
函数中，绿色框部分是通过CFArrayGetValueAtIndex 函数将 rlm（Runloop Mode）所持有的observers进行一次遍历，取出所有合法且注册监听状态与activity一致的observer，添加进入collectedObservers 这个临时数组中。
在蓝色框部分中，依次遍历collectedObservers这个数组中的observer对象，并通知他们当前runloop的状态发生了变化。即将进入对应的某个activity状态。
此时，我们可以注意到关键函数CFArrayGetValueAtIndex。我们可知iOS的体系中，CoreFoundation 与 Foundation中的对象其实是Full-bridge的，两个框架之间的对象可以进行强制的类型互转。
也就是，我们对NSMutableArray的objcAtIndex进行swizzle，映射下来也会影响到CFArrayGetValueAtIndex这个函数逻辑。
也就解释了为什么在我们的防护逻辑下，__CFRunLoopDoObservers这个函数会调用到我们的kscrash_objectAtIndex 这个方法中来。
且可知此时的数组中的对象全部都是 CFRunloopObserver 类型，也就是我们上面看到的大量反复持有的CFRunloopObserver对象。
4.2.2 __CFRunLoopDoObservers什么时候被调用
iOS的同学都看过下面这张关于Runloop执行的流程的图。
可以看到iOS中Runloop的执行，就是驱动自身的Observer通知状态变更，处理Source0和Source1事件。
核心函数就是__CFRunLoopRun 这个函数。这块相关的文章太多了，我们直接贴一张相关的图片。
可以看到，__CFRunLoopDoObservers 的作用，就是将当前状态的变更对注册进来的observer进行通知。
实际会在上图中所有通知Observer的时候调用__CFRunLoopDoObservers这个函数。
到这里我们可以解释为什么__CFRunLoopDoObservers这个函数会调用到我们业务层的防护逻辑。以及为什么MemoryGraph中可以看到@autoreleasepool content对象中会引用CFRunloopObserver。
这是由于__CFRunLoopDoObservers中会调用CFGetObjectAtIndex，将持有CFRunloopObserver的数组进行遍历。
导致业务层会调用CFRunloopObserver对象的autorelease方法，将CFRunloopObserver对象加入到自动释放池中。
4.3 @autoreleasepool content
@autoreleasepool content 其实就是AutoreleasePoolPage。相关实现定义在objc4这套代码里面，一样是全开源的，源码可看：
https://opensource.apple.com/source/objc4/
4.3.1 结构定义
Autoreleasepool的结构定义如下，每个AutoreleasepoolPage 的大小固定为4Kb，除了头结点所持有的一些必要信息，其他内存空间都用作持有添加进入释放池的obj对象。
在实际的使用过程中，AutoreleasepoolPage是一个双向链表，有成员变量同时指向父节点和子节点。整体结构定义如下：
（ps：翻objc4源码的时候发现在最新版的AutoreleasepoolPage与这块有些不同，新加入了AutoreleasePoolPageData的相关定义。但是总逻辑是一致的。）
4.3.2 add函数
在应用运行过程中，如果有某个对象的autorelease方法被调用，则会最终调用到AutoreleasePoolPage的函数中。
这个函数的逻辑就是将obj引用压入自己当前的栈顶中，并修改next指针至下一个可控空间。注意此时obj可以为任何对象，也可以为nil指针。
id *add(id obj) { assert(!full()); unprotect(); id *ret = next; *next++ = obj; protect(); return ret; }
4.3.3 AutoreleasePoolPage的使用
我们看下在MRC环境下是如何使用创建autoreleasePool的。
int main(int argc, const char * argv[]) { { void * atautoreleasepoolobj = objc_autoreleasePoolPush(); // do whatever you want objc_autoreleasePoolPop(atautoreleasepoolobj); } return 0;}
可以看到实际上就是通过调用autoreleasepoolPush函数启用，其实会有一个返回指针。在需要结束，将池子中的对象都释放的话，调用autoreleasepoolPop函数，将指针传入即可。
4.3.4 objc_autoreleasePoolPush
可以看到，push函数，就是将POOL_SENTINEL作为参数，调用autoreleaseFast函数。
可知POOL_SENTINEL是一个宏定义，其本质就是一个 nil 指针。
#define POOL_SENTINEL nil static inline void *push() { id *dest; { dest = autoreleaseFast(POOL_SENTINEL); } assert(*dest == POOL_SENTINEL); return dest; }
我们在上面的结构可知，每个AutoreleasepoolPage 其实只有4k的大小。按照每个指针为8个字节计算，实际每个AutoreleasepoolPage能引用的对象就是为500多个。
因此在autoreleaseFast函数中，先通过hotPage获取当前线程当前可用的poolPage对象，并判断了下这个page对象是不是full的。如果没有满，则直接调用add函数，也就是直接将一个nil指针压入了当前poolPage的栈顶中。
static inline id *autoreleaseFast(id obj) { AutoreleasePoolPage *page = hotPage(); if (page && !page->full()) { return page->add(obj); } else if (page) { return autoreleaseFullPage(obj, page); } else { return autoreleaseNoPage(obj); } }
如果page已经满了，则会调用autoreleaseFullPage函数。创建一个新的PoolPage对象，并设置为当前的hotPage。
同时也会设置两个page之间的父子关系，也就是构建page之间的双向链表引用关系。
static __attribute__((noinline)) id *autoreleaseFullPage(id obj, AutoreleasePoolPage *page) { // The hot page is full. // Step to the next non-full page, adding a new page if necessary. // Then add the object to that page. assert(page == hotPage()); assert(page->full() || DebugPoolAllocation); do { if (page->child) page = page->child; else page = new AutoreleasePoolPage(page); } while (page->full()); setHotPage(page); return page->add(obj); }
这里能够解释上面MemoryGraph中出现@autoreleasepool content对象出现链式引用的原理。
我们可以得出结论，如果@autoreleasepool content满了，就会创建下一个@autoreleasepool content，如果这个又满了，则会继续创建下一个，无限创建下去。
那么这些@autoreleasepool content到底什么时候会被释放呢？
4.3.5 objc_autoreleasePoolPop
在实际中调用，我们会调用objc_autoreleasePoolPop (atautoreleasepoolobj)，同时我们也知道了，atautoreleasepoolobj 这个指针，其实就是POOL_SENTINEL，也就是一个nil指针。作为哨兵对象。
看下Pop函数的实现。（有删减一些与本次分析无关分支，大家可以自己读下相关完整源码）
static inline void pop(void *token) { AutoreleasePoolPage *page; id *stop; page = pageForPointer(token); stop = (id *)token; if (PrintPoolHiwat) printHiwat(); page->releaseUntil(nil); if (page->child) { if (page->lessThanHalfFull()) { page->child->kill(); } else if (page->child->child) { page->child->child->kill(); } } }
可知在当前，token指针就是一个nil指针，那么此处的stop的指针，就是nil，实际上这时候又调用到了page的releaseUntil函数，将POOL_SENTINEL(nil，哨兵对象)作为参数传入。
void releaseUntil(id *stop) { // Not recursive: we don't want to blow out the stack // if a thread accumulates a stupendous amount of garbage while (this->next != stop) { // Restart from hotPage() every time, in case -release // autoreleased more objects AutoreleasePoolPage *page = hotPage(); // fixme I think this `while` can be `if`, but I can't prove it while (page->empty()) { page = page->parent; setHotPage(page); } page->unprotect(); id obj = *--page->next; memset((void*)page->next, SCRIBBLE, sizeof(*page->next)); page->protect(); if (obj != POOL_BOUNDARY) { objc_release(obj); } } setHotPage(this); }
这里的逻辑就是，利用next指针，从栈顶开始判断，如果当前的栈顶元素不为传入的stop指针相等，那么就会将栈顶对象取出，next指针--即清理这个指针空间，然后调用一次这个取出来对象的release方法。
如果调用release后这个对象的retainCount为0，则会触发这块内存的回收。
如果当前的page全都遍历完，但是依旧没有找到这个stop指针呢？
则代表这个page已经全部释放完了，同时将这个page的父节点设置为hotPage，并进行下一次的遍历查找stop指针。
结合Pop函数，当查找到stop指针后，会再遍历一次page的所有子节点，如果这些节点空了，则会调用page的kill函数，回收page本身的内存占用。
4.4 总结
那么，结合上下逻辑，我们可知poolpage对象的内存创建与回收时机，
在push函数中传入POOL_SENTINEL作为哨兵对象，然后再后续的add函数中，如果满了则会继续创建下一个poolpage。
但是在pop函数中，则会从最子节点开始往回回溯，查找POOL_SENTINEL，并释放这个过程中通过add函数加入所持有的各种业务对象。
在遍历结束中，并释放已经empty的子节点们，完成内存的回收。
因此可知AutoreleasepoolPage的push和pop函数必须对称使用，才能实现合理高效的内存管理逻辑。
4.5 Runloop与Autoreleasepool的结合
这里自然而然可以联想到一个很经典的iOS面试题：iOS中Runloop与Autoreleasepool的关系是什么？
我们可以直接获取Runloop中打印一下CFRunLoopObserver的对象，可以观察到两个关键的Observer，他们注册的回调函数都是_wrapRunLoopWithAutoreleasePoolHandler。
"<CFRunLoopObserver {valid = Yes, activities = 0x1, repeats = Yes, order = -2147483647, callout = _wrapRunLoopWithAutoreleasePoolHandler , context = {type = mutable-small, count = 0, values = ()}}", "<CFRunLoopObserver {valid = Yes, activities = 0xa0, repeats = Yes, order = 2147483647, callout = _wrapRunLoopWithAutoreleasePoolHandler , context = {type = mutable-small, count = 0, values = ()}}"
他们的优先级分别为-2147483647和2147483647，转成16进制为0x7FFFFFFF。是一个极大值和极小值。代表两个Observer分别需要在状态通知中，被最早调用和最晚调用。
一个Observer会监听Entry(即将进入Loop)，并且优先级最高，会第一个调用PoolPage的Push函数，保证创建释放池发生在其他所有回调之前。
另一个Observer会监听BeforeWaiting(准备进入休眠)和Exit(即将退出Loop) ，且优先级最低，确保其他回调都执行结束了，才会回溯自动释放池，并回收内存。
_wrapRunLoopWithAutoreleasePoolHandler这个函数中，就是判断传入的activities类型，分别调用_objc_autoreleasePoolPush 和 _objc_autoreleasePoolPop函数，来进行自动释放池的管理。
因此我们写的业务代码，在Runloop的运行驱动之中，这些调用都在被Runloop创建的AutoreleasePool所环绕，从而实现了内存管理，也帮助我们确保不会出现内存泄露。
4.6 OOM的原因分析
我们swizzle了NSMutableArray的方法，将objectAtIndex转移至业务层的kscrash_objectAtIndex: ，
则会主动调用一次对应obj的autorelease 方法。而autorelease的实现，就是调用当前Autoreleasepool的add函数，将obj加入自动释放池中。
结合上述的Autoreleasepool 和 Runloop的源码可知，在应用运行过程中，
1. 由于业务方的代码Hook，会将通过objectAtIndex来遍历数组对象的对象，添加进入Autoreleasepool之中。也就是CFRunloopObserver对象。那么
2. 系统会在Runloop启动的时候，通过遍历Runloop Observer，触发Autoreleasepool调用Push函数，向栈内加入一个哨兵对象作为标志位。
3. 在Runloop结束后，通过遍历Runloop Observer调用Autoreleasepool的Pop函数，逐一释放对象，直到遇见哨兵对象为止。
![【iOS】一段防护代码引发的内存风暴]( "【iOS】一段防护代码引发的内存风暴")
4. 最终的状态如下，对比这次Runloop启动前，可以发现当前poolpage中已经多加了observer对象在池子中。
![【iOS】一段防护代码引发的内存风暴]( "【iOS】一段防护代码引发的内存风暴")
1. Runloop Observer对象，在哨兵对象之前被添加进入了Autoreleasepool的栈顶。
2. Observer没有对应被移出Autoreleasepool的调用时机。
3. 循环执行的的Runloop函数，导致RunloopObserver被不断地压入Autoreleasepool池子中。
4. Autoreleasepool只有4k空间用于存储数据，当池子满了，则会自动创建下一个Autoreleasepool对象。
5. 大量的Autoreleasepool随着Runloop的在内存中被创建且不释放。
6. 随着App的运行时间变长，已申请内存空间不断增加，可用空间越来越少，最终导致应用OOM💥。
现在回过头看我们内存快照中的两张图，能与此处的结论能够相互印证。
且这个底层逻辑，因为不与特定入口相关联，不影响业务上任何的逻辑执行，但是只要使用App，且使用的时间足够长，就会导致内存的可用空间不断减少，最终导致OOM。也是为什么我们的上报能够看到在App的任何页面中都出现了内存警告的大幅增长。
五、其他
5.1可用的线上内存分析工具
因为这次的线上问题是在一个运行了一个月的稳定版本上发生，团队成员们第一时间基于对应时间内的配置变更着手，发现并解决了问题。但是如果这个问题是发生在一个全新的版本上，通过配置变更的思路来排查就不可用了，需要通过其他手段来进行有效的线上分析。
团队重新利用了Demo工程复现相关场景，并观察利用TME的火眼内存工具。
在对内存分区进行扫描，以及监控内存分配堆栈，两个维度监控，查看是否能够在线上抓取到相关问题。
在通过调整下发的检测参数后，也发现了对应的上报。图一是扫描出来的PoolPage对象，与其中的引用关系。
5.2 不同CF版本的代码对比
公司的其他团队的同学有反馈他们之前也遇到这个问题，不过更加前置的在内部阶段就发现了问题。
同时他们提到，这个问题之前的系统版本是没有问题的，是在后续的iOS系统版本上才会出现这个问题。
因此我们对比了下不同的CF源码版本，果然发现了差异
早一点CF版本在__CFRunLoopDoObservers 里面遍历observer的话，rlm是使用NSSet来管理Observer，是用的下标取法
而对比最新的CF代码版本，这段逻辑改成了数组的逻辑
也就是确实这个问题应该只会在高一点的版本中才会出现。
六、问题解决
只需要将相关的防护逻辑，从ARC编译修改为MRC的编译模式，移除编译器自动加入的autorelease调用，即可避免问题的产生。
七、复盘与总结
这一次线上问题的排查，实际上过程中也是拉通了相当多业务团队同学们来一起追溯原因。
由于这个问题实际上不会影响任何业务逻辑的调用和执行，所以问题的发现是在配置发布接近2天后才被开发感知到并介入干预。
事后通过技术的监控也都能发现了数据的异常，因此也都在第一时间对这些指标在火眼（APM平台）上增加了告警。
这段防护逻辑实际上在20年就在K歌的工程中实现了，只是由于一直没有遇到实际的业务场景，所以外网一直都没开。
过了3年时间，大家都默认这段代码应该都没问题了，导致这次第一次遇到实际场景后开放相关开关就踩坑了。
也通过这次实实在在的外网问题反馈，聚类，排查，归因，解决，明白了团队在应用稳定性建设上还有相当多的不足与后路要走。
原文始发于微信公众号（腾讯音乐技术团队）：【iOS】一段防护代码引发的内存风暴
评论