单例模式

单例模式大概是设计模式中最简单的一个。本来没什么好说的，但是实践过程中还是有一些坑。所以本文小结一下在iOS开发中的单例模式。

一、 什么是单例模式

按照四人帮（GOF）教科书的说法，标准定义是这样的：

1	Ensures a class has only one instance, and provide a global point of access to it.

保证一个类只有一个实例，并且提供一个全局的访问入口访问这个实例。

然后，类图是这个样子的：

单例类图

什么时候选择单例模式呢？

一个类必须只有一个对象。客户端必须通过一个众所周知的入口访问这个对象。

这个唯一的对象需要扩展的时候，只能通过子类化的方式。客户端的代码能够不需要任何修改就能够使用扩展后的对象。

上面的官方说法，听起来一头雾水。我的理解是这样的。

在建模的时候，如果这个东西确实只需要一个对象，多余的对象都是无意义的，那么就考虑用单例模式。比如定位管理（CLLocationManager），硬件设备就只有一个，弄再多的逻辑对象意义不大。所以就会考虑用单例

二、 如何实现基本的单例模式？

那么，我们就用Objective-C来实现一下单例模式吧。

要实现比较好的访问，我们就会想到用工厂方法创建对象，提供统一的创建方法的地方给外部使用。要实现仅有一个对象，就会想到用一个全局的东西保存这个对象，然后在创建对象的工厂方法中判断一下，如果对象存在，那么就返回该对象。如果不存在，就造一个返回出去。

于是，基本的单例实现就这样了：

1 2 3 4 5 6 7

DJSingleton * g_instance_dj_singleton = nil ; + (DJSingleton *)shareInstance{         if (g_instance_dj_singleton == nil) {             g_instance_dj_singleton = [[DJSingleton alloc] init];         }     return (DJSingleton *)g_instance_dj_singleton; }

看起来不错。不过这个全局的变量 g_instance_dj_singleton有个缺点，就是外面的人随便可以改，为了隔离外部修改，可以设置成静态变量，就是这样子：

1 2 3 4 5 6 7

+ (DJSingleton *)shareInstance{          static DJSingleton * s_instance_dj_singleton = nil ;          if (s_instance_dj_singleton == nil) {              s_instance_dj_singleton = [[DJSingleton alloc] init];         }      return (DJSingleton *)s_instance_dj_singleton;  }

单例的核心思想算是实现了。

三、 多线程怎么办？

虽然核心思想实现了，但是依旧不完美。考虑下多线程的情况。即多个线程同时访问这个工厂方法，能够总是保证只创建一个实例对象么？

显然上面的方式是有问题的。比如第一个线程执行到第4行但是还没有进行赋值操作，第二个线程执行第三行。此时判断对象依旧为nil，第二个线程也能往下执行到创建对象操作的第4行。从而创建了多个对象。

那么，如何保证多线程下依旧能够只创建一个呢？这里面的核心思路，是要保证s_instance_dj_singleton这个临界资源的访问（读取和赋值）。

iOS下控制多线程的方式有很多，可以使用NSLock，可以@synchronized等各种线程同步的技术。于是，我们的单例代码变成了这样：

1 2 3 4 5 6 7 8 9

+ (DJSingleton *)shareInstance{          static DJSingleton * s_instance_dj_singleton = nil ;           @synchronized(self) {                 if (s_instance_dj_singleton == nil) {                    s_instance_dj_singleton = [[DJSingleton alloc] init];                }             }          return (DJSingleton *)s_instance_dj_singleton;  }

看起来多线程没啥问题了了。不过我们可以做的更好。OC的内部机制里有一种更加高效的方式，那就是dispatch_once。性能相差好几倍，好几十倍。关于性能的比对，大神们做过实验和分析。请参考这里。

于是，我们的单例变成了这个样子：

1 2 3 4 5 6 7 8 9 10

+ (DJSingleton *)shareInstance{     static DJSingleton * s_instance_dj_singleton = nil ;     static dispatch_once_t onceToken;     dispatch_once(&onceToken, ^{         if (s_instance_dj_manager == nil) {             s_instance_dj_manager = [[DJSingleton alloc] init];         }     });     return (DJSingleton *)s_instance_dj_singleton; }

四、Objective-C的坑

看起来很完美了。可是Objective-C毕竟是Objective-C。别的语言，诸如C++，java，构造方法可以隐藏。Objective-C中的方法，实际上都是公开的，虽然我们提供了一个方便的工厂方法的访问入口，但是里面的alloc方法依旧是可见的，可以调用到的。也就是说，虽然你给了我一个工厂方法，调皮的小伙伴可能依旧会使用alloc的方式创建对象。这样会导致外面使用的时候，依旧可能创建多个实例。

关于这个事情的处理，可以分为两派。一个是冷酷派，技术上实现无论你怎么调用，我都给你同一个单例对象；一个是温柔派，是从编译器上给调皮的小伙伴提示，你不能这么造对象，温柔的指出有问题，但不强制约束。

1. 冷酷派的实现

