autorelease探究

简介:

有时候我们需要延迟一个对象的引用计数减一操作,比如:

+ (NSArray *)array
{
    return [[NSArray alloc] init] autorelease];
}

由于方法名并不以alloc, new, copy, mutableCopy开头,并且方法内部使用了alloc,需要对因此产生的引用计数负责。

不过如果直接调用release,将会返回野指针,所以我们需要autorelease机制来延迟释放。


我们需要先创建一个autorelease pool,才能有效地实现autorelease机制,否则会导致内存泄露。

当向一个对象obj发送autorelease消息时,会发生如下过程:

  1. 获取当前autorelease pool,即离事件发生处最近的(inner-most)自动释放池,NSAutoreleasePool实例。
  2. NSAutoreleasePool实例将obj添加到内部维护的数组中,记录起来。
  3. 当发送drain消息给自动释放池时,它会遍历内部维护的数组,向每个元素发送一个release消息。


除了我们显式创建的NSAutoreleasePool实例,系统会默认为我们在主线程创建一个:

@autoreleasepool {
    return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
}

从可见代码来看,这个自动释放池建立在main函数中,对于我们编码过程中创建的自动释放对象有什么帮助呢?

等到结束UIApplicationMain才释放,跟不释放基本没差别,因为程序运行即将结束。

所以,如果事实真相如此,那么是不合理的。


苹果官方文档有这么一段话:

The Application Kit creates an autorelease pool on the main threadat the beginning of every cycle of the event loop, anddrains it at the end, thereby releasing any autoreleased objects generated while processing an event. If you use the Application Kit, you therefore typically don’t have to create your own pools. If your application creates a lot of temporary autoreleased objects within the event loop, however, it may be beneficial to create “local” autorelease pools to help to minimize the peak memory footprint.

可见,在主线程中每个event loop开始的时候会创建一个autorelease pool,在循环结束时清空自动释放池。

当然,如果在某个局部地方创建很多临时对象,最好也显式创建autorelease pool降低内存峰值。

用代码来求证:

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
    TestObject *testObject = [[[TestObject alloc] init] autorelease];
}

- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event
{
    NSLog(@"Touches Ended\n");
    [NSAutoreleasePool showPools];
}

通过在TestObject的release方法中输出日志信息,可以看到testObject是在touchesEnded事件前被释放的,即event loop结束前。


这是对主线程而言,那么对其它线程呢?

下面又有一段说明:

Each thread (including the main thread) maintains its own stack of NSAutoreleasePool objects (see “Threads”). As new pools are created, they get added to the top of the stack. When pools are deallocated, they are removed from the stack. Autoreleased objects are placed into the top autorelease pool for the current thread. When a thread terminates, it automatically drains all of the autorelease pools associated with itself.

从上面这段话可以得知每个线程都维护着与自己对应的NSAutoreleasePool对象,将其放在线程栈的栈顶。当线程结束时,会清空自动释放池。

同样地可以用代码来说明:

[NSThread detachNewThreadSelector:@selector(onNewThread:) toTarget:self withObject:nil];

- (void)onNewThread:(id)info
{
    TestObject *testObject = [[[TestObjectalloc] init] autorelease];
}

通过输出结果也可以得知线程结束时,testObject得到释放。


不过,紧接着的一段说明说明了些例外情况:

If you are making Cocoa calls outside of the Application Kit’s main thread—for example if you create a Foundation-only applicationor if youdetach a thread—you need to create your own autorelease pool.

不过当我detach了多个线程出来,发现每个线程仍然有维护autorelease pool。是不是上面这段话我哪里没理解对?幸好在没有autorelease pool存在时,我们向对象发送autorelease消息会有警告输出。


最后,探讨下NSRunLoop和autorelease的关系。

当我们分离了个线程,并且让runloop跑起来,我们可以发现与主线程类似:每个runloop循环结束时会drain下autorelease pool。

通过观察runloop状态可以验证:

#pragma mark - RunLoop Observer

