文档章节

__weak 修饰符

lightUp
 lightUp
发布于 2015/06/02 19:12
字数 3100
阅读 13123
收藏 7

就像前面我们看到的一样,__weak 修饰符提供的功能如同魔法一般。


1,若附有__weak 修饰符的变量所引用的对象被废弃,则将nil 赋值给该变量。

2,使用附有__weak 修饰符的变量,即是使用注册到autoreleasepool 中的对象。


1,若附有__weak 修饰符的变量所引用的对象被废弃,则将nil 赋值给该变量。

这些功能像魔法一样,到底发生了什么,我们一无所知。所以下面我们来看看它们的实现。

{   
     id __weak obj1 = obj;
}

假设变量obj 附加__strong 修饰符且对象被赋值。

/* 编译器的模拟代码 */
id obj1;
objc_initWeak(&obj1, obj);
objc_destroyWeak(&obj1);

通过objc_initWeak 函数初始化附有_ _ weak 修饰符的变量,在变量作用域结束时通过objc_destroyWeak 函数释放该变量。

如以下源代码所示,objc_initWeak 函数将附有_ _ weak 修饰符的变量初始化为0 后,会将赋值的对象作为参数调用objc_storeWeak 函数。

obj1 = 0;
objc_storeWeak(&obj1, obj);

//objc_destroyWeak 函数将0 作为参数调用objc_storeWeak 函数。
objc_storeWeak(&obj1, 0);

即前面的源代码与下列源代码相同。

/* 编译器的模拟代码 */
id obj1;obj1 = 0;
objc_storeWeak(&obj1, obj);
objc_storeWeak(&obj1, 0);

objc_storeWeak 函数把第二参数的赋值对象的地址作为键值,将第一参数的附有_ _ weak 修饰符的变量的地址注册到weak 表中。

如果第二参数为0,则把变量的地址从weak 表中删除。

weak 表与引用计数表(参考1.2.4 节)相同,作为散列表被实现。如果使用weak 表,将废弃对象的地址作为键值进行检索,就能高速地获取对应的附有_ _ weak 修饰符的变量的地址。

另外,由于一个对象可同时赋值给多个附有_ _ weak 修饰符的变量中,所以对于一个键值,可注册多个(weak)变量的地址。

释放对象时,废弃谁都不持有的对象的同时,程序的动作是怎样的呢?下面我们来跟踪观察。对象将通过objc_release 函数释放。

(1)objc_release

(2)因为引用计数为0 所以执行dealloc

(3)_objc_rootDealloc

(4)object_dispose

(5)objc_destructInstance

(6)objc_clear_deallocating

对象被废弃时最后调用的objc_clear_deallocating 函数的动作如下:

  1. (1)从weak 表中获取废弃对象的地址为键值的记录。

  2. (2)将包含在记录中的所有附有_ _ weak 修饰符变量的地址,赋值为nil。

  3. (3)从weak 表中删除该记录。

  4. (4)从引用计数表中删除废弃对象的地址为键值的记录。


根据以上步骤,前面说的如果附有_ _ weak 修饰符的变量所引用的对象被废弃,则将nil 赋值给该变量这一功能即被实现。由此可知,如果大量使用附有_ _ weak 修饰符的变量,则会消耗相应的CPU 资源。良策是只在需要避免循环引用时使用_ _ weak 修饰符。

使用_ _ weak 修饰符时,以下源代码会引起编译器警告。

{
    id __weak obj = [[NSObject alloc] init];
}


因为该源代码将自己生成并持有的对象赋值给附有_ _ weak 修饰符的变量中,所以自己不能持有该对象,这时会被释放并被废弃,因此会引起编译器警告。

warning: assigning retained obj to weak variable; obj will be
      released after assignment [-Warc-unsafe-retained-assign]
        id __weak obj = [[NSObject alloc] init];
                  ^     ~~~~~~~~~~~~~~


编译器如何处理该源代码呢?

/* 编译器的模拟代码 */
id obj;
id tmp = objc_msgSend(NSObject, @selector(alloc));
objc_msgSend(tmp, @selector(init));
objc_initWeak(&obj, tmp);
objc_release(tmp); // 因为此时只有一个强引用,所以对象被释放了
objc_destroyWeak(&object);

虽然自己生成并持有的对象通过objc_initWeak 函数被赋值给附有_ _ weak 修饰符的变量中,但编译器判断其没有持有者(即 强引用),故该对象立即通过objc_release 函数被释放和废弃。

这样一来,nil 就会被赋值给引用废弃对象的附有_ _ weak 修饰符的变量中。

下面我们通过NSLog 函数来验证一下。

