OC基础-单例的实现 & 提醒自己注意多线程问题

栏目: IOS · 发布时间: 5年前

内容简介:做客户端开发应当时刻考虑多线程问题。我最初是做前端开发的,在这方面考虑得往往不够。谨记。单例的常见写法其实就两种dispatch_once的写法更推荐一些。一方面是性能上好一点,另一方面是语义上更直观。once,执行一次嘛。

做客户端开发应当时刻考虑多线程问题。我最初是做前端开发的,在这方面考虑得往往不够。谨记。

单例的常见写法

单例的常见写法其实就两种

1. 依赖锁

+ (id)sharedInstance {  
    static testClass *sharedInstance = nil;  
    @synchronized(self) {  
        if (!sharedInstance) {  
            sharedInstance = [[self alloc] init];  
        }  
    }  
    return sharedInstance;  
}

2. 依赖dispatch_once

+ (id)sharedInstance {  
    static testClass *sharedInstance = nil;  
    static dispatch_once_t once;  
    dispatch_once(&once, ^{  
        sharedInstance = [[self alloc] init];  
    });  
    return sharedInstance;  
}

dispatch_once的写法更推荐一些。一方面是性能上好一点,另一方面是语义上更直观。once,执行一次嘛。

不管是用锁还是dispatch_once,本质上都是为了避免单例创建过程出现线程安全问题。

更进一步,我们经常会有懒加载某些属性的写法:

- (id<InterfaceEngineA>)engineA
{
    if (_engineA == nil) {
        _engineA = [EngineA new];
    }
    
    return _engineA;
}

其实跟单例的实现是类似的,这种时候要格外注意线程安全问题。如果存在多线程场景,一定要做好保护

- (id<InterfaceEngineA>)engineA
{
    @synchronized(self) {
        if (_engineA == nil) {
            _engineA = [EngineA new];
        }
    }
    return _engineA;
}

一些废话

多线程问题的表现可能是各种各样难以预料的。这里我遇到的是,_engineA在多线程场景下小概率被重复创建,其实例1在init时注册了网络层命令字 cmd1 的回包,而这个网络层框架的实现是,只接受第一个注册这一命令字的对象。导致实例2注册失败。后面调用实例2发送请求,回包都被实例1接收了。从日志上看,一切都挺正常的。但是下次取数据就是取不到。

这个bug第一次提过来的时候,没分析出根本原因,只在表面上做了保护。结果第二次提过来才真正改掉。

丢人呐。还是要好好学习才是。


以上所述就是小编给大家介绍的《OC基础-单例的实现 & 提醒自己注意多线程问题》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

深入理解LINUX网络技术内幕

深入理解LINUX网络技术内幕

Christian Benvenuti / 夏安、闫江毓、黄景昌 / 中国电力出版社 / 2009-6 / 128.00元

Linux如此的流行正是得益于它的特性丰富及有效的网络协议栈。如果你曾经惊叹于Linux能够实现如此复杂的工作,或者你只是想通过现实中的例子学习现代网络,《深入理解Linux网络内幕》将会给你指导。同其他O'Reilly的流行书籍一样,《深入理解Linux网络内幕》清楚地阐述了网络的基本概念,并指导你如何用C语言实现。虽然早先的 TCP/IP经验是有用的,但初学者通过《深入理解Linux网络内幕》......一起来看看 《深入理解LINUX网络技术内幕》 这本书的介绍吧!

图片转BASE64编码
图片转BASE64编码

在线图片转Base64编码工具

Markdown 在线编辑器
Markdown 在线编辑器

Markdown 在线编辑器