黄岛因特网站建设公司,开源展示型网站,中建装饰集团,浙江省网站建设公司排名文章目录单例模式的应用场景饿汉式单例模式懒汉式单例模式改进#xff1a;synchronized改进#xff1a;双重检查锁改进#xff1a;静态内部类破坏单例用反射破坏单例用序列化破坏单例解密注册式单例模式枚举式单例模式解密容器式单例线程单例实现ThreadLocal单例模式小结参考…
文章目录单例模式的应用场景饿汉式单例模式懒汉式单例模式改进synchronized改进双重检查锁改进静态内部类破坏单例用反射破坏单例用序列化破坏单例解密注册式单例模式枚举式单例模式解密容器式单例线程单例实现ThreadLocal单例模式小结参考资料单例模式的应用场景
单例模式Singleton Pattern是指确保一个类在任何情况下都绝对只有一个实例并提供一个全局访问点。单例模式是创建型模式。单例模式在现实生活中应用也非常广泛例如公司CEO、部门经理等。J2EE标准中的ServletContext、ServletContextConfig 等、Spring框架应用中的ApplicationContext、数据库的连接池等也都是单例形式。
单例模式的类结构图如下 饿汉式单例模式
饿汉式单例模式在类加载的时候就立即初始化并且创建单例对象。它绝对线程安全在线程还没出现以前就实例化了、不可能存在访问安全问题。
优点没有加任何锁、执行效率比较高用户体验比懒汉式单例模式更好。
缺点类加载的时候就初始化不管用与不用都占着空间可能浪费内存“尸位素餐”。
Spring中loC容器ApplicationContext本身就是典型的饿汉式单例模式。
接下来看一段代码
public class HungrySingleton {//先静态、后动态//先属性、后方法//先上后下private static final HungrySingleton hungrySingleton new HungrySingleton();private HungrySingleton(){}public static HungrySingleton getInstance(){return hungrySingleton;}
}
还有另外一种写法利用静态代码块的机制
public class HungryStaticSingleton {private static final HungryStaticSingleton hungrySingleton;static {hungrySingleton new HungryStaticSingleton();}private HungryStaticSingleton(){}public static HungryStaticSingleton getInstance(){return hungrySingleton;}
}这两种写法都非常简单也非常好理解饿汉式单例模式适用于单例对象较少的情况。下面我们来看性能更优的写法。
ZJ联想起挂着大饼的巨婴。
懒汉式单例模式
懒汉式单例模式的特点是被外部类调用的时候内部类才会加载。下面看懒汉式单例模式的简单实现LazySimpleSingleton
public class LazySimpleSingleton {private LazySimpleSingleton(){}//静态块公共内存区域private static LazySimpleSingleton lazy null;public static LazySimpleSingleton getInstance(){if(lazy null){lazy new LazySimpleSingleton();}return lazy;}public static void main(String[] args) {Runnable task ()-{LazySimpleSingleton singleton LazySimpleSingleton.getInstance();System.out.println(Thread.currentThread().getName() : singleton);};Thread t1 new Thread(task);Thread t2 new Thread(task);t1.start();t2.start();System.out.println(End);}}运行结果如下
End
Thread-1:com.lun.pattern.singleton.lazy.LazySimpleSingleton6fc8c462
Thread-0:com.lun.pattern.singleton.lazy.LazySimpleSingleton6fc8c462上面的代码有一定概率出现两种不同结果这意味着上面的单例存在线程安全隐患。
我们通过调试运行再具体看一下手动控制线程的执行顺序来跟踪内存的变化。如下图打上断点。 运行调试让两线程停顿在lazy new LazySimpleSingleton(); 先让Thread-0单步运行观察lazy变量的哈希值 先让Thread-1单步运行观察lazy变量的哈希值 LazySimpleSingleton类有创建两次实例这违背单例模式初衷。
有时我们得到的运行结果可能是相同的两个对象实际上是被后面执行的线程覆盖了我们看到了一个假象线程安全隐患依旧存在。
改进synchronized
那么我们如何来优化代码使得懒汉式单例模式在线程环境下安全呢来看下面的代码给getInstance()加上synchronized关键字使这个方法变成线程同步方法
public class LazySimpleSingleton {private LazySimpleSingleton(){}//静态块公共内存区域private static LazySimpleSingleton lazy null;public static synchronized LazySimpleSingleton getInstance(){if(lazy null){lazy new LazySimpleSingleton();}return lazy;}
}运行调试。先让Thread-0获得锁正在调用getInstance()的lazy new LazySimpleSingleton();断点保持未填关键字synchronized时那样。而Thread-1尝试调用getInstance()但存在锁存在只能被阻塞直到Thread-0调用getInstance()返回后释放锁为止。 上图完美地展现了synchronized 监视锁的运行状态线程安全的问题解决了。
但是用synchronized加锁时在线程数量比较多的情况下如果CPU分配压力上升则会导致大批线程阻塞从而导致程序性能大幅下降。
改进双重检查锁
那么有没有一种更好的方式既能兼顾线程安全又能提高程序性能呢
答案是肯定的。我们来看双重检查锁的单例模式
public class LazyDoubleCheckSingleton {private volatile static LazyDoubleCheckSingleton lazy null;private LazyDoubleCheckSingleton(){}public static LazyDoubleCheckSingleton getInstance(){if(lazy null){synchronized (LazyDoubleCheckSingleton.class){
// if(lazy null){lazy new LazyDoubleCheckSingleton();//1.分配内存给这个对象//2.初始化对象//3.设置lazy指向刚分配的内存地址//4.初次访问对象
// }}}return lazy;}}但是用到 synchronized关键字总归要上锁对程序性能还是存在一定影响的。
难道就真的没有更好的方案吗?当然有。
改进静态内部类
我们可以从类初始化的角度来考虑看下面的代码采用静态内部类的方式
public class LazyInnerClassSingleton {//默认使用LazyInnerClassGeneral的时候会先初始化内部类//如果没使用的话内部类是不加载的private LazyInnerClassSingleton(){}//每一个关键字都不是多余的//static 是为了使单例的空间共享//保证这个方法不会被重写重载public static final LazyInnerClassSingleton getInstance(){//在返回结果以前一定会先加载内部类return LazyHolder.LAZY;}//默认不加载private static class LazyHolder{private static final LazyInnerClassSingleton LAZY new LazyInnerClassSingleton();}
}这种方式兼顾了饿汉式单例模式的内存浪费问题和synchronized 的性能问题。内部类一定是要在方法调用之前初始化巧妙地避免了线程安全问题。
破坏单例
用反射破坏单例
大家有没有发现,上面介绍的单例模式的构造方法除了加上private关键字没有做任何处理如果我们使用反射来调用其构造方法再调用getInstance()方法应该有两个不同的实例。现在来看一段测试代码以 LazyInnerClassSingleton为例
public class LazyInnerClassSingleton {...public static void main(String[] args) {try{//在很无聊的情况下,进行破坏Class? clazz LazyInnerClassSingleton.class;//通过反射获取私有的构造方法Constructor c clazz.getDeclaredConstructor(null);//强制访问c.setAccessible(true);//暴力初始化Object o1 c.newInstance();//调用了两次构造方法相当于“new”了两次犯了原则性错误Object o2 c.newInstance();System.out.println(o1 o2);}catch(Exception e){e.printStackTrace();}}}输出结果为
false显然创建了两个不同的实例。现在我们在其构造方法中做一些限制一旦出现多次重复创建则直接抛出异常。来看优化后的代码:
public class LazyInnerClassSingleton {//默认使用LazyInnerClassSingleton的时候会先初始化内部类//如果没使用的话内部类是不加载的private LazyInnerClassSingleton(){if(LazyHolder.LAZY ! null){//------------------------关注点throw new RuntimeException(不允许创建多个实例);}}...}再次运行测试代码输出结果为
java.lang.reflect.InvocationTargetExceptionat java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:78)at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)at com.lun.pattern.singleton.lazy.LazyInnerClassSingleton.main(LazyInnerClassSingleton.java:47)
Caused by: java.lang.RuntimeException: 不允许创建多个实例at com.lun.pattern.singleton.lazy.LazyInnerClassSingleton.init(LazyInnerClassSingleton.java:20)... 6 more至此看起来相当完美单例模式实现了。
用序列化破坏单例
一个单例对象创建好后有时候需要将对象序列化然后写入磁盘下次使用时再从磁盘中读取对象并进行反序列化将其转化为内存对象。反序列化后的对象会重新分配内存即重新创建。如果序列化的目标对象为单例对象就违背了单例模式的初衷相当于破坏了单例来看一段代码
public class SeriableSingleton implements Serializable {//序列化就是说把内存中的状态通过转换成字节码的形式//从而转换一个IO流写入到其他地方(可以是磁盘、网络IO)//内存中状态给永久保存下来了//反序列化//讲已经持久化的字节码内容转换为IO流//通过IO流的读取进而将读取的内容转换为Java对象//在转换过程中会重新创建对象newpublic final static SeriableSingleton INSTANCE new SeriableSingleton();private SeriableSingleton(){}public static SeriableSingleton getInstance(){return INSTANCE;}
}测试代码
public class SeriableSingletonTest {public static void main(String[] args) {SeriableSingleton s1 null;SeriableSingleton s2 SeriableSingleton.getInstance();FileOutputStream fos null;try {fos new FileOutputStream(SeriableSingleton.obj);ObjectOutputStream oos new ObjectOutputStream(fos);oos.writeObject(s2);oos.flush();oos.close();FileInputStream fis new FileInputStream(SeriableSingleton.obj);ObjectInputStream ois new ObjectInputStream(fis);s1 (SeriableSingleton)ois.readObject();ois.close();System.out.println(s1);System.out.println(s2);System.out.println(s1 s2);} catch (Exception e) {e.printStackTrace();}}
}运行结果
com.lun.pattern.singleton.seriable.SeriableSingleton17c68925
com.lun.pattern.singleton.seriable.SeriableSingleton48140564
false从运行结果可以看出反序列化后的对象和手动创建的对象是不一致的实例化了两次违背了单例模式的设计初衷。
那么我们如何保证在序列化的情况下也能够实现单例模式呢其实很简单只需要增加readResolve()方法即可。来看优化后的代码
public class SeriableSingleton implements Serializable {...private Object readResolve(){//新添方法。return INSTANCE;}}再次运行测试代码
com.lun.pattern.singleton.seriable.SeriableSingleton48140564
com.lun.pattern.singleton.seriable.SeriableSingleton48140564
true解密
为什么添加readResolve()后问题解决了。阅读ObjectInputStream类的readObject()方法源码代码如下
public class ObjectInputStreamextends InputStream implements ObjectInput, ObjectStreamConstants
{...public final Object readObject()throws IOException, ClassNotFoundException {return readObject(Object.class);//调用下面那个私有方法}private final Object readObject(Class? type)throws IOException, ClassNotFoundException{if (enableOverride) {return readObjectOverride();}if (! (type Object.class || type String.class))throw new AssertionError(internal error);// if nested read, passHandle contains handle of enclosing objectint outerHandle passHandle;try {Object obj readObject0(type, false);//-------关注点handles.markDependency(outerHandle, passHandle);ClassNotFoundException ex handles.lookupException(passHandle);if (ex ! null) {throw ex;}if (depth 0) {vlist.doCallbacks();freeze();}return obj;} finally {passHandle outerHandle;if (closed depth 0) {clear();}}}}readObject()方法中又调用了重写的 readObject0()方法。进入readObject0()方法代码如下 private Object readObject0(Class? type, boolean unshared) throws IOException {...byte tc;while ((tc bin.peekByte()) TC_RESET) {bin.readByte();handleReset();}depth;totalObjectRefs;try {switch (tc) {...case TC_OBJECT:if (type String.class) {throw new ClassCastException(Cannot cast an object to java.lang.String);}return checkResolve(readOrdinaryObject(unshared));//-------关注点...}} finally {depth--;bin.setBlockDataMode(oldMode);}}MN这里没太懂怎么到TC_OBJECT的这步的。
我们看到TC_OBJECT中调用了ObjectInputStream的readOrdinaryObject()方法看源码
public class ObjectInputStreamextends InputStream implements ObjectInput, ObjectStreamConstants
{...private Object readOrdinaryObject(boolean unshared)throws IOException{if (bin.readByte() ! TC_OBJECT) {throw new InternalError();}ObjectStreamClass desc readClassDesc(false);desc.checkDeserialize();Class? cl desc.forClass();if (cl String.class || cl Class.class|| cl ObjectStreamClass.class) {throw new InvalidClassException(invalid class descriptor);}Object obj;try {obj desc.isInstantiable() ? desc.newInstance() : null;//--------------关注点} catch (Exception ex) {throw (IOException) new InvalidClassException(desc.forClass().getName(),unable to create instance).initCause(ex);}...return obj;}
}我们发现调用了ObjectStreamClass的isInstantiable()方法而 isInstantiable()方法的代码如下
public class ObjectInputStreamextends InputStream implements ObjectInput, ObjectStreamConstants
{...boolean isInstantiable() {requireInitialized();return (cons ! null);}...
}上述代码非常简单就是判断一下构造方法是否为空构造方法不为空就返回 true。这意味着只要有无参构造方法就会实例化。
MN如果没添加readResolve()方法就返回这实例。
此时并没有找到加上readResolve()方法就避免了单例模式被破坏的真正原因。再回到ObjectInputStream的readOrdinaryObject()方法继续往下看
public class ObjectInputStreamextends InputStream implements ObjectInput, ObjectStreamConstants
{...private Object readOrdinaryObject(boolean unshared)throws IOException{if (bin.readByte() ! TC_OBJECT) {throw new InternalError();}ObjectStreamClass desc readClassDesc(false);desc.checkDeserialize();Class? cl desc.forClass();if (cl String.class || cl Class.class|| cl ObjectStreamClass.class) {throw new InvalidClassException(invalid class descriptor);}Object obj;try {obj desc.isInstantiable() ? desc.newInstance() : null;} catch (Exception ex) {throw (IOException) new InvalidClassException(desc.forClass().getName(),unable to create instance).initCause(ex);}...if (obj ! null handles.lookupException(passHandle) null desc.hasReadResolveMethod())//-----关注点{Object rep desc.invokeReadResolve(obj);if (unshared rep.getClass().isArray()) {rep cloneArray(rep);}if (rep ! obj) {// Filter the replacement objectif (rep ! null) {if (rep.getClass().isArray()) {filterCheck(rep.getClass(), Array.getLength(rep));} else {filterCheck(rep.getClass(), -1);}}handles.setObject(passHandle, obj rep);}}return obj;}...
}判断无参构造方法是否存在之后又调用了ObjectStreamClass.hasReadResolveMethod()方法来看代码
public class ObjectStreamClass implements Serializable {...boolean hasReadResolveMethod() {requireInitialized();return (readResolveMethod ! null);}...
}上述代码逻辑非常简单就是判断readResolveMethod是否为空不为空就返回true。
通过全局查找知道在私有方法ObjectStreamClass()中给readResolveMethod进行了赋值来看代码
public class ObjectStreamClass implements Serializable {...private ObjectStreamClass(final Class? cl) {...readResolveMethod getInheritableMethod(cl, readResolve, null, Object.class);... }...}上面的逻辑其实就是通过反射找到一个无参的readResolve()方法并且保存下来。现在回到ObjectInputStream 的readOrdinaryObject()方法继续往下看如果readResolve()方法存在则调用invokeReadResolve()方法来看代码
public class ObjectStreamClass implements Serializable {...Object invokeReadResolve(Object obj)throws IOException, UnsupportedOperationException{requireInitialized();if (readResolveMethod ! null) {try {return readResolveMethod.invoke(obj, (Object[]) null);//----关注点调用我们新添的方法。} catch (InvocationTargetException ex) {Throwable th ex.getTargetException();if (th instanceof ObjectStreamException) {throw (ObjectStreamException) th;} else {throwMiscException(th);throw new InternalError(th); // never reached}} catch (IllegalAccessException ex) {// should not occur, as access checks have been suppressedthrow new InternalError(ex);}} else {throw new UnsupportedOperationException();}}...}我们可以看到在invokeReadResolve()方法中用反射调用了readResolveMethod方法。
通过JDK源码分析我们可以看出虽然增加readResolve()方法返回实例解决了单例模式被破坏的问题但是实际上实例化了两次只不过新创建的对象没有被返回而已。
如果创建对象的动作发生频率加快就意味着内存分配开销也会随之增大。
有办法从根本上解决问题吗下面讲的注册式单例应运而生。
注册式单例模式
注册式单例模式又称为登记式单例模式就是将每一个实例都登记到某一个地方使用唯一的标识获取实例。
注册式单例模式有两种
一种为枚举式单例模式另一种为容器式单例模式。
枚举式单例模式
先来看枚举式单例模式的写法创建EnumSingleton类
public enum EnumSingleton {INSTANCE;private Object data;public Object getData() {return data;}public void setData(Object data) {this.data data;}public static EnumSingleton getInstance(){return INSTANCE;}
}测试代码
public class EnumSingletonTest {public static void main(String[] args) {try {EnumSingleton instance1 null;EnumSingleton instance2 EnumSingleton.getInstance();instance2.setData(new Object());FileOutputStream fos new FileOutputStream(EnumSingleton.obj);ObjectOutputStream oos new ObjectOutputStream(fos);oos.writeObject(instance2);oos.flush();oos.close();FileInputStream fis new FileInputStream(EnumSingleton.obj);ObjectInputStream ois new ObjectInputStream(fis);instance1 (EnumSingleton) ois.readObject();ois.close();System.out.println(instance1.getData());System.out.println(instance2.getData());System.out.println(instance1.getData() instance2.getData());}catch (Exception e){e.printStackTrace();}}
}运行结果
java.lang.Object2280cdac
java.lang.Object2280cdac
true它竟如此优雅简单。
解密
下载一个非常好用的Java反编译工具 Jad下载地址: https://varaneckas.com/jad/解压后配置好环境变量或在工具所在目录下使用)就可以使用命令行调用了。找到工程所在的Class目录复制EnumSingleton.class所在的路径。
然后反编译EnumSingleton.class
jad D:\eclipse-workspace\lun-spring-2\target\classes\com\lun\pattern\singleton\register\EnumSingleton.class打开反编译后生成的EnumSingleton.jad内容如下
// Decompiled by Jad v1.5.8g. Copyright 2001 Pavel Kouznetsov.
// Jad home page: http://www.kpdus.com/jad.html
// Decompiler options: packimports(3)
// Source File Name: EnumSingleton.javapackage com.lun.pattern.singleton.register;public final class EnumSingleton extends Enum
{private EnumSingleton(String s, int i){super(s, i);}public Object getData(){return data;}public void setData(Object data){this.data data;}public static EnumSingleton getInstance(){return INSTANCE;}public static EnumSingleton[] values(){EnumSingleton aenumsingleton[];int i;EnumSingleton aenumsingleton1[];System.arraycopy(aenumsingleton ENUM$VALUES, 0, aenumsingleton1 new EnumSingleton[i aenumsingleton.length], 0, i);return aenumsingleton1;}public static EnumSingleton valueOf(String s){return (EnumSingleton)Enum.valueOf(com/lun/pattern/singleton/register/EnumSingleton, s);}public static final EnumSingleton INSTANCE;private Object data;private static final EnumSingleton ENUM$VALUES[];static {//-----------------------主要关注点INSTANCE new EnumSingleton(INSTANCE, 0);ENUM$VALUES (new EnumSingleton[] {INSTANCE});}
}原来枚举式单例模式在静态代码块中就给INSTANCE进行了赋值是饿汉式单例模式的实现。 至此我们还可以试想序列化能否破坏枚举式单例模式呢不妨再来看一下JDK源码还是回到ObjectInputStream的readObject0()方法
public class ObjectInputStreamextends InputStream implements ObjectInput, ObjectStreamConstants
{...private Object readObject0(Class? type, boolean unshared) throws IOException {...case TC_ENUM:if (type String.class) {throw new ClassCastException(Cannot cast an enum to java.lang.String);}return checkResolve(readEnum(unshared));...}}我们看到在readObject0()中调用了readEnum()方法来看readEnum()方法的代码实现
public class ObjectInputStreamextends InputStream implements ObjectInput, ObjectStreamConstants
{...private Enum? readEnum(boolean unshared) throws IOException {if (bin.readByte() ! TC_ENUM) {throw new InternalError();}ObjectStreamClass desc readClassDesc(false);if (!desc.isEnum()) {throw new InvalidClassException(non-enum class: desc);}int enumHandle handles.assign(unshared ? unsharedMarker : null);ClassNotFoundException resolveEx desc.getResolveException();if (resolveEx ! null) {handles.markException(enumHandle, resolveEx);}String name readString(false);Enum? result null;Class? cl desc.forClass();if (cl ! null) {try {SuppressWarnings(unchecked)Enum? en Enum.valueOf((Class)cl, name);//-----------------------------------------关注点result en;} catch (IllegalArgumentException ex) {throw (IOException) new InvalidObjectException(enum constant name does not exist in cl).initCause(ex);}if (!unshared) {handles.setObject(enumHandle, result);}}handles.finish(enumHandle);passHandle enumHandle;return result;}...}public abstract class EnumE extends EnumEimplements Constable, ComparableE, Serializable {...public static T extends EnumT T valueOf(ClassT enumClass,String name) {T result enumClass.enumConstantDirectory().get(name);if (result ! null)return result;if (name null)throw new NullPointerException(Name is null);throw new IllegalArgumentException(No enum constant enumClass.getCanonicalName() . name);}...}我们发现枚举类型其实通过类名String和类对象类Class找到一个唯一的枚举对象。因此枚举对象不可能被类加载器加载多次。 那么反射是否能破坏枚举式单例模式呢来看一段测试代码
public class EnumSingletonTest {public static void main(String[] args) {try {Class clazz EnumSingleton.class;Constructor c clazz.getDeclaredConstructor();c.newInstance();}catch (Exception e){e.printStackTrace();}}
}运行结果
java.lang.NoSuchMethodException: com.lun.pattern.singleton.register.EnumSingleton.init()at java.base/java.lang.Class.getConstructor0(Class.java:3517)at java.base/java.lang.Class.getDeclaredConstructor(Class.java:2691)at com.lun.pattern.singleton.test.EnumSingletonTest.main(EnumSingletonTest.java:46)结果中报的是 java.lang.NoSuchMethodException异常意思是没找到无参的构造方法。这时候我们打开java.lang.Enum的源码查看它的构造方法只有一个protected类型的构造方法
public abstract class EnumE extends EnumEimplements Constable, ComparableE, Serializable {...protected Enum(String name, int ordinal) {this.name name;this.ordinal ordinal;}...
}再尝试用其创造实例
public class EnumSingletonTest {...public static void main(String[] args) {try {Class clazz EnumSingleton.class;Constructor c clazz.getDeclaredConstructor(String.class,int.class);c.setAccessible(true);EnumSingleton enumSingleton (EnumSingleton)c.newInstance(Tom,666);}catch (Exception e){e.printStackTrace();}}}运行结果
java.lang.IllegalArgumentException: Cannot reflectively create enum objectsat java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:492)at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)at com.lun.pattern.singleton.test.EnumSingletonTest.main(EnumSingletonTest.java:60)
这时错误已经非常明显了“Cannot reflectively create enum objects”即不能用反射来创建枚举类型。还是习惯性地想来看看JDK源码进入Constructor的newInstance()方法
public final class ConstructorT extends Executable {...CallerSensitiveForceInline // to ensure Reflection.getCallerClass optimizationpublic T newInstance(Object ... initargs)throws InstantiationException, IllegalAccessException,IllegalArgumentException, InvocationTargetException{Class? caller override ? null : Reflection.getCallerClass();return newInstanceWithCaller(initargs, !override, caller);}/* package-private */T newInstanceWithCaller(Object[] args, boolean checkAccess, Class? caller)throws InstantiationException, IllegalAccessException,InvocationTargetException{if (checkAccess)checkAccess(caller, clazz, clazz, modifiers);if ((clazz.getModifiers() Modifier.ENUM) ! 0)throw new IllegalArgumentException(Cannot reflectively create enum objects);//--------------------关注点ConstructorAccessor ca constructorAccessor; // read volatileif (ca null) {ca acquireConstructorAccessor();}SuppressWarnings(unchecked)T inst (T) ca.newInstance(args);return inst;}...
}从上述代码可以看到在 newInstance()方法中做了强制性的判断如果修饰符是Modifier.ENUM枚举类型则直接抛出异常。
枚举式单例模式也是《Effective Java》书中推荐的一种单例模式实现写法。JDK枚举的语法特殊性及反射也为枚举保驾护航让枚举式单例模式成为一种比较优雅的实现。
容器式单例
public class ContainerSingleton {private ContainerSingleton(){}private static MapString,Object ioc new ConcurrentHashMapString,Object();public static Object getInstance(String className){synchronized (ioc) {if (!ioc.containsKey(className)) {Object obj null;try {obj Class.forName(className).newInstance();ioc.put(className, obj);} catch (Exception e) {e.printStackTrace();}return obj;} else {return ioc.get(className);}}}
}容器式单例模式适用于实例非常多的情况便于管理。但它是非线程安全的。
MN非线程安全的深表疑问synchronized是干啥
到此注册式单例模式介绍完毕。我们再来看看Spring 中的容器式单例模式的实现代码
public abstract class AbstractAutowireCapableBeanFactory extends AbstractBeanFactory
implements AutowirecapableBeanFactory {/*Cache of unfinished FactoryBean instances: FactoryBean name -- Beanwrapper */private final MapString,Beanwrapper factoryBeanInstanceCache new ConcurrentHashNap(16)};...
}线程单例实现ThreadLocal
讲讲线程单例实现ThreadLocal。ThreadLocal不能保证其创建的对象是全局唯一的但是能保证在单个线程中是唯一的。下面来看代码
public class ThreadLocalSingleton {private static final ThreadLocalThreadLocalSingleton threadLocalInstance new ThreadLocalThreadLocalSingleton(){Overrideprotected ThreadLocalSingleton initialValue() {return new ThreadLocalSingleton();}};private ThreadLocalSingleton(){}public static ThreadLocalSingleton getInstance(){return threadLocalInstance.get();}
}测试代码
public class ThreadLocalSingletonTest {public static void main(String[] args) {System.out.println(ThreadLocalSingleton.getInstance());System.out.println(ThreadLocalSingleton.getInstance());System.out.println(ThreadLocalSingleton.getInstance());System.out.println(ThreadLocalSingleton.getInstance());System.out.println(ThreadLocalSingleton.getInstance());Runnable task ()-{System.out.println(ThreadLocalSingleton.getInstance());};Thread t1 new Thread(task);Thread t2 new Thread(task);t1.start();t2.start();System.out.println(End);}
}运行结果
com.lun.pattern.singleton.threadlocal.ThreadLocalSingleton5e265ba4
com.lun.pattern.singleton.threadlocal.ThreadLocalSingleton5e265ba4
com.lun.pattern.singleton.threadlocal.ThreadLocalSingleton5e265ba4
com.lun.pattern.singleton.threadlocal.ThreadLocalSingleton5e265ba4
com.lun.pattern.singleton.threadlocal.ThreadLocalSingleton5e265ba4
End
com.lun.pattern.singleton.threadlocal.ThreadLocalSingleton15864d5a
com.lun.pattern.singleton.threadlocal.ThreadLocalSingleton481d0703在主线程中无论调用多少次获取到的实例都是同一个都在两个子线程中分别获取到了不同的实例。
那么ThreadLocal是如何实现这样的效果的呢单例模式为了达到线程安全的目的会给方法上锁以时间换空间。ThreadLocal将所有的对象全部放在ThreadLocalMap中为每个线程都提供一个对象实际上是以空间换时间来实现线程隔离的。
单例模式小结
单例模式可以保证内存里只有一个实例减少了内存的开销还可以避免对资源的多重占用。单例模式看起来非常简单实现起来其实也非常简单但是在面试中却是一个高频面试点。
参考资料
《Spring5核心原理与30个类手写实战》
