ARC模式下的循环引用引起内存泄漏

简介:

自从iOS 5时代自动引用计数(Automatic Reference Counting)技术发布,Cocoa工程师们才扔下了内存管理的包袱,从此在Objective-C修行道路上的一座大山被削平。然而,即使ARC很强大,我们日常搬砖时同样是有内存泄漏风险的,今天我就跟大家聊聊这些你可能还没有注意到的坑。

测试原理

我们知道ARC模式下,NSObject的MRC相关方法都不可以使用了,但dealloc方法如果实现了,同样还是会调用的,只是不允许在dealloc方法中调用[super dealloc],所以我们在dealloc方法中加入log信息就可以跟踪到我们的实例是否释放。

容易忽视的引用循环

我们知道引用计数内存管理的设计理念,就是根据实例的计数值来决定是否释放实例内存空间。

例如我们的ViewController拥有一个block类型的property


  
  
  1. @property (nonatomic, strong) void (^ testBlock)(void); 

我们在viewDidLoad中加入如下代码


  
  
  1. [self setTestBlock:^{ 
  2.     self.title = @"测试"
  3. }];  

这个代码从表面上看没有什么问题,但编译器会给出warning,

Catering 'self' strongly in this block is likely to lead a retain cycle

翻译过来意思是在block中使用self指针,可能会引起一个引用循环,导致self无法释放。

什么是引用循环(retain cycle)

假设我们有两个实例A和B,B是A的一个strong型的property,则B的引用计数是1,当A的需要释放的时候,A则会调用[B release]来释放B,B的引用计数则减为0,释放。

可如果这时候将B的一个strong型property指向A,则A与B互相为强引用,问题就来了。因为B强引用A,A的引用计数永远不会减为0,当A原本的强引用对象被释放以后,A和B成为了一个相互引用的孤岛,永远不会被释放了,这就会引起内存泄漏。

在上面的例子中,就是一种非常普遍的引用循环情况,加入如上代码的VC在dismiss或者pop以后,并不会执行dealloc方法,证明内存泄漏了。而引起泄漏的原因就是在作为self的property的block中,使用self指针导致self被block强引用,形成引用循环。

如何解决引用循环问题

在编译器提示上面的warning的时候一定不要忽视,正确的解决办法如下:


  
  
  1. __unsafe_unretained Demo1ViewController * weakSelf = self; 
  2. [self setTestBlock:^{ 
  3.        weakSelf.title = @"测试"
  4. }];  

或者使用__weak也可以,原理也很简单,就是声明一个弱引用对象在block中替代self,这样在我们测试中,下面代码就能正常输出log,标志着VC被正确释放。


  
  
  1. - (void)dealloc 
  2.     NSLog(@"%s",__func__); 
  3.  

2016-09-07 13:17:38.879 ReactiveCocoaDemo[7473:3432323] -[Demo1ViewController dealloc]

其他会引起引用循环的状况

NSTimer

NSTimer在VC释放前,一定要调用[timer invalidate],不调用的后果就是NSTimer无法释放其target,如果target正好是self(VC本身),则引用循环。

这里要补充一点,引用循环不是只能有两个对象,三个四个更多都是可以的,甚至环数也不一定只有一个,所以要养成良好的代码习惯,在NSTimer停用前调用invalidate方法。

WKUserContentController

这个类一般会在使用WKWebView的时候配套使用,如果你发现项目中调用了addScriptMessageHandler方法,就要注意了,检查有没有在VC释放前对称调用removeScriptMessageHandlerForName方法,如果没有则引起引用循环。

调用方法如下:


  
  
  1. [self.wkWebView.configuration.userContentController removeScriptMessageHandlerForName:@"qdpay"]; 

注意WKUserContentController和WKWebView中还有一个WKWebViewConfiguration。

引用大循环

就像前面说的,引用循环可能是一个大循环。我遇到过一种情况,就是给UITableViewCell设置block属性响应事件,在block中强引用了self,导致self->tableView->cell->self形成循环。

改善block写法避免强引用self

如果要从根本改变这种易发的错误,要从写法开始改变,开始避免。将上面的代码改写如下:


  
  
  1. @property (nonatomic, strong) void (^ testBlock)(__kindof UIViewController* sender);  
  2.  
  3. [self setTestBlock:^(__kindof UIViewController * vc) { 
  4.         vc.title = @"123"
  5.  }]; 
  6.      
  7.  self.testBlock(self);  

将self作为参数传入block即可避免强引用,从逻辑角度来看,代码更健壮。

结束

上面列举的几个引用循环引起的内存泄漏,编译器是没有任何提示的,并且也不影响App运行,不会crash,但作为严谨的程序猿,我们不能容忍这种的小泄漏,虽然不影响大局,但积少成多终将影响系统的运行速度。




作者:秋刀生鱼片
来源:51CTO
目录
相关文章
|
5月前
|
缓存 算法 数据处理
如何选择合适的内存访问模式
【10月更文挑战第20天】如何选择合适的内存访问模式
111 1
|
7月前
|
开发框架 监控 .NET
|
9月前
|
设计模式 PHP 容器
在PHP中避免循环引用导致的内存泄漏问题
在PHP中避免循环引用导致的内存泄漏问题
108 1
|
9月前
|
算法 Java 程序员
Python内存管理用引用计数(对象的`ob_refcnt`)跟踪对象,但循环引用(如A->B->A)可导致内存泄漏。
【6月更文挑战第20天】Python内存管理用引用计数(对象的`ob_refcnt`)跟踪对象,但循环引用(如A->B->A)可导致内存泄漏。为解决此问题,Python使用`gc`模块检测并清理循环引用,可通过`gc.collect()`手动回收。此外,Python结合标记清除和分代回收策略,针对不同生命周期的对象优化垃圾回收效率,确保内存有效释放。
63 3
|
8月前
|
SQL 资源调度 关系型数据库
实时计算 Flink版产品使用问题之在使用Flink on yarn模式进行内存资源调优时,如何进行优化
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
8月前
|
设计模式 安全 NoSQL
Java面试题:设计一个线程安全的单例模式,并解释其内存占用和垃圾回收机制;使用生产者消费者模式实现一个并发安全的队列;设计一个支持高并发的分布式锁
Java面试题:设计一个线程安全的单例模式,并解释其内存占用和垃圾回收机制;使用生产者消费者模式实现一个并发安全的队列;设计一个支持高并发的分布式锁
99 0
|
8月前
|
存储 设计模式 监控
Java面试题:如何在不牺牲性能的前提下,实现一个线程安全的单例模式?如何在生产者-消费者模式中平衡生产和消费的速度?Java内存模型规定了变量在内存中的存储和线程间的交互规则
Java面试题:如何在不牺牲性能的前提下,实现一个线程安全的单例模式?如何在生产者-消费者模式中平衡生产和消费的速度?Java内存模型规定了变量在内存中的存储和线程间的交互规则
71 0
|
8月前
|
存储 Java 程序员
Java内存模式以及volatile关键字的使用
Java内存模式以及volatile关键字的使用
56 0
|
10月前
|
Java Python
如何在Python中处理循环引用导致的内存泄漏?
如何在Python中处理循环引用导致的内存泄漏?
126 3
|
10月前
|
缓存