是否需要释放Objective-c 2.0属性的内存？

Something I have been wondering about properties for a while. When you are using properties, do you need to override the release message to ensure the properties are released properties?

我一直想知道房产的一些事情。使用属性时,是否需要覆盖发布消息以确保属性是已发布的属性?

i.e. is the following (fictitious) example sufficient?

即以下(虚构)示例是否足够?

@interface MyList : NSObject {
NSString* operation;
NSString* link;
}
@property (retain) NSString* operation;
@property (retain) NSString* link;
@end

@implementation MyList
@synthesize operation,link;
@end

6 个解决方案

#1

You should always release the backing variables in dealloc:

您应该始终在dealloc中释放支持变量:

- (void) dealloc {
   [operation release];
   [link release];

   [super dealloc];
}

Another way:

- (void) dealloc {
   self.operation = nil;
   self.link = nil;

   [super dealloc];
}

That's not the preferred way of releasing the objects, but in case you're using synthesized backing variables, it's the only way to do it.

这不是释放对象的首选方式,但如果您使用的是合成后备变量,那么这是唯一的方法。

NOTE: to make it clear why this works, let's look at the synthesized implementation of the setter for link property, and what happens when it is set to nil:

注意:为了清楚说明为什么这样做,让我们看看为链接属性设置setter的综合实现,以及当它设置为nil时会发生什么:

- (void) setLink:(MyClass *) value {
   [value retain]; // calls [nil retain], which does nothing
   [link release]; // releases the backing variable (ivar)
   link = value;   // sets the backing variable (ivar) to nil
}

So the net effect is that it will release the ivar.

因此净效应是它将释放伊娃。

#2

In non-GC applications, yes. It is usual to assign nil instead of releasing the ivars. My best experience is to release ivars initialized with init and assign nil to properties with retain and copy mode.

在非GC应用程序中,是的。通常指定nil而不是释放ivars。我最好的经验是发布用init初始化的ivars,并将nil分配给具有保留和复制模式的属性。

In your case I would assign nil

在你的情况下,我会指定为零

- (void) dealloc {
   self.operation = nil;
   self.link = nil;
   [super dealloc];
}

#3

The best way to do this is:

最好的方法是:

- (void)dealloc {
    [operation release], operation = nil;
    [link release], link = nil;

    [super dealloc];
}

It would indeed be more convenient to use the generated setter methods

使用生成的setter方法确实更方便

self.operation = nil;

but that is frowned upon. You don't always know which thread an object is deallocated on. Thus using an accessor may cause problems by triggering KVO notifications.

但这令人不悦。您并不总是知道对象被解除分配的线程。因此,使用访问器可能会通过触发KVO通知而导致问题。

The catch here is that you need to adapt your dealloc to match the object management policy defined in your @property. E.g. don't go releasing a iVar backing an (assign) property.

这里的问题是您需要调整dealloc以匹配@property中定义的对象管理策略。例如。不要发布支持(assign)属性的iVar。

#4

No, you override the -dealloc method. And yes, if you don't release your properties (or rather, the backing ivars), you will leak. So in your @implementation here you should have something like

不,您覆盖-dealloc方法。是的,如果你不释放你的属性(或者更确切地说,支持ivars),你就会泄漏。所以在你的@implementation中你应该有类似的东西

- (void)dealloc {
    [operation release];
    [link release];
    [super dealloc];
}

#5

Synthesizing a property only creates getter and setter methods, and therefor won't release the ivar when the object is deallocated. You need to release the ivar yourself.

合成属性只会创建getter和setter方法,因此在取消分配对象时不会释放ivar。你需要自己释放ivar。

#6

In pre-ARC whenever you see new, alloc, retain and copy, whether it is an instance var or a property you must release. In ARC whenever you have a strong variable you must set it to nil. In either case you have to override dealloc().

无论何时看到新的,分配,保留和复制,无论是实例var还是必须释放的属性,在ARC之前。在ARC中,只要有强变量,就必须将其设置为nil。在任何一种情况下,您都必须覆盖dealloc()。

#1