objective-C 的内存管理之-实例分析

简介: 注:这是《Objective-C基础教程》一书上的实例,但是原书限于篇幅,分析得比较简单,初次阅读看得比较费劲,这里展开详细讨论一下。 场景:有二个类Car和Engine,即“汽车”和“引擎”。 先来看最初的版本: Engine.

注:这是《Objective-C基础教程》一书上的实例,但是原书限于篇幅,分析得比较简单,初次阅读看得比较费劲,这里展开详细讨论一下。

场景:有二个类Car和Engine,即“汽车”和“引擎”。

先来看最初的版本:

Engine.h

#import <Cocoa/Cocoa.h>

@interface Engine : NSObject

@property int flag;

@end // Engine

Engine.m

#import "Engine.h"

@implementation Engine

@synthesize flag;

- (NSString *) description
{
    return ([NSString stringWithFormat:@"I am engine %d,my retainCount=%d",flag,[self retainCount]]);
} // description


-(void) dealloc
{
	NSLog(@"this engine %d is going to die.",flag);
	[super dealloc];
	NSLog(@"this engine %d is dead.",flag);
}
@end // Engine

代码不复杂,略加解释:Engine类有一个flag属性,用于后面辅助输出时区分当前引擎的唯一标识。然后就是description方法(相当于c#中Object的toString()方法),用于返回一个描述自身的字符串。最后就是dealloc方法,用于清理自身所用的资源。

Car.h

#import <Cocoa/Cocoa.h>

#import	"Engine.h"

@interface Car : NSObject
{
    Engine *engine;	
}

@property int flag;

- (void) setEngine: (Engine *) newEngine;

- (Engine *) engine;

@end // Car

Car.m

#import "Car.h"
#import "Engine.h"


@implementation Car

@synthesize flag;

- (id) init
{
    if (self = [super init]) {
        engine = [Engine new]; //每辆汽车诞生时,先预设了一个空的引擎(flag=0的engine),这个对象最终也需要释放!       
    }
    return (self);
} // init


- (Engine *) engine
{
    return (engine);
} // engine


- (void) setEngine: (Engine *) newEngine
{
	engine = newEngine;    
} // setEngine


-(void) dealloc
{	
	NSLog(@"the car %d is going to die.",flag);
	NSLog(@"%@",engine);
	[engine release];//释放附属资源:引擎	
	[super dealloc];
	NSLog(@"the car %d is dead.",flag);
}

@end // Car

解释一下:init方法中,给每辆汽车在出厂时预置了一个默认的引擎(其flag值为默认值0),然后setEngine方法用于给汽车设置新引擎,最后dealloc中,汽车销毁时会附带release自己的引擎。

先来考虑第一种情况

有一辆汽车,给它安装了新引擎,使用完后汽车销毁,但是引擎还能拿出来做其它用途(比如给其它汽车使用之类),最后新引擎也用完了,销毁!

Car *car1 = [Car new];
car1.flag  = 1;
Engine *engine1 = [Engine new];
engine1.flag = 1;
[car1 setEngine:engine1];
[car1 release];	
NSLog(@"%@",engine1);//这里模拟引擎做其它用途	
[engine1 release];

以上代码至少有二个问题:

1.1 Car在构造函数init里,预置的默认引擎(即flag=0的引擎)最后未被释放

1.2 Car在dealloc方法中,已经释放了engine,所以Car释放后,该引擎也就跟着灰飞烟灭了,没办法再做其它用途。所以第7,8行代码根本没办法运行,会直接报错!这比内存泄漏更严重。

先来解决最严重的第2个问题,至少让它跑起来再说,根源在于:Car销毁时,附带把engine也给release了!解决它的途径有二种:

1、去掉Car.m类dealloc中的[engine release],但是本着“自家的孩子自己管”的原则,不推荐这种不负责任的做法。

2、在setEngine方法中,人工调用[newEngine retain]方法,让引擎的引用计数加1,这样正好可抵消Car.m类dealloc方法中[engine release]带来的影响(一加一减,正好抵消!)。

于是Car.m中的setEngine方法有了第二个版本:

- (void) setEngine: (Engine *) newEngine
{
	engine = [newEngine retain];    
} // setEngine

再次编译,总算通过了,也能运行了。先把问题1.1丢到一边,再来考虑第二种情况

又有一辆汽车,安装了新引擎engine1,然后试了一下,觉得不爽,于是把engine1丢了,然后又换了另一个引擎engine2(喜新厌旧!)

Car *car1 = [Car new];
car1.flag = 1;
Engine *engine1 = [Engine new];
engine1.flag = 1;
[car1 setEngine:engine1];//换新引擎engine1		
[engine1 release];//觉得不爽,于是把engine1扔了

Engine *engine2 = [Engine new];
engine2.flag = 2;
[car1 setEngine:engine2];//又换了新引擎engine2

[car1 release];//使用完以后,car1报废
[engine2 release];//新引擎engine2当然也不再需要了

同样有二个问题:

2.1 engine1先被new了一次,然后在setEngine中又被retain了一次,也就是说其retainCount为2,虽然代码中后来release了一次,但是也只能让retainCount减到1,并不能销毁!

2.2 刚才1.1中所说的问题依然存在,即Car在init方法中预置的默认引擎engine0,始终被无视了,未得到解脱。

可能,你我都想到了,在setEngine方法中,可以先把原来的旧引擎给干掉,然后再把新引擎挂上去,这样就ok了! 好吧,setEngine的第三个版本出现了:

- (void) setEngine: (Engine *) newEngine
{
	[engine release];
	engine = [newEngine retain];    
} // setEngine

貌似皆大欢喜了,但是事情还没完,又有新情况了:第三种情况

有二辆汽车Car1与Car2,Car1换了新引擎engine1,然后跑去跟Car2显摆,Car2觉得新引擎不错,于是要求跟Car1共用新引擎engine1,但问题是:在Car2尚未下手前,engine1已经被某人(可能是car1自己,也可能是车主main()函数)给抛弃了!

Engine *engine1 = [Engine new];//engine1.retainCount=1
engine1.flag = 1;
	
Car *car1 = [Car new];
car1.flag = 1;
	
Car *car2 = [Car new];
car2.flag = 2;
	
[car1 setEngine:engine1];//car1换了新引擎engine1	
[engine1 release];//然后很快又抛弃了它
	
[car2 setEngine:[car1 engine]];//car2要跟car1共用engine1
	
//最后car1跟car2都被车主main函数给扔了
[car2 release];
[car1 release];

问题:在16行[car2 release]时,car2已经彻底把engine1给销毁了(也许car2忘记了,engine1是它跟car1共同的财产),于是紧接着[car1 release]时,car1的dealloc方法在[engine release]时,意外发现engine1已经不在人世了,最终它愤怒了,整个程序也就罢工了!

setEngine的最后一个版本

- (void) setEngine: (Engine *) newEngine
{	
	[newEngine retain];
	[engine release];	
	engine = newEngine;
    
} // setEngine

其实就是把上一个版本的二行代码,拆分成了三行,变成了先retain,再release,看上去好象含义一样,但是仔细分析你会发现,如果当engine与newEngine为同一个对象的引用时(即这二指针指向的为同一块内存),且newEngine(其实也就是engine)的retainCount为1时,原来的版本会导致newEngine(其实也就是engine)销毁,而现在这样处理后,即会被保留下来。

最后验证一个最终版本是否能完美应付上面提到的三种情况:

第一种情况的运行结果:

2011-02-25 09:17:52.951 CarParts[257:a0f] this engine 0 is going to die.
2011-02-25 09:17:52.957 CarParts[257:a0f] this engine 0 is dead.
2011-02-25 09:17:52.959 CarParts[257:a0f] the car 1 is going to die.
2011-02-25 09:17:52.961 CarParts[257:a0f] I am engine 1,my retainCount=2
2011-02-25 09:17:52.962 CarParts[257:a0f] the car 1 is dead.
2011-02-25 09:17:52.966 CarParts[257:a0f] I am engine 1,my retainCount=1
2011-02-25 09:17:52.968 CarParts[257:a0f] this engine 1 is going to die.
2011-02-25 09:17:52.969 CarParts[257:a0f] this engine 1 is dead.

第二种情况的运行结果:

2011-02-25 09:19:30.639 CarParts[291:a0f] this engine 0 is going to die.
2011-02-25 09:19:30.644 CarParts[291:a0f] this engine 0 is dead.
2011-02-25 09:19:30.646 CarParts[291:a0f] this engine 1 is going to die.
2011-02-25 09:19:30.648 CarParts[291:a0f] this engine 1 is dead.
2011-02-25 09:19:30.650 CarParts[291:a0f] the car 1 is going to die.
2011-02-25 09:19:30.652 CarParts[291:a0f] I am engine 2,my retainCount=2
2011-02-25 09:19:30.653 CarParts[291:a0f] the car 1 is dead.
2011-02-25 09:19:30.655 CarParts[291:a0f] this engine 2 is going to die.
2011-02-25 09:19:30.657 CarParts[291:a0f] this engine 2 is dead.

第三种情况的运行结果:

2011-02-25 09:21:02.549 CarParts[324:a0f] this engine 0 is going to die.
2011-02-25 09:21:02.554 CarParts[324:a0f] this engine 0 is dead.
2011-02-25 09:21:02.556 CarParts[324:a0f] this engine 0 is going to die.
2011-02-25 09:21:02.558 CarParts[324:a0f] this engine 0 is dead.
2011-02-25 09:21:02.559 CarParts[324:a0f] the car 2 is going to die.
2011-02-25 09:21:02.561 CarParts[324:a0f] I am engine 1,my retainCount=2
2011-02-25 09:21:02.563 CarParts[324:a0f] the car 2 is dead.
2011-02-25 09:21:02.571 CarParts[324:a0f] the car 1 is going to die.
2011-02-25 09:21:02.573 CarParts[324:a0f] I am engine 1,my retainCount=1
2011-02-25 09:21:02.575 CarParts[324:a0f] this engine 1 is going to die.
2011-02-25 09:21:02.578 CarParts[324:a0f] this engine 1 is dead.
2011-02-25 09:21:02.587 CarParts[324:a0f] the car 1 is dead.

从输出结果上看,不管是哪一种情况,Car以及Engine资源最终都得到了释放!

 

2014-02-21 注:现在最新的xcode上,setEngine方法不管是第二个版本,还是第三个版本,对于第三种情况,都能正确释放所有资源。估计是xcode做了改进,这二个版本编译出来的代码,个人估计是相同的,原书上的分析应该是基于当时的xcode环境,友情提醒大家学习时注意。

目录
相关文章
|
6天前
|
Web App开发 监控 JavaScript
监控和分析 JavaScript 内存使用情况
【10月更文挑战第30天】通过使用上述的浏览器开发者工具、性能分析工具和内存泄漏检测工具,可以有效地监控和分析JavaScript内存使用情况,及时发现和解决内存泄漏、过度内存消耗等问题,从而提高JavaScript应用程序的性能和稳定性。在实际开发中,可以根据具体的需求和场景选择合适的工具和方法来进行内存监控和分析。
|
30天前
|
编译器 C语言
动态内存分配与管理详解(附加笔试题分析)(上)
动态内存分配与管理详解(附加笔试题分析)
45 1
|
2月前
|
程序员 编译器 C++
【C++核心】C++内存分区模型分析
这篇文章详细解释了C++程序执行时内存的四个区域:代码区、全局区、栈区和堆区,以及如何在这些区域中分配和释放内存。
50 2
|
4天前
|
存储 缓存 安全
阿里云服务器内存型r7、r8a、r8y、r8i实例区别及选择参考
随着阿里云2024年金秋云创季的开始,目前在阿里云的活动中,属于内存型实例规格的云服务器有内存型r7、内存型r8a、内存型r8y和内存型r8i这几个实例规格,相比于活动内的经济型e和通用算力型u1等实例规格来说,这些实例规格等性能更强,虽然这几个实例规格的云服务器通常处理器与内存的配比为都是1:8,但是他们在处理器、存储、网络、安全等方面等性能并不是一样的,所以他们的适用场景也有着不同。本文为大家介绍内存型r7、r8a、r8y、r8i实例的性能、适用场景的区别以及选择参考。
|
1天前
|
开发框架 监控 .NET
【Azure App Service】部署在App Service上的.NET应用内存消耗不能超过2GB的情况分析
x64 dotnet runtime is not installed on the app service by default. Since we had the app service running in x64, it was proxying the request to a 32 bit dotnet process which was throwing an OutOfMemoryException with requests >100MB. It worked on the IaaS servers because we had the x64 runtime install
|
11天前
|
Web App开发 JavaScript 前端开发
使用 Chrome 浏览器的内存分析工具来检测 JavaScript 中的内存泄漏
【10月更文挑战第25天】利用 Chrome 浏览器的内存分析工具,可以较为准确地检测 JavaScript 中的内存泄漏问题,并帮助我们找出潜在的泄漏点,以便采取相应的解决措施。
84 9
|
15天前
|
并行计算 算法 IDE
【灵码助力Cuda算法分析】分析共享内存的矩阵乘法优化
本文介绍了如何利用通义灵码在Visual Studio 2022中对基于CUDA的共享内存矩阵乘法优化代码进行深入分析。文章从整体程序结构入手,逐步深入到线程调度、矩阵分块、循环展开等关键细节,最后通过带入具体值的方式进一步解析复杂循环逻辑,展示了通义灵码在辅助理解和优化CUDA编程中的强大功能。
|
29天前
|
存储 机器学习/深度学习 应用服务中间件
阿里云倚天云服务器实例:计算型c8y、通用型g8y、内存型r8y实例介绍
阿里云倚天云服务器是基于阿里云自研的倚天710 ARM架构CPU打造的高性能计算产品系列,它依托先进的第四代神龙架构,旨在为用户提供稳定可预期的超高效能体验。倚天云服务器在存储、网络性能及计算稳定性方面实现了显著提升,主要得益于其芯片级的快速路径加速技术。本文将深度解析阿里云倚天云服务器的计算型c8y、通用型g8y、内存型r8y实例,探讨其优势及适用场景,以供选择参考。
|
2月前
|
分布式计算 大数据 数据挖掘
阿里云服务器计算型c8i、通用型g8i、内存型r8i实例测评与价格参考
阿里云服务器计算型c8i、通用型g8i、内存型r8i实例是阿里云的第八代云服务器实例规格,是除了计算型c7和c8y、通用型g7与g8y、内存型r7与r8y之外同样深受用户喜欢的云服务器实例规格。本文将详细介绍阿里云第八代云服务器中的计算型c8i、通用型g8i、以及内存型r8i实例,包括它们的技术特性、适用场景以及最新的活动价格信息。
阿里云服务器计算型c8i、通用型g8i、内存型r8i实例测评与价格参考
|
30天前
|
程序员 编译器 C语言
动态内存分配与管理详解(附加笔试题分析)(下)
动态内存分配与管理详解(附加笔试题分析)(下)
44 2