如何排查修复线上APP的EXC_BAD_ACCESS KERN_INVALID_ADDRESS崩溃？

遇到这种后台停留后才触发的EXC_BAD_ACCESS KERN_INVALID_ADDRESS崩溃确实头疼，尤其是常规的Zombie和Allocation工具没抓到问题的情况。我来帮你拆解下崩溃栈，再给出针对性的排查和修复方案：

一、先从崩溃栈找核心线索 #

先梳理你的崩溃日志路径：

设置waterfallResponse的setter → 释放旧的AdMediatorZoneResponse → 销毁内部数组的AdMediatorZoneResponseItem → 触发objc_release时访问了无效内存

这里的关键信息：

1. 崩溃不是发生在访问对象，而是发生在释放对象的过程中
2. 仅在APP后台停留15-60分钟后触发，说明和系统后台内存回收机制强相关
3. Zombie没检测到问题，说明这不是「已释放对象再发消息」的经典野指针，更可能是「对象内存被系统回收/重利用后，代码还在尝试释放它」

二、针对性的调试手段 #

1. 用Memory Graph Debugger抓引用链 #

在Xcode中运行APP，模拟后台停留（可以用Xcode的Simulate Memory Warning多次触发，模拟系统回收内存），切回前台触发崩溃后，立刻打开Memory Graph Debugger：

• 搜索AdMediatorZoneResponse和AdMediatorZoneResponseItem，查看它们的引用关系
• 重点排查有没有全局缓存、第三方库或者后台任务持有这些对象的引用，导致内存被系统回收后，引用链还未更新

2. 用VM Tracker监控后台内存变化 #

打开Instruments的VM Tracker模板：

• 监控APP进入后台后的内存页状态，看是否有内存被标记为Purgeable或者直接回收
• 重点关注AdMediatorZoneResponseItem所在的内存区域，是否在后台被系统清理

3. 开启Malloc Scribble强化内存检测 #

在Xcode的Scheme设置里，开启Malloc Scribble：

• 这个选项会在对象释放后用0xAA填充内存，一旦有野指针访问，会立刻触发崩溃，且崩溃时的内存内容更易排查
• 模拟后台场景，看是否能复现并抓到更详细的内存异常信息

4. 用Thread Sanitizer排查竞态问题 #

虽然看起来是内存释放问题，但多线程竞争也可能导致内存状态异常：

• 开启Thread Sanitizer运行APP，模拟后台再前台的场景，检查是否有多个线程同时读写waterfallResponse

三、代码层面的防御性修复 #

即使还没找到根因，也可以先加一些代码避免崩溃：

1. 给waterfallResponse加线程保护 #

如果waterfallResponse可能被多线程读写，用串行队列做线程隔离：

private let responseSyncQueue = DispatchQueue(label: "com.yourcompany.admediator.response.queue")
private var _waterfallResponse: AdMediatorZoneResponse?

var waterfallResponse: AdMediatorZoneResponse? {
    get { responseSyncQueue.sync { _waterfallResponse } }
    set { responseSyncQueue.sync { _waterfallResponse = newValue } }
}

2. 对返回的data做深拷贝 #

如果data是来自外部的对象（比如网络请求返回、第三方库持有），它的内存可能被系统回收，设置时做深拷贝确保自己持有独立内存：

if let data = data {
    // 给AdMediatorZoneResponse实现深拷贝初始化方法
    self.waterfallResponse = AdMediatorZoneResponse(copy: data)
}

3. 后台时主动清理无效引用 #

在APP进入后台时，主动置空waterfallResponse，避免持有可能被系统回收的对象：

// 在AdMediatorBanner初始化时注册通知
NotificationCenter.default.addObserver(
    self,
    selector: #selector(handleAppBackground),
    name: UIApplication.didEnterBackgroundNotification,
    object: nil
)

@objc private func handleAppBackground() {
    self.waterfallResponse = nil
}

4. 确保闭包在安全线程执行 #

你的闭包是在NSOperationQueue里执行的，切换到主线程执行（如果涉及对象状态更新）：

AdMediatorManager.instance.refreshAd(self.zoneId!, self.adMediatorBannerId!) { [weak self] (data, errorCode) in
    DispatchQueue.main.async {
        guard let self = self else { return }
        if let data = data {
            self.waterfallResponse = data
        }
        // 后续逻辑
    }
}

四、额外检查点 #

• 如果AdMediatorZoneResponseItem是OC类，检查是否开启了ARC，有没有手动调用release的代码
• 检查是否有后台任务在APP后台时修改了AdMediatorZoneResponse的内容，导致内部数组元素的内存状态异常

内容的提问来源于stack exchange，提问作者Coldfish