java单例模式实现

时间 2020-06-03

标签 java 模式实现栏目 Java 繁體版

原文原文链接

1.最基本的单例模式

/** * @author LearnAndGet * @time 2018年11月13日 * 最基本的单例模式 */
public class SingletonV1 { private static SingletonV1 instance = new SingletonV1();; //构造函数私有化
    private SingletonV1() {} public static SingletonV1 getInstance() { return instance; } }

import org.junit.Test; public class SingletonTest { @Test public void test01() throws Exception { SingletonV1 s1 = SingletonV1.getInstance(); SingletonV1 s2 = SingletonV1.getInstance(); System.out.println(s1.hashCode()); System.out.println(s2.hashCode()); } } //运行结果以下：
589873731
589873731

2.类加载时不初始化实例的模式

　　上述单例模式在类加载的时候，就会生成实例，可能形成空间浪费，若是须要修改为，在须要使用时才生成实例，则可修改代码以下：html

 1 public class SingletonV2 {  2     
 3     private static SingletonV2 instance;  4     
 5     //构造函数私有化
 6     private SingletonV2() {}  7 
 8     public static SingletonV2 getInstance(){ 10         if(instance == null) 11  { 12             instance = new SingletonV2(); 13  } 14         return instance; 15  } 16 }

然而，上述方案虽然在类加载时不会生成实例，可是存在线程安全问题，若是线程A在执行到第10行时，线程B也进入该代码块，刚好也执行好第10行，此时若是实例还没有生成，则线程A和线程B都会执行第12行的代码，各自生成一个实例，此时就违背了单例模式的设计原则。实际测试代码以下：java

public class SingletonTest { @Test public void test02() throws Exception { for(int i=0;i<1000;i++) { Thread th1 = new getInstanceThread(); th1.start(); } } class getInstanceThread extends Thread { public void run() { try { SingletonV2 s = SingletonV2.getInstance(); System.out.println(Thread.currentThread().getName()+" get Instance "+s.hashCode()+" Time: "+System.currentTimeMillis()); }catch(Exception e) { e.printStackTrace(); } } } }

通过屡次测试，可能产生以下输出结果：安全

3.线程安全的单例模式

　　在上述单例模式下进行改进，在getInstance方法前加入 Sychronized关键字，来实现线程安全，修改后代码以下：并发

 1 public class SingletonV3 {  2     
 3     private static SingletonV3 instance;  4     
 5     //构造函数私有化
 6     private SingletonV3() {}  7 
　　　　//synchronized关键字在静态方法上，锁定的是当前类：sychronized关键字
 8     public static synchronized SingletonV3 getInstance()  9  { 10         if(instance == null) 11  { 12             instance = new SingletonV3(); 13  } 14         return instance; 15  } 16 }

增长sychronized关键字后，确实可以改善线程安全问题，可是也带来了额外的锁开销。性能受到必定影响。举例来讲，此时若是有1000个线程都须要使用SingletonV3实例，由于加锁的位置在getInstance上，所以，每一个线程都必须等待其余获取了锁的线程彻底执行完锁中的方法后，才可以进入该方法并获取本身的实例。eclipse

4.双重校检+线程安全单例模式

　　因而能够在上述代码的基础上，只有当Singleton实例未被初始化时，对实例化方法加锁便可。在Singleton实例已经被初始化时，无需加锁，直接返回当前Singleton对象。代码以下：函数

 1     private static SingletonV4 instance;  2     
 3     //构造函数私有化
 4     private SingletonV4() {}  5 
 6     public static SingletonV4 getInstance()  7  {  8         if(instance == null)  9  { 10             synchronized(SingletonV4.class) 11  { 12                 //双重校检
13                 if(instance == null) 14  { 15                     instance = new SingletonV4(); 16  } 17  } 18  } 19         return instance; 20     }

5.内部类单例模式

　　尽管上述方案解决了同步问题，双重校检也使得性能开销大大减少，可是，只有有synchronized关键字的存在。性能多多少少仍是会有一些影响，此时，咱们想到了 "内部类"的用法。性能

　　①.内部类不会随着类的加载而加载测试

　　②.一个类被加载，当且仅当其某个静态成员（静态域、构造器、静态方法等）被调用时发生。lua

　　静态内部类随着方法调用而被加载，只加载一次，不存在并发问题，因此是线程安全。基于此，修改代码以下：spa

 /推荐指数：★★★★★

 1 public class SingletonV5 {  2     //构造函数私有化
 3     private SingletonV5() {}  4 
 5     static class SingetonGet  6  {  7         private static final SingletonV5 instance = new SingletonV5();  8  }  9     
10     public static SingletonV5 getInstance() 11  { 12         return SingetonGet.instance; 13  } 14 }

6.反射都不能破坏的单例模式

　　静态内部类实现的单例模式，是目前比较推荐的方式，可是在java功能强大反射的机制下，它就是个弟弟，此时利用反射仍然可以建立出多个实例，如下是建立实例的代码：

 1  @Test  2     public void test4()  3  {  4         //普通方式获取实例s1，s2
 5         SingletonV5 s1 = SingletonV5.getInstance();  6         SingletonV5 s2 = SingletonV5.getInstance();  7         //利用反射获取实例s3,s4
 8         SingletonV5 s3 = null;  9         SingletonV5 s4 = null; 10         try 
11  { 12             Class<SingletonV5> clazz = SingletonV5.class; 13             Constructor<SingletonV5> constructor = clazz.getDeclaredConstructor(); 14             constructor.setAccessible(true); 15             s3 = constructor.newInstance(); 16             s4 = constructor.newInstance(); 17         }catch(Exception e) 18  { 19  e.printStackTrace(); 20  } 21         
22  System.out.println(s1.hashCode()); 23  System.out.println(s2.hashCode()); 24  System.out.println(s3.hashCode()); 25  System.out.println(s4.hashCode()); 26     }

