单例模式
单例模式
实现单例模式的重点是在多线程和序列化的时候保持实例的单一
饿汉式
public class Singletion {
/**
* 优点:
* 用到这个实例的时候就能够立即拿到，而不需要任何等待时间
* 由于该实例在类被加载的时候就创建出来了，所以也避免了线程安全问题
* 缺点:
* 在类被加载的时候对象就会实例化, 这也许会造成不必要的消耗
* 如果这个类被多次加载的话也会造成多次实例化
* 但是怎么样才会导致一个类被加载两次呢??? 网上也没有, 留一个todu吧
*/
//TODO 如上注释
private static Singletion instance = new Singletion();
private Singletion() {
}
public Singletion getInstance() {
return instance;
}
}
静态内部类式
/**
* 这种方式同样利用了classloder的机制来保证初始化instance时只有一个线程，
* 它跟饿汉式不同的是（很细微的差别）：
* 饿汉式是只要Singleton类被装载了，那么instance就会被实例化（没有达到lazy loading效果），
* 而这种方式是Singleton类被装载了，instance不一定被初始化。
* 因为SingletonHolder类没有被主动使用，只有显示通过调用getInstance方法时
* 才会显示装载SingletonHolder类，从而实例化instance。
* 想象一下，如果实例化instance很消耗资源，我想让他延迟加载，
* 另外一方面，我不希望在Singleton类加载时就实例化，
* 因为我不能确保Singleton类还可能在其他的地方被主动使用从而被加载，
* 那么这个时候实例化instance显然是不合适的。这个时候，这种方式相比饿汉式更加合理。
*/
public class Singletion {
private static class SingletonHodler {
private static final Singletion INSTANCE = new Singletion();
}
private Singletion(){};
public static final Singletion getInstance() {
return SingletonHodler.INSTANCE;
}
}
懒汉式
存在线程安全的模型
public class Singletion implements Serializable{
private static Singletion instance;
private Singletion(){};
/** 这种懒汉模式存在线程安全 */
public static Singletion getInstance1() {
if (instance == null) {
instance = new Singletion();
}
return instance;
}
}
线程安全但是效率低下的模型
public class Singletion implements Serializable{
private static Singletion instance;
private Singletion(){};
/**
* 这种写法在多线程中可以很好工作
* 但是效率很低下, 因为加锁是整个方法加锁, 该方法的所有操作都是同步进行的
* 但是对于非第一次操作, 根本不需要同步操作, 可以直接返回instance
*
* 但是以上的做法都不能防止序列化和反序列化所带来的危害
*/
public static synchronized Singletion getInstance2() {
if (instance == null) {
instance = new Singletion();
}
return instance;
}
}
双重校验锁
public class Singletion implements Serializable{
private static volatile Singletion instance;
private Singletion(){};
/**
* 双重校验锁的单例模式
* 因为java 内存模型, 必须强制线程从主内存区读取
* 所有要在instance变量上面加volatile
* @return
*/
public static Singletion getInstance() {
if (instance == null) {
synchronized (Singletion.class) {
if (instance == null) {
instance = new Singletion();
}
}
}
return instance;
}
}
单例模式与序列化
看下面案例:
public static void main(String[] args) throws IOException, ClassNotFoundException {
File file = new File("temp");
ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream(file));
oos.writeObject(Singletion.getInstance());
ObjectInputStream ois = new ObjectInputStream(new FileInputStream(file));
Singletion newSingletion = (Singletion) ois.readObject();
System.out.println(newSingletion == Singletion.getInstance()); //false
}
这里的单例采用上面的双重校验锁, 将instance序列化后再反序列化, 得到了两个不一样的对象, 这就破坏了单例模式了
先说怎么解决:
//在单例模式里面加入这个方法解决序列化问题
/**
* 实现这个方法可以避免序列化的问题, 返回的必须是Object类型
* @return
*/
public Object readResolve() {
return getInstance();
}
原理:
对象的序列化过程通过ObjectOutputStream和ObjectInputputStream来实现的，那么带着刚刚的问题，分析一下ObjectInputputStream 的readObject 方法执行情况到底是怎样的。
为了节省篇幅，这里给出ObjectInputStream的readObject的调用栈：
readObject--->readObject0--->readOrdinaryObject--->checkResolve
这里看一下重点代码，readOrdinaryObject方法的代码片段
private Object readOrdinaryObject(boolean unshared)
throws IOException
{
//省略部分代码
Object obj;
try {
/**
这里创建的这个obj对象，就是本方法要返回的对象，也可以暂时理解为是ObjectInputStream的readObject返回的对象
isInstantiable：如果一个serializable/externalizable的类可以在运行时被实例化，那么该方法就返回true。
desc.newInstance：该方法通过反射的方式调用无参构造方法新建一个对象。
到目前为止，也就可以解释，为什么序列化可以破坏单例了？
序列化会通过反射调用无参数的构造方法创建一个新的对象。
*/
obj = desc.isInstantiable() ? desc.newInstance() : null;
} catch (Exception ex) {
throw (IOException) new InvalidClassException(
desc.forClass().getName(),
"unable to create instance").initCause(ex);
}
//省略部分代码
/**
hasReadResolveMethod:如果实现了serializable 或者 externalizable接口的类中包含readResolve则返回true
*/
if (obj != null &&
handles.lookupException(passHandle) == null &&
desc.hasReadResolveMethod())
{
//invokeReadResolve:通过反射的方式调用要被反序列化的类的readResolve方法。
//所以，原理也就清楚了，主要在Singleton中定义readResolve方法，并在该方法中指定要返回的对象的生成策略，就可以方式单例被破坏。
Object rep = desc.invokeReadResolve(obj);
if (unshared && rep.getClass().isArray()) {
rep = cloneArray(rep);
}
if (rep != obj) {
// Filter the replacement object
if (rep != null) {
if (rep.getClass().isArray()) {
filterCheck(rep.getClass(), Array.getLength(rep));
} else {
filterCheck(rep.getClass(), -1);
}
}
handles.setObject(passHandle, obj = rep);
}
}
return obj;
}
使用枚举实现单例
单例的枚举实现在《Effective Java》中有提到，因为其功能完整、使用简洁、无偿地提供了序列化机制、在面对复杂的序列化或者反射攻击时仍然可以绝对防止多次实例化等优点，单元素的枚举类型被作者认为是实现Singleton的最佳方法
//比上面的什么双重校验锁简单多了
public enum Singletion {
INSTANCE;
}
下面深入了解一下为什么枚举会满足线程安全、序列化等标准。
在JDK5 中提供了大量的语法糖，枚举就是其中一种。
所谓 语法糖（Syntactic Sugar），也称糖衣语法，是由英国计算机学家 Peter.J.Landin 发明的一个术语，指在计算机语言中添加的某种语法，这种语法对语言的功能并没有影响，但是但是更方便程序员使用。只是在编译器上做了手脚，却没有提供对应的指令集来处理它。
就拿枚举来说，其实Enum就是一个普通的类，它继承自java.lang.Enum类。
public enum DataSourceEnum {
DATASOURCE;
}
把上面枚举编译后的字节码反编译，得到的代码如下：
public final class DataSourceEnum extends Enum<DataSourceEnum> {
public static final DataSourceEnum DATASOURCE;
public static DataSourceEnum[] values();
public static DataSourceEnum valueOf(String s);
static {};
}
由反编译后的代码可知，DATASOURCE 被声明为 static 的，根据在【单例深思】饿汉式与类加载中所描述的类加载过程，可以知道虚拟机会保证一个类的
当一个Java类第一次被真正使用到的时候静态资源被初始化、Java类的加载和初始化过程都是线程安全的（因为虚拟机在加载枚举的类的时候，会使用ClassLoader的loadClass方法，而这个方法使用同步代码块保证了线程安全）。所以，创建一个enum类型是线程安全的。
也就是说，我们定义的一个枚举，在第一次被真正用到的时候，会被虚拟机加载并初始化，而这个初始化过程是线程安全的。而我们知道，解决单例的并发问题，主要解决的就是初始化过程中的线程安全问题。
所以，由于枚举的以上特性，枚举实现的单例是天生线程安全的。
接下来看看序列化问题：
Java规范中规定，每一个枚举类型极其定义的枚举变量在JVM中都是唯一的，因此在枚举类型的序列化和反序列化上，Java做了特殊的规定。
在序列化的时候Java仅仅是将枚举对象的name属性输出到结果中，反序列化的时候则是通过 java.lang.Enum 的 valueOf() 方法来根据名字查找枚举对象。
也就是说，以下面枚举为例，序列化的时候只将 DATASOURCE 这个名称输出，反序列化的时候再通过这个名称，查找对于的枚举类型，因此反序列化后的实例也会和之前被序列化的对象实例相同。
参考:
https://mp.weixin.qq.com/s?__biz=MzI3NzE0NjcwMg==&mid=402577543&idx=1&sn=41c4bf5f46d13806668edacce130468b&scene=21#wechat_redirect
https://cloud.tencent.com/developer/article/1341386
https://blog.csdn.net/moakun/article/details/80688851
https://blog.csdn.net/gavin_dyson/article/details/70832185