单例模式相信大家都很熟悉了，是一种很常用的设计模式，单例模式确保一个类只有一个实例，并提供一个访问它的全局访问点。作者曾经在一次面试中要求写出单例模式，想了想单例模式还是简单的，随手就写了如下代码。
/**
* @author Meng
* @date 2020/8/19
*/
public class Singleton {
private static Singleton instance;
private Singleton(){}
public static Singleton getInstance(){
if(instance==null){
instance=new Singleton();
}
return instance;
}
}
最后，不出意外的没有通过面试。原因如下
- 这段代码并没有保证线程是安全的，是有可能导致获取的对象不唯一。
- 这段代码是可以通过反射破坏单例模式，拿到多个相同的对象。
在多线程的情况下，一个线程已经进入到if里面的代码块但是还没有创建对象，突然切换到另外一个线程，就有可能导出创建的对象不一致。
至于通过反射破坏单例模式，我们则是通过setAccessible(true)来强行访问私有构造器，代码如下
public static void main(String[] args) throws NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException {
Class<?> clazz=Singleton.class;
Constructor<?> constructor = clazz.getDeclaredConstructor();
constructor.setAccessible(true); //修改私有构造器的访问权限
Singleton singleton=(Singleton)constructor.newInstance();
Singleton singleton1=(Singleton)constructor.newInstance();
System.out.println(singleton==singleton1); //输出为false，证明创建两个不一样的对象
}
经过总结，一个单例模式的写法，我们需要关注以下几点。
- 如何确保线程安全
- 懒加载还是立刻加载(懒加载能避免资源浪费)
- 能否避免反射破坏单例模式，如何避免
一、饿汉模式
/**
- @author Meng
- @date 2020/8/19
*/
public class Singleton {
private final static Singleton instance = new Singleton();
private Singleton() {
if (instance != null) {
throw new RuntimeException("禁止通过反射构造对象");
}
}
public static synchronized Singleton getInstance() {
return instance;
}
}
饿汉模式的特点很明显，它在类初始化的时候会创建对象，而该过程执行在类初始化<client>(),而<client>()是线程安全的，因此不担心线程安全问题，但是缺点也容易明显，就算没有使用也会创建对象，容易浪费内存。同时构造器进行了判断，如果想通过反射也会抛出异常。
- 类加载就创建对象保证线程安全
- 立刻加载
- 能通过立刻加载+私有构造器判定确保不会被反射破坏
二、懒汉模式
懒汉模式，顾名思义，就是很懒，用到才创建对象，属于懒加载。作者一开始的例子就属于懒汉模式，因此我们需要为其确保线程安全。但是懒汉模式难以防止反射破坏,详情下面会分析
2.1 synchronized关键字
/**
- @author Meng
- @date 2020/8/19
*/
public class Singleton {
private static Singleton instance;
private Singleton (){
if (instance != null) {
throw new RuntimeException("禁止通过反射构造对象");
}
}
public static synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
简单粗暴，直接通过synchronized加锁达到了线程安全，也像饿汉模式一样在构造函数进行了判断防止反射破坏。但是真的能防止反射吗？它防止的只是先正常获取对象，再反射，但是其实可以通过先反射，再正常的获取对象，拿到两个对象。代码如下
/**
- @author Meng
- @date 2020/8/19
*/
public class Singleton {
private static Singleton instance;
private Singleton (){
if (instance != null) {
throw new RuntimeException("禁止通过反射构造对象");
}
}
public static synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
- synchronized 对整个方法加锁保证线程安全,但可能牺牲性能
- 懒加载
- 不能避免反射破坏
2.2 双重检测锁
/**
- @author Meng
- @date 2020/8/19
*/
public class Singleton {
private volatile static Singleton instance;
private Singleton (){
if (instance != null) {
throw new RuntimeException("禁止通过反射构造对象");
}
}
public Singleton getInstance() {
if (null == instance) {
synchronized (Singleton.class) {
if (null == instance) {
instance = new Singleton();
}
}
}
return instance;
}
}
该方法不是对整个方法加锁，而是先进行判断，再对类进行加锁,同时使用volatile避免指令的重排序（需要jdk1.5以后）,volatile关键字的作用这里就不细谈了。至于防止反射破坏，与上面的一样，是不能避免的。
- volatile(jdk>1.5)+判定+对类加锁确保线程安全
- 懒加载
- 不能防止反射破坏
三、[推]枚举模式
/**
3\. @author Meng
4\. @create 2020/8/19
*/
public enum Singleton {
instance;
public static Singleton getInstance(){
return instance;
}
}
我们先看看枚举的本质
- 枚举只能拥有私有的构造器
- 枚举类实际上是一个继承Enum的一个final类
- 枚举类不允许被反序列化，Enum重写了方法
- 静态代码块中对final变量的值进行初始化
- enum类最终是一个final class
枚举是线程安全的，因为枚举类里的枚举会在静态代码块创建对象，而该过程执行在类初始化<client>(),而<client>()是线程安全的
- 枚举天生就是线程安全的
- 并非懒加载
- java禁止对枚举反射，从而保证不会被反射破坏
四、[推]Holder模式
接下来就是作者最喜欢的Holder模式，虽然枚举模式已经十分的完美，但是面向对象还是更多人喜欢Class而不是Enum.Holder模式说白了就是通过静态内部类来实现，先看代码
/**
* @author Meng
* @date 2020/8/19
*/
public class Singleton {
private Singleton() {
if(Holder.instance!=null) {
throw new RuntimeException("禁止通过反射构造对象");
}
}
private static class Holder {
private static Singleton instance = new Singleton();
}
public static Singleton getInstance() {
return Holder.instance;
}
}
在调用getInstance方法的时候，Holder类才会被加载（这里可以去看下类加载的时机）,到了初始化阶段会对静态变量instance赋值，属于<clinit>()过程，而该过程是保证线程安全的，静态内部类在用到时候才会加载，因此该模式属于延迟加载，与饿汉模式类似，私有构造方法进行判定避免了反射破坏。
- 线程安全
- 静态内部类需要时才会加载，属于懒加载
- 能够避免反射破坏
五、总结
最后
关注公众号：程序员麦冬，回复888 领取2020最新Java面试题手册（200多页PDF文档）。
网友评论