输出结果以下：

能够看到，s1和s2拥有相同的哈希码，所以他们是同一个实例，可是s三、s4，是经过反射后用构造函数从新构造生成的实例，他们均与s1，s2不一样。此时单例模式下产生了多个不一样的对象，违反了设计原则。

基于上述反射可能形成的单例模式失效，考虑在私有的构造函数中添加是否初始化的标记位，使私有构造方法只可能被执行一次。

public class SingletonV6 { //是否已经初始化过的标记位
    private static boolean isInitialized = false; //构造函数中，当实例已经被初始化时，不能继续获取新实例
    private SingletonV6() { synchronized(SingletonV6.class) { if(isInitialized == false) { isInitialized = !isInitialized; }else { throw new RuntimeException("单例模式被破坏..."); } } } static class SingetonGet { private static final SingletonV6 instance = new SingletonV6(); } public static SingletonV6 getInstance() { return SingetonGet.instance; } }

测试代码以下：

 @Test public void test5() { SingletonV6 s1 = SingletonV6.getInstance(); SingletonV6 s2 = null; try { Class<SingletonV6> clazz = SingletonV6.class; Constructor<SingletonV6> constructor = clazz.getDeclaredConstructor(); constructor.setAccessible(true); s2 = constructor.newInstance(); }catch(Exception e) { e.printStackTrace(); } System.out.println(s1.hashCode()); System.out.println(s2.hashCode()); }

运行上述代码时，会抛出异常：

java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Unknown Source) at SingletonTest.SingletonTest.test5(SingletonTest.java:98) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:538) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:760) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:206) Caused by: java.lang.RuntimeException: 单例模式被破坏... at SingletonTest.SingletonV6.<init>(SingletonV6.java:26) ... 28 more 2052001577

7.序列化反序列化都不能破坏的单例模式

　　通过上述改进，反射也不可以破坏单例模式了。可是，依然存在一种可能形成上述单例模式产生两个不一样的实例，那就是序列化。当一个对象A通过序列化，而后再反序列化，获取到的对象B和A是不是同一个实例呢，验证代码以下：

/** * @Author {LearnAndGet} * @Time 2018年11月13日 * @Discription:测试序列化并反序列化是否仍是同一对象 */
package SingletonTest; import java.io.FileInputStream; import java.io.FileOutputStream; import java.io.ObjectInput; import java.io.ObjectInputStream; import java.io.ObjectOutput; import java.io.ObjectOutputStream; public class Main { /** * @param args */
    public static void main(String[] args) { // TODO Auto-generated method stub
        SingletonV6 s1 = SingletonV6.getInstance(); ObjectOutput objOut = null; try { //将s1序列化（记得将Singleton实现Serializable接口）
            objOut = new ObjectOutputStream(new FileOutputStream("c:\\a.objFile")); objOut.writeObject(s1); objOut.close(); //反序列化获得s2
            ObjectInput objIn = new ObjectInputStream(new FileInputStream("c:\\a.objFile")); SingletonV6 s2 = (SingletonV6) objIn.readObject(); objIn.close(); System.out.println(s1.hashCode()); System.out.println(s2.hashCode()); } catch (Exception e) { // TODO Auto-generated catch block
 e.printStackTrace(); } } }

　　输出结果以下：

1118140819
990368553

可见，此时序列化前的对象s1和通过序列化->反序列化步骤后的到的对象s2，并非同一个对象，所以，出现了两个实例，再次违背了单例模式的设计原则。

为了消除问题，在单例模式类中，实现Serializable接口以后添加对readResolve()方法的实现：当从I/O流中读取对象时，readResolve()方法都会被调用到。实际上就是用readResolve()中返回的对象直接替换在反序列化过程当中建立的对象，而被建立的对象则会被垃圾回收掉。这就确保了在序列化和反序列化的过程当中没人能够建立新的实例,修改后的代码以下：

package SingletonTest; import java.io.Serializable; /** * @author LearnAndGet * * @time 2018年11月13日 * */
public class SingletonV6  implements Serializable{ //是否已经初始化过的标记位
    private static boolean isInitialized = false; //构造函数中，当实例已经被初始化时，不能继续获取新实例
    private SingletonV6() { synchronized(SingletonV6.class) { if(isInitialized == false) { isInitialized = !isInitialized; }else { throw new RuntimeException("单例模式被破坏..."); } } } static class SingetonGet { private static final SingletonV6 instance = new SingletonV6(); } public static SingletonV6 getInstance() { return SingetonGet.instance; } //实现readResolve方法
    private Object readResolve() { return getInstance(); } }

从新运行上述序列化和反序列过程，能够发现，此时获得的对象是同一对象。

1118140819
1118140819

8.总结

　　在实际开发中，根据本身的须要，选择对应的单例模式便可，不同非要实现第7节中那种无坚不摧的单例模式。毕竟不是全部场景下都须要实现序列化接口，也并非全部人都会用反射来破坏单例模式。所以比较经常使用的是第5节中的，内部类单例模式，代码简洁明了，且节省空间。