冷酷派的实现从OC的对象创建角度出发，就是把创建对象的各种入口给封死了。alloc，copy等等，无论是采用哪种方式创建，我都保证给出的对象是同一个。

由Objective-C的一些特性可以知道，在对象创建的时候，无论是alloc还是new，都会调用到 allocWithZone方法。在通过拷贝的时候创建对象时，会调用到-(id)copyWithZone:(NSZone *)zone，-(id)mutableCopyWithZone:(NSZone *)zone方法。因此，可以重写这些方法，让创建的对象唯一。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

+(id)allocWithZone:(NSZone *)zone{     return [DJSingleton sharedInstance]; } +(DJSingleton *) sharedInstance{     static DJSingleton * s_instance_dj_singleton = nil;     static dispatch_once_t onceToken;     dispatch_once(&onceToken, ^{         s_instance_dj_singleton = [[super allocWithZone:nil] init];     });     return s_instance_dj_singleton; } -(id)copyWithZone:(NSZone *)zone{     return [DJSingleton sharedInstance]; } -(id)mutableCopyWithZone:(NSZone *)zone{     return [DJSingleton sharedInstance]; }

2. 温柔派的实现

温柔派就直接告诉外面，alloc，new，copy，mutableCopy方法不可以直接调用。否则编译不过。

1 2 3 4

+(instancetype) alloc __attribute__((unavailable("call sharedInstance instead"))); +(instancetype) new __attribute__((unavailable("call sharedInstance instead"))); -(instancetype) copy __attribute__((unavailable("call sharedInstance instead"))); -(instancetype) mutableCopy __attribute__((unavailable("call sharedInstance instead")));

我个人的话比较喜欢采用温柔派的实现。不需要这么多复杂的实现。也让使用方有比较明确的概念这个是个单例，不要调皮。对于一般的业务场景是足够了的。

五、 可不可以再方便点？

可以。

大神们把单例模式的各种套路封装成了宏。这样使用的时候，就不需要每个类都手动写一遍里面的重复代码了。省去了敲代码的时间。

以温柔派的为例，大概是这样子的。

1 2 3 4 5 6 7 8 9 10 11 12 13

#define DJ_SINGLETON_DEF(_type_) + (_type_ *)sharedInstance; +(instancetype) alloc __attribute__((unavailable("call sharedInstance instead"))); +(instancetype) new __attribute__((unavailable("call sharedInstance instead"))); -(instancetype) copy __attribute__((unavailable("call sharedInstance instead"))); -(instancetype) mutableCopy __attribute__((unavailable("call sharedInstance instead"))); #define DJ_SINGLETON_IMP(_type_) + (_type_ *)sharedInstance{ static _type_ *theSharedInstance = nil; static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ theSharedInstance = [[super alloc] init]; }); return theSharedInstance; }

那么，在定义和实现的时候就很简单了：

1 2 3 4 5 6

@interface DJSingleton : NSObject     DJ_SINGLETON_DEF(DJSingleton); @end @implementation DJSingleton     DJ_SINGLETON_IMP(DJSingleton); @end

六、 单例模式潜在的问题

1. 内存问题

单例模式实际上延长了对象的生命周期。那么就存在内存问题。因为这个对象在程序的整个生命都存在。所以当这个单例比较大的时候，总是hold住那么多内存，就需要考虑这件事了。另外，可能单例本身并不大，但是它如果强引用了另外的比较大的对象，也算是一个问题。别的对象因为单例对象不释放而不释放。

当然这个问题也有一定的办法。比如对于一些可以重新加载的对象，在需要的时候加载，用完之后，单例对象就不再强引用，从而把原先hold住的对象释放掉。下次需要再加载回来。

2. 循环依赖问题

在开发过程中，单例对象可能有一些属性，一般会放在init的时候创建和初始化。这样，比如如果单例A的m属性依赖于单例B，单例B的属性n依赖于单例A，初始化的时候就会出现死循环依赖。死在dispatch_once里。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

@interface DJSingletonA : NSObject     DJ_SINGLETON_DEF(DJSingletonA); @end @interface DJSingletonB : NSObject     DJ_SINGLETON_DEF(DJSingletonB); @end @interface DJSingletonA() @property(nonatomic, strong) id someObj; @end @implementation DJSingletonA DJ_SINGLETON_IMP(DJSingletonA); -(id)init{     if (self = [super init]) {         _someObj = [DJSingletonB sharedInstance];     }     return self; } @end @interface DJSingletonB() @property(nonatomic, strong) id someObj; @end @implementation DJSingletonB DJ_SINGLETON_IMP(DJSingletonB); -(id)init{     if (self = [super init]) {         _someObj = [DJSingletonA sharedInstance];     }     return self; } @end //--------------------------------------- DJSingletonA * s1 = [DJSingletonA sharedInstance];

死亡现场

对于这种情况，最好的设计是在单例设计的时候，初始化的内容不要依赖于其他对象。如果实在要依赖，就不要让它形成环。实在会形成环或者无法控制，就采用异步初始化的方式。先过去，内容以后再填。内部需要做个标识，标识这个单例在造出来之后，不能立刻使用或者完整使用。