- (void)onNewThread:(id)info
{
    NSRunLoop *runloop = [NSRunLoop currentRunLoop];
    if (!runloop) {
        return ;
    }
    
    NSTimer *timer = [NSTimer scheduledTimerWithTimeInterval:5.0f target:self selector:@selector(onTimerFired:) userInfo:nil repeats:NO];
    [runloop addTimer:timer forMode:NSRunLoopCommonModes];
    
    CFRunLoopObserverContext context = {
        0,
        self,
        NULL,
        NULL,
        NULL
    };
    
    CFRunLoopObserverRef observerRef = CFRunLoopObserverCreate(kCFAllocatorDefault, kCFRunLoopAllActivities, YES, 0, &runloopObserverCallback, &context);
    CFRunLoopAddObserver([runloop getCFRunLoop], observerRef, kCFRunLoopCommonModes);
    
    [runloop run];
    
    CFRunLoopRemoveObserver([runloop getCFRunLoop], observerRef, kCFRunLoopCommonModes);
    CFRelease(observerRef);
}

static void runloopObserverCallback(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info)
{
    CFRunLoopActivity currentActivity = activity;
    switch (currentActivity) {
        casekCFRunLoopEntry:
            NSLog(@"kCFRunLoopEntry \n");
            break;
            
        casekCFRunLoopBeforeTimers:
            NSLog(@"kCFRunLoopBeforeTimers \n");
            break;
            
        casekCFRunLoopBeforeSources:
            NSLog(@"kCFRunLoopBeforeSources \n");
            break;
            
        casekCFRunLoopBeforeWaiting:
            NSLog(@"kCFRunLoopBeforeWaiting \n");
            break;
            
        casekCFRunLoopAfterWaiting:
            NSLog(@"kCFRunLoopAfterWaiting \n");
            break;
            
        casekCFRunLoopExit:
            NSLog(@"kCFRunLoopExit \n");
            break;
            
        default:
            NSLog(@"Activity not recognized!\n");
            break;
    }
}

--------------------------------------------------

Jason Lee @ Hangzhou

2012.08.15


目录
打赏
0
0
0
0
53
分享
相关文章
一文探究系统分析与设计的逻辑性
「软件分析」与「软件设计」这样的词眼经常听到,然而要真正理解「软件分析」和「软件设计」的本质是比较难的,本文带你了解软件分析与设计的「逻辑性」到底是什么。
1085 25
大模型不会推理,为什么也能有思路?有人把原理搞明白了
大模型(LLMs)在推理任务上表现出与人类不同的问题解决思路。最新研究《Procedural Knowledge in Pretraining Drives Reasoning in Large Language Models》发现,大模型通过合成程序性知识来完成推理任务,而非简单检索答案。这为理解其推理能力提供了新视角,并指出了改进方向,如设计更有效的算法和使用更大规模数据。论文链接:https://arxiv.org/abs/2411.12580。
72 3
深入探讨前端性能优化:从理论到实践
在现代Web开发中,前端性能优化已成为提升用户体验的关键因素。本文将探讨前端性能优化的基本理论,并结合实际案例,深入分析如何通过优化代码、资源管理和用户交互,显著提升网站和应用的响应速度。我们将介绍从理论到实践的多种方法,包括资源压缩、异步加载、缓存机制及工具的使用,帮助开发者构建更加高效和用户友好的前端应用。
第一性原理
第一性原理
122 0
理论与实践:如何写好一个方法
鉴于团队越来越强调开发规范,本人被diss了很多次,haha,为了改变这一现状,总结了一些提升方法代码质量的方法。个人认为一个好的方法主要表现在可读性、可维护性、可复用性上,本文通过设计原则和代码规范两章来讲解如何提高方法的可读性、可维护性、可复用性。这些设计原则和代码规范更多的是表现一种思想,不仅仅可以用在方法上,也可以用在类上、模块上。下面通过具体的例子来讲解。设计原则单一原则单一职责解释是一
83 0
下一篇
oss创建bucket
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等