导语
单例（Singletons），是Cocoa的核心模式之一。在iOS上，单例十分常见，比如：UIApplication，NSFileManager等等。虽然它们用起来十分方便，但实际上它们有许多问题需要注意。所以在你下次自动补全dispatch_once代码片段的时候，想一下这样会导致什么后果。因为本人在使用单例过程中碰到过许多坑，希望大家慎用！
什么是单例
在《设计模式》一书中给出了单例的定义：
单例模式：保证一个类仅有一个实例，并提供一个访问它的全局访问点。
单例模式提供了一个访问点，供客户类为共享资源生成唯一实例，并通过它来对共享资源进行访问，这一模式提供了灵活性。
在objective-c中，可以使用以下代码创建一个单例：
+(instancetype)sharedInstance
{
static dispatch_once_t once;
static id sharedInstance;
dispatch_once(&once, ^{
sharedInstance = [[self alloc]init];
});
return sharedInstance;
}
当类只能有一个实例，而且必须从一个访问点对其进行访问时使用单例就显得十分方便，因为使用单例保证了访问点的唯一、一致且为人熟知。
单例中的问题
全局状态
首先我们都应该达成一个共识“全局可变状态”是危险的，因为这样会让程序变得难以理解和调试，就削减状态性代码上，面向对象编程应该向函数式编程学习。
比如下面的代码：
@implementation Math{
NSUInteger _a;
NSUInteger _b;
}
-(NSUInteger)computeSum {
return _a + _b;
}
这段代码想要计算_a和_B相加的和，并返回。但事实上这段代码存在着不少问题：
1.computeSum方法中并没有把_a和_b作为参数。相比查找interface并了解哪个变量控制方法的输出，查找implementation来了解显得更隐蔽，而隐蔽代表着容易发生错误。
2.当准备修改_a和_b的值来让它们调用computeSum方法的时候，程序员必清楚修改它们的值不会影响其他包含着两个值的代码的正确性，而在多线程的情况下作出这样的判断显得尤其困难。
对比下面这段代码：
+(NSUInteger)computeSumOf:(NSUInteger)a plus:(NSUInteger)b {
return a + b;
}
这段代码中，a和b的从属显得十分清晰，不再需要去改变实例的状态来调用这个方法，而且不用担心调用这个方法的副作用。
那这个例子和单例又有什么关系呢？事实上，单例就是披着羊皮的全局状态。一个单例可以在任何地方被使用，而且不用清晰地声明从属。程序中的任何模块都可以简单的调用[MySingleton sharedInstance]，然后拿到这个单例的访问点，这意味着任何和单例交互时产生的副作用都会有可能影响程序中随机的一段代码，如：
@interface MySingleton : NSObject
+(instancetype)sharedInstance;
-(NSUInteger)badMutableState;
-(void)setBadMutableState:(NSUInteger)badMutableState;
@end
@implementation ConsumerA
-(void)someMethod {
if([[MySingleton sharedInstance] badMutableState]){
//do something...
}
}
@end
@implementation ConsumerB
-(void)someOtherMethod {
[[MySingleton sharedInstance] setBadMutableState:0];
}
在上面的代码中，ConsumerA和ComsumerB是程序中两个完全独立的模块，但是ComsumerB中的方法会影响到ComsumerA中的行为，因为这个状态的改变通过单例传递了过去。
在这段代码，正是因为单例的全局性和状态性，导致了ComsumerA和ComsumerB这两个看起来似乎毫无关系的模块之间隐含的耦合。
对象生命周期
另外一个关键问题就是单例的生命周期。
当你在程序中添加一个单例时，很容易会认为 “永远只会有一个实例”。但是在很多我看到过的 iOS 代码中，这种假定都可能被打破。
比如，假设我们正在构建一个应用，在这个应用里用户可以看到他们的好友列表。他们的每个朋友都有一张个人信息的图片，并且我们想使我们的应用能够下载并且在设备上缓存这些图片。 使用 dispatch_once 代码片段，我们可以写一个 SPThumbnailCache 单例：
@interface SPThumbnailCache : NSObject
+ (instancetype)sharedThumbnailCache;
- (void)cacheProfileImage:(NSData *)imageData forUserId:(NSString *)userId;
- (NSData *)cachedProfileImageForUserId:(NSString *)userId;
@end
我们继续构建我们的应用，一切看起来都很正常，直到有一天，我们决定去实现‘注销’功能，这样用户可以在应用中进行账号切换。突然我们发现我们将要面临一个讨厌的问题：用户相关的状态存储在全局单例中。当用户注销后，我们希望能够清理掉所有的硬盘上的持久化状态。否则，我们将会把这些被遗弃的数据残留在用户的设备上，浪费宝贵的硬盘空间。对于用户登出又登录了一个新的账号这种情况，我们也想能够对这个新用户使用一个全新的 SPThumbnailCache 实例。
问题在于按照定义单例被认为是“创建一次，永久有效”的实例。你可以想到一些对于上述问题的解决方案。或许我们可以在用户登出时移除这个单例：
static SPThumbnailCache *sharedThumbnailCache;
+ (instancetype)sharedThumbnailCache
{
if (!sharedThumbnailCache) {
sharedThumbnailCache = [[self alloc] init];
}
return sharedThumbnailCache;
}
+ (void)tearDown
{
// The SPThumbnailCache will clean up persistent states when deallocated
sharedThumbnailCache = nil;
}
这是一个明显的对单例模式的滥用，但是它可以工作，对吧？
我们当然可以使用这种方式去解决，但是代价实在是太大了。我们不能使用简单的的 dispatch_once 方案了，而这个方案能够保证线程安全以及所有调用 [SPThumbnailCache sharedThumbnailCache] 的地方都能访问到同一个实例。现在我们需要对使用缩略图 cache 的代码的执行顺序非常小心。假设当用户正在执行登出操作时，有一些后台任务正在执行把图片保存到缓存中的操作:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[[SPThumbnailCache sharedThumbnailCache] cacheProfileImage:newImage forUserId:userId];
});
我们需要保证在所有的后台任务完成前， tearDown 一定不能被执行。这确保了 newImage
数据可以被正确的清理掉。或者，我们需要保证在缩略图 cache 被移除时，后台缓存任务一定要被取消掉。否则，一个新的缩略图 cache 的实例将会被延迟创建，并且之前用户的数据 (newImage
对象) 会被存储在它里面。
由于对于单例实例来说它没有明确的所有者，(因为单例自己管理自己的生命周期)，“关闭”一个单例变得非常的困难。
分析到这里，我希望你能够意识到，“这个缩略图 cache 从来就不应该作为一个单例！”。问题在于一个对象得生命周期可能在项目的最初阶段没有被很好得考虑清楚。举一个具体的例子，Dropbox 的 iOS 客户端曾经只支持一个账号登录。它以这样的状态存在了数年，直到有一天我们希望能够同时支持多个用户账号登录 (同时登陆私人账号和工作账号)。突然之间，我们以前的的假设“只能够同时有一个用户处于登录状态”就不成立了。如果假定了一个对象的生命周期和应用的生命周期一致，那你的代码的灵活扩展就受到了限制，早晚有一天当产品的需求产生变化时，你会为当初的这个假定付出代价的。
这里我们得到的教训是，单例应该只用来保存全局的状态，并且不能和任何作用域绑定。如果这些状态的作用域比一个完整的应用程序的生命周期要短，那么这个状态就不应该使用单例来管理。用一个单例来管理用户绑定的状态，是代码的坏味道，你应该认真的重新评估你的对象图的设计。
避免使用单例
既然单例对局部作用域的状态有这么多的坏处，那么我们应该怎样避免使用它们呢？
让我们来重温一下上面的例子。既然我们的缩略图 cache 的缓存状态是和具体的用户绑定的，那么让我们来定义一个user对象吧：
@interface SPUser : NSObject
@property (nonatomic, readonly) SPThumbnailCache *thumbnailCache;
@end
@implementation SPUser
- (instancetype)init
{
if ((self = [super init])) {
_thumbnailCache = [[SPThumbnailCache alloc] init];
// Initialize other user-specific state...
}
return self;
}
@end
我们现在用一个对象来作为一个经过认证的用户会话的模型类，并且我们可以把所有和用户相关的状态存储在这个对象中。现在假设我们有一个view controller来展现好友列表：
@interface SPFriendListViewController : UIViewController
- (instancetype)initWithUser:(SPUser *)user;
@end
我们可以显式地把经过认证的 user 对象作为参数传递给这个 view controller。这种把依赖性传递给依赖对象的技术正式的叫法是依赖注入，它有很多优点：
1.对于阅读这个 SPFriendListViewController 头文件的读者来说，可以很清楚的知道它只有在有登录用户的情况下才会被展示。
2.这个 SPFriendListViewController 只要还在使用中，就可以强引用 user 对象。举例来说，对于前面的例子，我们可以像下面这样在后台任务中保存一个图片到缩略图 cache 中：
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[_user.thumbnailCache cacheProfileImage:newImage forUserId:userId];
});
就算后台任务还没有完成，应用其他地方的代码也可以创建和使用一个全新的 SPUser 对象，而不会在清理第一个实例时阻塞用户交互。
为了更详细的说明一下第二点，让我们画一下在使用依赖注入之前和之后的对象图。
假设我们的 SPFriendListViewController 是当前 window 的 root view controller。使用单例时，我们的对象图看起来如下所示：
view controller 自己，以及自定义的 image view 的列表，都会和 sharedThumbnailCache 产生交互。当用户登出后，我们想要清理 root view controller 并且退出到登录页面：
这里的问题在于这个好友列表的 view controller 可能仍然在执行代码 (由于后台操作的原因)，并且可能因此仍然有一些没有执行的涉及到 sharedThumbnailCache 的调用。
和使用依赖注入的解决方案对比一下：
简单起见，假设 SPApplicationDelegate 管理 SPUser 的实例 (在实践中，你可能会把这些用户状态的管理工作交给另外一个对象来做，这样可以使你的 application delegate 简化)。当展现好友列表 view controller 时，会传递进去一个 user 的引用。这个引用也会向下传递给 profile image views。现在，当用户登出时，我们的对象图如下所示：
这个对象图看起来和使用单例时很像。那么，区别是什么呢？
关键问题是作用域。在单例那种情况中，sharedThumbnailCache 仍然可以被程序的任意模块访问。假如用户快速的登录了一个新的账号。该用户也想看看他的好友列表，这也就意味着需要再一次的和缩略图 cache 产生交互：
当用户登录一个新账号，我们应该能够构建并且与全新的 SPThumbnailCache 交互，而不需要再在销毁老的缩略图 cache 上花费精力。基于对象管理的典型规则，老的 view controllers 和老的缩略图 cache 应该能够自己在后台延迟被清理掉。简而言之，我们应该隔离用户 A 相关联的状态和用户 B 相关联的状态：
结论
我们都知道全局可变状态是不好的，但是在使用单例的时候我们又不经意地把它变成我们讨厌的全局可变状态。
在面向对象编程中，我们需要尽可能减少可变状态的作用域，而单例与这个思想背道而驰，希望在下一次使用单例的时候能够多想一想，考虑是否这个变量真正值得成为一个单例，如果不是，还请使用“依赖注入模式”来代替。