学习设计模式不光要学习设计模式的思想,还要去深入理解,为什么要用这个设计模式。
如何深入理解?读优秀的框架代码,看别人代码,了解它们的使用场景。 - - - 博主老师(感谢他)
单例应用的太广泛,大家应该都用过,本文主要是想聊聊线程安全的单例以及反序列化破坏单例的情况。
确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例。
关键点:
饿汉模式:不管有没有调用getInstance方法,只要类加载了,我就给你new出来(a)
public class A {
private static final A a = new A();
public static A getInstance() {
return a;
}
private A() {
}
}
以下两点保证了以上代码的线程安全:
懒汉模式:延迟加载,用到再去new
public class B {
private static volatile B b;
public static synchronized B getInstance() {
if (b == null) {
b = new B();
}
return b;
}
private B() {
}
}
要保证线程安全,最简单的方式是加同步锁。synchroized保证了多个线程串行的去调用getInstance(),既然是串行,那就不会存在什么线程安全问题了。但是这实现,每次读都要加锁,其实我们想要做的只是让他写(new)的时候加锁。
public class B {
private static volatile B b;
public static synchronized B getInstance0() {
if (b == null) {
synchronized (B.class) {
b = new B();
}
}
return b;
}
public static B getInstance() {
if (b == null) {
synchronized (B.class) {
if (b == null) {
b = new B();
}
}
}
return b;
}
private B() {
}
}
为了解决懒汉模式的效率问题,我们改造成getInstance0():
但还有个问题 X、Y 两个线程同时进入if (b == null), X先进同步代码块,new了一个B,返回。Y等到X释放锁之后,它也进了同步代码块,也会new一个B。
getInstance0()解决了效率问题,但它不是线程安全的。我们有进行了一次改造: getInstance():
getInstance在同步块里面,又做了一次if (b == null)的判断,确保了Y线程不会再new B,保证了线程安全。
getInstance() 也正是所谓的双重检查锁定(double checked locking)。
这里还有一个关键点:private static volatile B b;
b是用volatile修饰的。
这个主要是因为new 并不是原子的。
B b = new B();
可以简单的分解成一下步骤
2,3 直接可能发生指令重排序,就是说对象还未初始化完成,就让b指向了一块内存地址,这时候b就不是null了。
public class C {
private C() {
}
public static C getInstance() {
return CHolder.c;
}
private static class CHolder {
private static final C c = new C();
}
}
静态内部类的线程安全也是由jvm保证的,在调用Cholder.c的时候,去加载CHolder类,new 了一个c。
总的来说,这个方式比DCL还是高点的,因为DCL加了volatile,效率上还是略微有些些影响。
上面介绍的3种线程安全的单例,在有种极端的情况,单例模式有可能被破坏:反序列化
反序列化的时候,会重新构造一个对象,破坏单例模式。我们看下代码验证下:
public class C1 implements Serializable {
private C1() {
System.out.println("构造方法");
}
public static C1 getInstance() {
return CHolder.c;
}
private static class CHolder {
private static final C1 c = new C1();
}
// 注意这块被注释的代码
// private Object readResolve(){
// System.out.println("read resolve");
// return CHolder.c;
// }
public static void main(String[] args) throws NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException {
C1 c = C1.getInstance();
System.out.println(c.toString());
try {
ObjectOutputStream o = new ObjectOutputStream(
new FileOutputStream("d:/tmp/c.out"));
o.writeObject(c);
o.close();
} catch(Exception e) {
e.printStackTrace();
}
C1 c1 = null, c2 = null;
try {
ObjectInputStream in =new ObjectInputStream(
new FileInputStream("d:/tmp/c.out"));
c1 = (C1)in.readObject();
in.close();
} catch(Exception e) {
e.printStackTrace();
}
try {
ObjectInputStream in =new ObjectInputStream(
new FileInputStream("d:/tmp/c.out"));
c2 = (C1)in.readObject();
in.close();
} catch(Exception e) {
e.printStackTrace();
}
System.out.println("c1.equals(c2) : " + c1.equals(c2));
System.out.println("c1 == c2 : " + (c1 == c2));
System.out.println(c1);
System.out.println(c2);
}
}
结果:
构造方法
me.hhy.designpattern.singletonpattern.C1@1540e19d
c1.equals(c2) : false
c1 == c2 : false
me.hhy.designpattern.singletonpattern.C1@135fbaa4
me.hhy.designpattern.singletonpattern.C1@45ee12a7
放开注释的代码
构造方法
me.hhy.designpattern.singletonpattern.C1@1540e19d
read resolve
read resolve
c1.equals(c2) : true
c1 == c2 : true
me.hhy.designpattern.singletonpattern.C1@1540e19d
me.hhy.designpattern.singletonpattern.C1@1540e19d
正如我们看到的那样,加上readResolve就解决了反序列化单例被破坏的问题。
当然,如果没实现Serializable接口,也就不会有这个被破坏的问题… 还是看场景。
关于readResolve的介绍,感兴趣的同学们可以看java.io.ObjectInputStream#readUnshared方法上的注释(博主看了,看得不是很明白,一知半解,就不误人子弟了)
而我们下面要介绍的枚举单例,并不会有这个问题。
public enum DEnum {
INSTANCE;
private D d;
DEnum() {
d = new D();
}
public D getInstance() {
return d;
}
}
public class D {
}
线程安全的保证:
序列化不破坏单例的保证:
在序列化的时候Java仅仅是将枚举对象的name属性输出到结果中,反序列化的时候则是通过java.lang.Enum的valueOf方法来根据名字查找枚举对象。同时,编译器是不允许任何对这种序列化机制的定制的,因此禁用了writeObject、readObject、readObjectNoData、writeReplace和readResolve等方法。
不过多介绍了,这个其实在线程安全的单例部分,我们介绍的比较详细了。
public class B {
private static volatile B b;
public static B getInstance() {
if (b == null) {
b = new B();
}
return b;
}
private B() {
}
}
单例的应用实在是太多了,也没必要再去找源码种的经典使用(因为基本上大家用过)。
枚举单例构造方法还是public,并不是防止外部直接去new它。个人认为如果一个类要开放给外部使用,用内部类的形式实现单例是最合适的。