Objective-C 内存管理精髓

本文深入探讨了Objective-C的内存管理机制,包括引用计数、内存管理API及其准则,并详细解释了AutoreleasePool如何将Objective-C的内存管理提升至半自动化。同时,文章还阐述了面向对象领域中的引用概念、实例拥有权及循环引用的处理方式。

iPhone系统中的Objective-C的内存管理机制是比较灵活的,即可以拿来像C/C++一样用,也可以加个AutoreleasePool让它升级为半自动化的内存管理语言。

文/OSChina

之前写过类似的文章,这篇以做总结,希望能帮助刚上船的兄弟。_

iPhone系统中的Objective-C的内存管理机制是比较灵活的,即可以拿来像C/C++一样用,也可以加个AutoreleasePool让它升级为半自动化的内存管理语言。当然,也不能拿JAVA虚拟机中的全自动化GC来比?

引用计数是实例对象的内存回收唯一参考

引用计数(retainCount)是Objective-C管理对象引用的唯一依据。调用实例的release方法后,此属性减一,减到为零时对象的dealloc方法被自动调用,进行内存回收操作,也就是说我们永不该手动调用对象的dealloc方法。

它的内存管理API老简单老简单了,下面就是它主要操作接口:

1,alloc, allocWithZone,new(带初始化)
为对象分配内存,retainCount为“1”,并返回此实例

2,retain
retainCount 加“1”

3,copy,mutableCopy
复制一个实例,retainCount数为“1”,返回此实例。所得到的对象是与其它上下文无关的,独立的对象(干净对象)。

4,release
retainCount 减“1”,减到“0”时调用此对象的dealloc方法

5,autorelease
在当前上下文的AutoreleasePool栈顶的autoreleasePool实例添加此对象,由于它的引入使Objective-C(非GC管理环境)由全手动内存管理上升到半自动化。

Objective-C内存管理准则

我们可以把上面的接口按对retainCount的操作性质归为两类,
A类是加一操作:1,2,3
B类是减一操作:4,5(延时释放)

内存管理准则如下:
1,A与B类的调用次数保持一制
2,为了很好的保障准则一,以实例对象为单位,谁A了就谁B,没有第二者参与

例:

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSObject *o = [[NSObject alloc] init];     //retainCount为1
[o retain];     //retainCount为2
[o release];  //retainCount为1
[o autorelease];  //retainCount为1
[pool release];  //retaincount为0,触发dealloc方法
 
对象的拥有者

面向对象领域里有个引用的概念,区别于继承,引用常被用来当做偶合性更小的设计。继承是强依赖,对吧。我们要降偶软件的设计,就要尽量减少对它的使用。但没有任何偶合的模块或功能是没有用的?对吧,那我们只能多用引用了吧。一个实例拥有另一个实例的时候,我们称它为引用了另一个实例。

比如ClassA类的一个属性对象的Setter方法:

- (  void  )setMyArray:(NSMutableArray *)newArray {
      if  (myArray != newArray) {
          [myArray release];
          myArray = [newArray retain];
      }
}

假设这个类的一个实例为'a',调用setMyArray后,我们就可以说a拥有了一个新的myArray实例,也可以说a引用了一个新的myArray实例。其中调用的retain方法,使myArray的retainCount加一,我们需要注意以下两个地方:
1,setMyarray方法中,在retain之前先release了旧实例一次
2,在本实例的dealloc方法中,本应该是要再次release当前实例的,但回头看看参考内存管理准则。它并不合理,对吧。。。多了一次release。这里比较推荐的做法是:
[ myArray setMyArray:nil ];
这样可以巧妙的使当前实例release而不出错(我们可以向nil发送消息?其实它本身就是个整数0),并符合我们的内存管理准则。更主要的是,很简单,你不需要考虑过多的事情。

另外一个比较容易忽略而又比较经典的问题是实例变量的循环引用,Objective-C为此区分了,其实也相当相当的简单:
1,强引用,上面讲的就是强引用,存在retainCount加一。
2,弱引用,但凡是assign声明并直接用指针赋值实现的被称之为弱引用,不存在retainCount加一的情况。

AutoreleasePool使Objective-C成为内存管理半自动化语言

如果仅仅是上面这些,很简单,对吧。但往往很多人都会迷糊在自动内存管理这块上,感觉像是有魔法,但其实原理也很简单?

先看看最经典的程序入口程序:

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
int  retVal = UIApplicationMain(argc, argv, nil, nil);
[pool release];

我们先把pool看成一个普通对象?很简单,先是alloc,pool的retainCount为1。第三句release,retainCount为0,自动调用它的dealloc方法。它和任何其它普通对象没 任何区别。

魔法在哪里?
在声明pool后,release它之前的这段代码,所有段里的代码(先假设中间没有声明其它的AutoreleasePool实例),凡是调用了autorelase方法的实例,都会把它的retainCount加1,并在此pool实例中添1次此实例要回收的记录以做备案。当此pool实例dealloc时,首先会检查之前备案的所有实例,所有记录在案的实例都会依次调用它的release方法。

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSObject *o = [[NSObject alloc] init];
//在pool实例dealloc时,release一次此实例,重要的是并不是在此行去release
[o autorelease]; 
//此时还可以看到我们的o实例还是可用的,并且retainCount为1
NSLog(@  "o retainCount:%d"  ,[o retainCount]); 
//pool 的 retainCount为0,自动调用其dealloc方法,我们之前备案的小o也将在这里release一次
[pool release];

