理解dealloc的调用时机
在iOS开发中，dealloc方法是对象生命周期结束的标志，由Objective-C运行时或Swift的ARC（自动引用计数）机制在对象引用计数降为零时自动调用。开发者常在此方法中执行资源释放、通知移除等清理工作。然而，当对象被其他对象强引用持有时，其引用计数无法归零，dealloc便不会执行。因此，dealloc未触发本质上是一个对象未能被正确释放的问题，是排查内存泄漏的关键线索。
循环引用：最常见的原因
循环引用是阻止dealloc调用的首要元凶。它发生在两个或多个对象相互强引用，形成闭环，导致引用计数永远无法清零。典型场景包括：使用闭包（Block/Closure）时捕获了self而未使用弱引用；委托（Delegate）属性被声明为强引用；以及父子视图控制器之间不恰当的相互持有。例如，一个视图控制器强引用着一个包含`self`的闭包，而这个闭包又被该控制器所持有，就构成了循环。打破循环的关键在于识别闭环，并将其中一环改为弱引用或无主引用。
系统框架与全局持有的影响
除了自定义代码，系统框架的行为也可能导致对象被意外持有。例如，向通知中心（NotificationCenter）注册观察者后未及时移除，观察者对象就会被系统持有。使用NSTimer、CADisplayLink时，若未正确调用invalidate方法，它们会对target形成强引用。此外，将对象添加到全局的集合（如数组、字典）中，或将其设置为单例对象的属性，都会延长其生命周期。排查这类问题需要仔细审查代码中对系统API的调用，确保在适当时机（如viewDidDisappear或deinit中）执行对应的清理操作。
多线程环境下的释放问题
在多线程或异步操作中，对象释放的时机变得复杂。例如，在一个后台线程中创建并强引用了一个对象，如果该线程的RunLoop或操作队列持续活跃，且持有该对象，那么即使主线程逻辑认为应该释放，对象也可能存活。另一种情况是，在异步回调中错误地引用了即将释放的对象，可能导致访问已释放内存的崩溃。在处理并发时，需明确对象的持有者与生命周期，并在跨线程传递时注意使用适当的引用修饰符，避免在异步任务中产生意外的强引用链。
排查工具与实践策略
高效地定位dealloc未触发的问题离不开工具的支持。Xcode提供的Instruments套件中的“Allocations”和“Leaks”模板是核心利器。“Leaks”工具可以直接检测内存泄漏并定位可疑代码。“Allocations”工具通过记录所有内存分配事件，结合“Generation Analysis”功能，可以观察特定操作前后内存的增长情况，识别未被释放的对象。在代码层面，可以重写dealloc方法并添加日志，或为可疑类添加弱引用袋里来辅助判断。养成预防性编程习惯，如对闭包内引用self保持警惕、使用weak修饰delegate属性、及时移除通知和定时器，是避免问题发生的根本。
