保证一个类只有一个实例,并提供一个全局的访问点
应用单例模式的例子实在是太多了,她几乎在程序中随处可见,比如代码里的工具包、应用程序里的注册表对象等等
她甚至还经常在其他的设计模式中有一定的戏份,比如工厂模式里的工厂类对象、生成器模式里的生成器对象、观察者模式里的主题对象……
基本上当你的对象符合以下条件的其中一种,你就可以考虑是否要使用单例模式了:
要不让用你写的代码的人在用之前都找你签个合同?
如果上面这个方法不好使的话,想想我们是怎么保护类里面的属性的呢?
我们会
私有化
类里面的属性,并提供 setter & getter 方法来统一对属性的访问
事实上要统一对单例对象的访问,用的也是这个思路,只不过我们要 私有化 的是类的构造器,就像这样:
public class A{
private static A a = new A();
public static A getInstance(){
return a;
}
private A(){}
}
把构造方法设定成私有的,禁止别的类去访问,同时提供 getInstance 来统一对单例对象的访问
上例中的 A ,确实是一个单例实现,但是他并不优雅
他的问题主要出在以下两个方面:
所以绝大多数情况下,我们会考虑把单例对象的实例化延迟,就像这样:
public class A{
private static A a;
public static A getInstance(){
if(a == null){
a = new A();
}
return a;
}
private A(){}
}
看起来很优雅吧,事实上除非你能保证A一定是在单线程情况下被访问,否则他比第一个实现更糟糕
因为他让A成了一个线程不安全的类
会出现这样的情况:
两个线程同时访问了getInstance方法,他们同时得到了a == null为true的结果;最终两个线程都创建了自己的单例对象,到这里这个单例实现就失控了
就像这样:
这个问题必须被解决,我们可以直接给 getInstance 方法上个锁,就像这样:
public class A{
private static A a;
public static synchronized A getInstance(){
if(a == null){
a = new A();
}
return a;
}
private A(){}
}
这样做可以解决线程问题,但出现了另一个问题
因为上了锁,每一次获取A的单例对象的时候都必须要进行 获取&释放锁
的动作
可单例模式的价值就在于单例对象被频繁使用的时候可以免去重复初始化所带来的性能损耗,直接加锁的方式解决了问题,但是带来新的性能损耗,如果A只是一个可以被很简单就初始化的类,那么获取&释放锁的性能损耗可能比初始化带来的损耗还要大。属于是捡了西瓜丢了冬瓜了
当然,如果A并不会被频繁使用,而且加锁带来的性能损耗在可接受范围内,那么直接给 getInstance 加锁是最稳妥的方法
如果你追求极致,那可以考虑一下 双重检查加锁
的方案
即然给整个方法加锁会影响性能,那我只在需要初始化的时候加锁不就好了吗,就像这样:
public class A{
private static volatile A a;//volatile保证在线程出现竞争的时候程序可以正常处理
public static A getInstance(){
if(a == null){
synchronized(A.class){
if(a == null){//双重检查,在锁内如果还是null,才需要初始化
a = new A();
}
}
}
return a;
}
private A(){}
}
这样一来只有出现竞争的线程有机会获取锁,而在锁内也可以保持正常的行为;其他线程在第一次判断的时候就已经是false了,所以不会进锁,直接返还a
上文提到了单例的四种实现方式:静态初始化、不加锁、锁方法和双重检查加锁。事实上这四种方式不存在谁比谁高级,他们都是特定情况下的最优解。只不过代码性能越来越低(虽然是微乎其微的降低),安全性越来越高
这世上的事物都不会是非黑即白的,单例模式是这样,其他设计模式也一样。几乎所有的设计模式都有一个缺点,那就是让代码变得更复杂,可是她同时也让你的代码变得更清晰了或者性能提高了。凡事都有两面性,你必须在其中找到平衡点,找到当前形势下的最优解