{
    id __weak obj = [[NSObject alloc] init];
    NSLog(@"obj=%@", obj);
}


以下为该源代码的输出结果,其中用%@ 输出nil。

obj=(null)


关于“立即释放对象”

如前所述,以下源代码会引起编译器警告。

id __weak obj = [[NSObject alloc] init];


这是由于编译器判断生成并持有的对象不能继续持有。附有__unsafe_unretained修饰符的变量又如何呢?

id __unsafe_unretained obj = [[NSObject alloc] init];


与__weak修饰符完全相同,编译器判断生成并持有的对象不能继续持有,从而发出警告。
warning: assigning retained object to unsafe_unretained variable;
      obj will be released after assignment [-Warc-unsafe-retained-assign]
    id __unsafe_unretained obj = [[NSObject alloc] init];
                           ^     ~~~~~~~~~~~~~~~~~~~~~~~

该源代码通过编译器转换为以下形式。

/* 编译器的模拟代码 */
id obj = objc_msgSend(NSObject, @selector(alloc));
objc_msgSend(obj, @selector(init));
objc_release(obj);


objc_release函数立即释放了生成并持有的对象,这样该对象的悬垂指针被赋值给变量obj中。

那么如果最初不赋值变量又会如何呢?下面的源代码在ARC无效时必定会发生内存泄漏。
[[NSObject alloc] init];

由于源代码不使用返回值的对象,所以编译器发出警告。
warning: expression result unused [-Wunused-value]
    [[NSObject alloc] init];
    ^~~~~~~~~~~~~~~~~~~~~~~

可像下面这样通过向void型转换来避免发生警告。
(void)[[NSObject alloc] init];

不管是否转换为void,该源代码都会转换为以下形式
/* 编译器的模拟代码 */
id tmp = objc_msgSend(NSObject, @selector(alloc));
objc_msgSend(tmp, @selector(init));
objc_release(tmp);

虽然没有指定赋值变量,但与赋值给附有__unsafe_unretained修饰符变量的源代码完全相同。由于不能继续持有生成并持有的对象,所以编译器生成了立即调用objc_release函数的源代码。而由于ARC的处理,这样的源代码也不会造成内存泄漏。

另外,能调用被立即释放的对象的实例方法吗?
(void)[[[NSObject alloc] init] hash];

该源代码可变为如下形式:
/* 编译器的模拟代码 */
id tmp = objc_msgSend(NSObject, @selector(alloc));
objc_msgSend(tmp, @selector(init));
objc_msgSend(tmp, @selector(hash));
objc_release(tmp);

在调用了生成并持有对象的实例方法后,该对象被释放。看来“由编译器进行内存管理”这句话应该是正确的。

2,这次我们再用附有_ _ weak 修饰符的变量来确认另一功能:使用附有_ _ weak 修饰符的变量,即是使用注册到autoreleasepool 中的对象。

{
    id __weak obj1 = obj;
    NSLog(@"%@", obj1);
}


该源代码可转换为如下形式:

/* 编译器的模拟代码 */
id obj1;
objc_initWeak(&obj1, obj);
id tmp = objc_loadWeakRetained(&obj1);
objc_autorelease(tmp);
NSLog(@"%@", tmp);
objc_destroyWeak(&obj1);


被赋值时相比,在使用附有_ _ weak 修饰符变量的情形下,增加了对objc_loadWeakRetained函数和objc_autorelease 函数的调用。这些函数的动作如下。

(1)objc_loadWeakRetained 函数取出附有_ _ weak 修饰符变量所引用的对象并retain

(2)objc_autorelease 函数将对象注册到autoreleasepool 中。

由此可知,因为附有_ _ weak 修饰符变量所引用的对象像这样被注册到autoreleasepool 中,所以在@autoreleasepool 块结束之前都可以放心使用。但是,如果大量地使用附有_ _ weak 修饰符的变量,注册到autoreleasepool 的对象也会大量地增加,因此在使用附有_ _ weak 修饰符的变量时,最好先暂时赋值给附有_ _ strong 修饰符的变量后再使用。

比如,以下源代码使用了5 次附有_ _ weak 修饰符的变量o。

{
    id __weak o = obj;
    NSLog(@"1 %@", o);
    NSLog(@"2 %@", o);
    NSLog(@"3 %@", o);
    NSLog(@"4 %@", o);
    NSLog(@"5 %@", o);
}


相应地,变量o 所赋值的对象也就注册到autoreleasepool 中5 次。