真对同一个实例,同一个Pool是可以多次注册备案(autorelease)的。在一些很少的情况化可能会出现这种需求:

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSObject *o = [[NSObject alloc] init];
[o retain];
[o autorelease];
[o autorelease];
[pool release];

我们调用了两次A类(retainCount加1的方法),使其retainCount为2,而接下来的两次autorelease方法调用,使其在pool中注册备案了两次。这里的pool将会在回收时调用此实例的两次release方法。使其retainCount降为0,完成回收内存的操作,其实这也是完全按照内存管理规则办事的好处?

AutoreleasePool是被嵌套的!
池是被嵌套的,嵌套的结果是个栈,同一线程只有当前栈顶pool实例是可用的:

栈顶pool_5
栈中pool_4
栈中pool_3
栈中pool_2
栈底pool_1

 

其代码如下:

NSAutoreleasePool *pool1 = [[NSAutoreleasePool alloc] init];
NSAutoreleasePool *pool2 = [[NSAutoreleasePool alloc] init];
NSAutoreleasePool *pool3 = [[NSAutoreleasePool alloc] init];
NSObject *o = [[NSObject alloc] init] autorelease];
[pool3 release];
[pool2 release];
[pool1 release];

我们可以看到其栈顶是pool3,o的autorelease是把当前的release放在栈顶的pool实例管理。。。也就是pool3。
在生命周期短,产生大量放在autoreleasePool中管理实例的情况下经常用此方法减少内存使用,达到内存及时回收的目的。

AutoreleasePool还被用在哪里?
在上面的例子里,也可以看到,我们在执行autorelease方法时,并没有时时的进行release操作?它的release被延时到pool实例的dealloc方法里。这个小细节使我们的Objective-C用起来可以在方法栈中申请堆中的内存,创建实例,并把它放在当前pool中延迟到此方法的调用者释放?

 

转载地址:http://my.oschina.net/jeans/blog/68271

标题基于Python的汽车之家网站舆情分析系统研究AI更换标题第1章引言阐述汽车之家网站舆情分析的研究背景、意义、国内外研究现状、论文方法及创新点。1.1研究背景与意义说明汽车之家网站舆情分析对汽车行业及消费者的重要性。1.2国内外研究现状概述国内外在汽车舆情分析领域的研究进展与成果。1.3论文方法及创新点介绍本文采用的研究方法及相较于前人的创新之处。第2章相关理论总结和评述舆情分析、Python编程及网络爬虫相关理论。2.1舆情分析理论阐述舆情分析的基本概念、流程及关键技术。2.2Python编程基础介绍Python语言特点及其在数据分析中的应用。2.3网络爬虫技术说明网络爬虫的原理及在舆情数据收集中的应用。第3章系统设计详细描述基于Python的汽车之家网站舆情分析系统的设计方案。3.1系统架构设计给出系统的整体架构,包括数据收集、处理、分析及展示模块。3.2数据收集模块设计介绍如何利用网络爬虫技术收集汽车之家网站的舆情数据。3.3数据处理与分析模块设计阐述数据处理流程及舆情分析算法的选择与实现。第4章系统实现与测试介绍系统的实现过程及测试方法,确保系统稳定可靠。4.1系统实现环境列出系统实现所需的软件、硬件环境及开发工具。4.2系统实现过程详细描述系统各模块的实现步骤及代码实现细节。4.3系统测试方法介绍系统测试的方法、测试用例及测试结果分析。第5章研究结果与分析呈现系统运行结果,分析舆情数据,提出见解。5.1舆情数据可视化展示通过图表等形式展示舆情数据的分布、趋势等特征。5.2舆情分析结果解读对舆情分析结果进行解读,提出对汽车行业的见解。5.3对比方法分析将本系统与其他舆情分析系统进行对比,分析优劣。第6章结论与展望总结研究成果,提出未来研究方向。6.1研究结论概括本文的主要研究成果及对汽车之家网站舆情分析的贡献。6.2展望指出系统存在的不足及未来改进方向,展望舆情
【磁场】扩展卡尔曼滤波器用于利用高斯过程回归进行磁场SLAM研究(Matlab代码实现)内容概要:本文介绍了利用扩展卡尔曼滤波器(EKF)结合高斯过程回归(GPR)进行磁场辅助的SLAM(同步定位与地图构建)研究,并提供了完整的Matlab代码实现。该方法通过高斯过程回归对磁场空间进行建模,有效捕捉磁场分布的非线性特征,同时利用扩展卡尔曼滤波器融合传感器数据,实现移动机器人在复杂环境中的精确定位与地图构建。研究重点在于提升室内等无GPS环境下定位系统的精度与鲁棒性,尤其适用于磁场特征明显的场景。文中详细阐述了算法原理、数学模型构建、状态估计流程及仿真实验设计。; 适合人群:具备一定Matlab编程基础,熟悉机器人感知、导航或状态估计相关理论的研究生、科研人员及从事SLAM算法开发的工程师。; 使用场景及目标:①应用于室内机器人、AGV等在缺乏GPS信号环境下的高精度定位与地图构建;②为磁场SLAM系统的设计与优化提供算法参考和技术验证平台;③帮助研究人员深入理解EKF与GPR在非线性系统中的融合机制及实际应用方法。; 阅读建议:建议读者结合Matlab代码逐模块分析算法实现细节,重点关注高斯过程回归的训练与预测过程以及EKF的状态更新逻辑,可通过替换实际磁场数据进行实验验证,进一步拓展至多源传感器融合场景。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值