单例模式
单例模式是我们经常使用的一种设计模式，它能保证系统中只有一个实例。在适当的应用场合，单例模式能给我们提供很大的便利，但是如果应用不当，却是麻烦的根源，有时候还会很难排查。
本文就拿我所负责的项目中实际产生的问题来说明滥用单例模式导致的一些诡异的问题。
第一宗罪：数据不一致性
单例模式为什么会产生数据不一致性呢？我们先看一个简单的例子：
[SingletonDemo shareInstance].important = @"123";
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"important = %@", [SingletonDemo shareInstance].important);
});
[SingletonDemo shareInstance].important = @"abc";
这段代码，一般会输出important = abc，我们也很容易分析出来为什么会有这样的输出。但是放到复杂的系统里，可能就没有这么直观了。
在我们的项目中，诡异问题产生的原理跟上面代码是类似的。简单的来说就是前任开发人员将订单号放在了某个单例里了，业务代码里会使用这个订单号拿到整个订单对数据来做处理，但是更新这个订单号的地方有一个异步操作。可能上个订单已经处理完毕了，但是上个订单里有一部分异步逻辑没有来得及执行，下一个订单就开始了将订单号更改成了下一个订单号，导致了上一个订单里的异步逻辑执行有问题，产生了数据的不一致性。
我们接到用户反馈的这个诡异的问题后，所有人的目光都盯在了异步逻辑的执行里，看起来逻辑一切正常，直到我发现了更改订单号和这个逻辑是异步的，改掉这个问题后，这个诡异的问题再也没有出现过。
不得不承认将订单号放在单例里，是一个很糟糕的设计，当时迫于业务压力，并且测试阶段也没有发现由此导致的问题，就没有下定决心重构这段代码，直到用户使用的时候发生了诡异的bug，我才下定决心重构这个设计。
第二宗罪：内存警告
单例模式一旦生成了单例对象，基本不会再释放，所以如果单例模式使用过多必然会造成内存占用率变高的问题。在这里我再举一个我们团队里出现的一个极端的例子。
我们的App里需要开发一个换肤功能，负责的开发将皮肤所用的图片资源放在了某个单例里面，导致只要没有使用默认的皮肤，内存占用率就会暴涨。当然这个问题我们使用Instruments排查后就很轻松的就解决了，但是如何正确使用单例模式却值得我们深思。
单例模式使用建议
虽然本文标题说的是单例模式的两宗罪，但是实际上单例模式本身并没有罪，罪在开发人员使用的姿势不对。所以我们要理解单例模式的应用场景是什么。
前面我们提到，单例模式的特点是系统中只有一个实例，所以单例模式适合表示那些在我们系统中只可能存在一个的对象。显然对于第一个例子，我们的系统经常处理订单，将订单当成单例是非常不合适的。
另外单例模式生成后基本上不太会释放，所以一些大的数据对象（比如UIImage对象）不太适合用单例存储。这也正是第二个例子导致内存暴涨的原因所在。