objc[14481]: ##############
objc[14481]: AUTORELEASE POOLS for thread 0xad0892c0
objc[14481]: 6 releases pending.
objc[14481]: [0x6a85000]  ................  PAGE  (hot) (cold)
objc[14481]: [0x6a85028]  ################  POOL 0x6a85028
objc[14481]: [0x6a8502c]         0x6719e40  NSObject
objc[14481]: [0x6a85030]         0x6719e40  NSObject
objc[14481]: [0x6a85034]         0x6719e40  NSObject
objc[14481]:  [0x6a85038]         0x6719e40  NSObject
objc[14481]: [0x6a8503c]         0x6719e40  NSObject
objc[14481]: ##############


将附有_ _ w e a k 修饰符的变量o 赋值给附有_ _ s t r o n g 修饰符的变量后再使用可以避免此类问题。

{
    id __weak o = obj;
    id tmp = o;
    NSLog(@"1 %@", tmp);
    NSLog(@"2 %@", tmp);
    NSLog(@"3 %@", tmp);
    NSLog(@"4 %@", tmp);
    NSLog(@"5 %@", tmp);
}

“tmp = o;”时对象仅登录到autoreleasepool 中1 次。

objc[14481]: ##############
objc[14481]: AUTORELEASE POOLS for thread 0xad0892c0
objc[14481]: 2 releases pending.
objc[14481]: [0x6a85000]  ................  PAGE  (hot) (cold)
objc[14481]: [0x6a85028]  ################  POOL 0x6a85028
objc[14481]: [0x6a8502c]         0x6719e40  NSObject
objc[14481]: ##############


在iOS4 和OS  X  Snow  Leopard 中是不能使用_ _ weak 修饰符的,而有时在其他环境下也不能使用。实际上存在着不支持_ _ weak 修饰符的类。

例如NSMachPort 类就是不支持_ _ weak 修饰符的类。这些类重写了retain/release 并实现该类独自的引用计数机制。但是赋值以及使用附有_ _ weak 修饰符的变量都必须恰当地使用objc4运行时库中的函数,因此独自实现引用计数机制的类大多不支持_ _ weak 修饰符。

不支持_ _ weak 修饰符的类,其类声明中附加了“_ _ attribute_ _ ((objc_arc_weak_reference_unavailable))”这一属性,同时定义了NS_AUTOMATED_REFCOUNT_WEAK_UNAVAILABLE。

如果将不支持_ _ weak 声明类的对象赋值给附有_ _ weak 修饰符的变量,那么一旦编译器检验出来就会报告编译错误。而且在Cocoa 框架类中,不支持_ _ weak 修饰符的类极为罕见,因此没有必要太过担心。

专栏allowsWeakReference/retainWeakReference 方法实际上还有一种情况也不能使用__weak修饰符。

就是当allowsWeakReference/retainWeakReference实例方法(没有写入NSObject接口说明文档中)返回NO的情况。这些方法的声明如下:
- (BOOL)allowsWeakReference;
- (BOOL)retainWeakReference;

在赋值给__weak修饰符的变量时,如果赋值对象的allowsWeakReference方法返回NO,程序将异常终止。

cannot form weak reference to instance (0x753e180) of class MyObject即对于所有allowsWeakReference方法返回NO的类都绝对不能使用__weak修饰符。这样的类必定在其参考说明中有所记述。

另外,在使用__weak修饰符的变量时,当被赋值对象的retainWeakReference方法返回NO的情况下,该变量将使用“nil”。如以下的源代码:

{
    id __strong obj = [[NSObjectalloc] init];
    id __weak o = obj;
    NSLog(@"1 %@", o);
    NSLog(@"2 %@", o);
    NSLog(@"3 %@", o);
    NSLog(@"4 %@", o);
    NSLog(@"5 %@", o);
}


由于最开始生成并持有的对象为附有__strong修饰符变量obj所持有的强引用,所以在该变量作用域结束之前都始终存在。因此如下所示,在变量作用域结束之前,可以持续使用附有__weak修饰符的变量o所引用的对象。
1 <NSObject: 0x753e180>
2 <NSObject: 0x753e180>
3 <NSObject: 0x753e180>
4 <NSObject: 0x753e180>
5 <NSObject: 0x753e180>

下面对retainWeakReference方法进行试验。我们做一个MyObject类,让其继承NSObject类并实现retainWeakReference方法。

@interfaceMyObject : NSObject
{
    NSUInteger count;
}
@end

@implementationMyObject
- (id)init
{
    self = [super init];
    return self;
}

- (BOOL)retainWeakReference
{
    if (++count > 3)
        return NO;
    return [super retainWeakReference];
}

@end


该例中,当retainWeakReference方法被调用4次或4次以上时返回NO。在之前的源代码中,将从NSObject类生成并持有对象的部分更改为MyObject类。
{
    id __strong obj = [[MyObject alloc] init];
    id __weak o = obj;
    NSLog(@"1 %@", o);
    NSLog(@"2 %@", o);
    NSLog(@"3 %@", o);
    NSLog(@"4 %@", o);
    NSLog(@"5 %@", o);
}
以下为执行结果。
1 <MyObject: 0x753e180>
2 <MyObject: 0x753e180>
3 <MyObject: 0x753e180>
4 (null)
5 (null)
从第4次起,使用附有__weak修饰符的变量o时,由于所引用对象的retainWeakRef-erence方法返回NO,所以无法获取对象。像这样的类也必定在其参考说明中有所记述。

另外,运行时库为了操作__weak修饰符在执行过程中调用allowsWeakReference/retainWeakReference方法,因此从该方法中再次操作运行时库时,其操作内容会永久等待。原本这些方法并没有记入文档,因此应用程序编程人员不可能实现该方法群,但如果因某些原因而不得不实现,那么还是在全部理解的基础上实现比较好。



本文转载自:http://book.2cto.com/201305/23869.html

上一篇: dispatch_sync
lightUp
粉丝 11
博文 242
码字总数 287936
作品 0
杭州
程序员
私信 提问
加载中

评论(1)

yinxu
yinxu
介绍的很好 尽然没赞
__weak与__block修饰符到底有什么区别

API Reference对block变量修饰符有如下几处解释: 大概意思归结出来就是两点: 1.block对象在block中是可以被修改、重新赋值的。 2.block对象在block中不会被block强引用一次,从而不会出现循...

xiao理想
2016/07/20
14
0
Objective-C高级编程之引用计数,看我就够了

自动引用计数.png 1.1 什么是自动引用计数 概念:在 LLVM 编译器中设置 ARC(Automaitc Reference Counting) 为有效状态,就无需再次键入 或 代码。 1.2 内存管理 / 引用计数 1.2.1 概要 引用...

shenglanya
2017/12/19
0
0
Objective-C高级编程笔记一(自动引用计数)

示例代码下载 手动引用计数 MRC内存管理的思考方式 自己生成的对象自己持有 不是自己生成的对象,自己也能持有 不在需要自己持有的对象时释放 不是自己持有的对象无法释放 对象操作与Objecti...

酒茶白开水
04/04
0
0
iOS Objective-C 高级编程

iOS 所有权修饰符 strong, weak, unsafeunretained, _autoreleasing 这些修饰符,只有在 ARC 打开的时候才会用到 内存管理规则: 1. 自己生成的对象,自己所持有 2. 非自己生成的对象,自己也...

iOS_愛OS
2018/07/27
0
0
iOS内存管理知识点

PART1: ARC的修饰符 ARC主要提供了4种修饰符,他们分别是: strong 表示引用为强引用。对应在定义property时的"strong"。所有对象只有当没有任何一个强引用指向时,才会被释放。 注意:如果在...

Sunxb
2017/09/11
0
0

没有更多内容

加载失败,请刷新页面

加载更多

Angular 英雄编辑器

应用程序现在有了基本的标题。 接下来你要创建一个新的组件来显示英雄信息并且把这个组件放到应用程序的外壳里去。 创建英雄组件 使用 Angular CLI 创建一个名为 heroes 的新组件。 ng gener...

honeymoose
今天
4
0
Kernel DMA

为什么会有DMA(直接内存访问)?我们知道通常情况下,内存数据跟外设之间的通信是通过cpu来传递的。cpu运行io指令将数据从内存拷贝到外设的io端口,或者从外设的io端口拷贝到内存。由于外设...

yepanl
今天
6
0
hive

一、hive的定义: Hive是一个SQL解析引擎,将SQL语句转译成MR Job,然后再在Hadoop平台上运行,达到快速开发的目的 Hive中的表是纯逻辑表,就只是表的定义,即表的元数据。本质就是Hadoop的目...

霉男纸
今天
3
0
二、Spring Cloud—Eureka(Greenwich.SR1)

注:本系列文章所用工具及版本如下:开发工具(IDEA 2018.3.5),Spring Boot(2.1.3.RELEASE),Spring Cloud(Greenwich.SR1),Maven(3.6.0),JDK(1.8) Eureka: Eureka是Netflix开发...

倪伟伟
昨天
13
0
eclipse常用插件

amaterasUML https://takezoe.github.io/amateras-update-site/ https://github.com/takezoe/amateras-modeler modelGoon https://www.cnblogs.com/aademeng/articles/6890266.html......

大头鬼_yc
昨天
5
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部