单例模式的六种写法

黑客技术
点击右侧关注,了解黑客的世界!

Java开发进阶
点击右侧关注,掌握进阶之路!

Python开发
点击右侧关注,探讨技术话题!


作者丨酸辣汤
https://juejin.im/post/5d484e2ff265da03ec2e4a47


1


   

定义
确保某个类只有一个实例,而且自行实例化并向整个系统提供这个实例
2


   

UML结构图

3


   

场景
确保某个类只有一个对象的场景,比如一个对象需要消耗的资源过多,访问io、数据库,需要提供全局配置的场景
4


   

几种单例模式
4.1


   

饿汉式
声明静态时已经初始化,在获取对象之前就初始化
优点:获取对象的速度快,线程安全(因为虚拟机保证只会装载一次,在装载类的时候是不会发生并发的)
缺点:耗内存(若类中有静态方法,在调用静态方法的时候类就会被加载,类加载的时候就完成了单例的初始化,拖慢速度)
1public class EagerSingleton {
 2    //饿汉单例模式
 3    //在类加载时就完成了初始化,所以类加载较慢,但获取对象的速度快
 4    private static EagerSingleton instance = new EagerSingleton();//静态私有成员,已初始化
 5
 6    private EagerSingleton() 
 7    
{
 8        //私有构造函数
 9    }
10
11    public static EagerSingleton getInstance()    //静态,不用同步(类加载时已初始化,不会有多线程的问题)
12    
{
13        return instance;
14    }
15
16}

4.2


   

懒汉式
synchronized同步锁:多线程下保证单例对象唯一性
优点:单例只有在使用时才被实例化,一定程度上节约了资源
缺点:加入synchronized关键字,造成不必要的同步开销。不建议使用。
 1    //懒汉式单例模式
 2    //比较懒,在类加载时,不创建实例,因此类加载速度快,但运行时获取对象的速度慢
 3    private static LazySingleton intance = null;//静态私用成员,没有初始化
 4
 5    private LazySingleton()
 6    
{
 7        //私有构造函数
 8    }
 9
10    public static synchronized LazySingleton getInstance()    //静态,同步,公开访问点
11    
{
12        if(intance == null)
13        {
14            intance = new LazySingleton();
15        }
16        return intance;
17    }
18}


4.3


   

Double Check Lock(DCL)实现单例(使用最多的单例实现之一)
(双重锁定体现在两次判空)
优点:既能保证线程安全,且单例对象初始化后调用getInstance不进行同步锁,资源利用率高
缺点:第一次加载稍慢,由于Java内存模型一些原因偶尔会失败,在高并发环境下也有一定的缺陷,但概率很小。
代码示例:
 1public class SingletonKerriganD {
 2
 3    /**
 4     * 单例对象实例
 5     */

 6    private volatile static SingletonKerriganD instance = null;//这里加volatitle是为了避免DCL失效
 7
 8    //DCL对instance进行了两次null判断
 9    //第一层判断主要是为了避免不必要的同步
10    //第二层的判断则是为了在null的情况下创建实例。
11    public static SingletonKerriganD getInstance({
12        if (instance == null) {
13            synchronized (SingletonKerriganD.class) {
14                if (instance == null) {
15                    instance = new SingletonKerriganD();
16
17            }
18        }
19        return instance;
20    }
21}


什么是DCL失效问题?

假如线程A执行到instance = new SingletonKerriganD(),大致做了如下三件事:
  1. 给实例分配内存
  2. 调用构造函数,初始化成员字段
  3. 将instance 对象指向分配的内存空间(此时sInstance不是null)
如果执行顺序是1-3-2,那多线程下,A线程先执行3,2还没执行的时候,此时instance!=null,这时候,B线程直接取走instance ,使用会出错,难以追踪。JDK1.5及之后的volatile 解决了DCL失效问题(双重锁定失效)
4.4


   

静态内部类单例模式
由于在调用 SingletonHolder.instance 的时候,才会对单例进行初始化,而且通过反射,是不能从外部类获取内部类的属性的。所以这种形式,很好的避免了反射入侵。
优点:线程安全、保证单例对象唯一性,同时也延迟了单例的实例化,避免了反射入侵
缺点:需要两个类去做到这一点,虽然不会创建静态内部类的对象,但是其 Class 对象还是会被创建,而且是属于永久代的对象。(综合来看,私以为这种方式是最好的单例模式)
 1public class Singleton {
 2    private Singleton(){
 3
 4    }
 5    private static class SingletonHolder{
 6        private final static Singleton instance=new Singleton();
 7    }
 8    public static Singleton getInstance(){
 9        return SingletonHolder.instance;
10    }
11}


这种方式如何保证单例且线程安全?

当getInstance方法第一次被调用的时候,它第一次读取SingletonHolder.instance,内部类SingletonHolder类得到初始化;而这个类在装载并被初始化的时候,会初始化它的静态域,从而创建Singleton的实例,由于是静态的域,因此只会在虚拟机装载类的时候初始化一次,并由虚拟机来保证它的线程安全性。这个模式的优势在于,getInstance方法并没有被同步,并且只是执行一个域的访问,因此延迟初始化并没有增加任何访问成本。

这种方式能否避免反射入侵?

答案是:不能。网上很多介绍到静态内部类的单例模式的优点会提到“通过反射,是不能从外部类获取内部类的属性的。所以这种形式,很好的避免了反射入侵”,这是错误的,反射是可以获取内部类的属性(想了解更多反射的知识请看 java反射全解),入侵单例模式根本不在话下,直接看下面的例子:
单例类如下:
 1package eft.reflex;
 2
 3public class Singleton {
 4
 5    private int a;
 6
 7    private Singleton(){
 8        a=123;
 9    }
10    private static class SingletonHolder{
11        private final static Singleton instance=new Singleton();
12    }
13    public static Singleton getInstance(){
14        return SingletonHolder.instance;
15    }
16
17    public int getTest(){
18        return a;
19    }
20}
入侵与测试代码如下:
 1    public static void main(String[] args) throws Exception {
 2        //通过反射获取内部类SingletonHolder的instance实例fInstance
 3        Class cInner=Class.forName("eft.reflex.Singleton$SingletonHolder");
 4        Field fInstance=cInner.getDeclaredField("instance");
 5
 6        //将此域的final修饰符去掉
 7        Field modifiersField = Field.class.getDeclaredField("modifiers");
 8        modifiersField.setAccessible(true);
 9        modifiersField.setInt(fInstance, fInstance.getModifiers() & ~Modifier.FINAL);
10
11        //打印单例的某个属性,接下来要通过反射去篡改这个值
12        System.out.println("a="+ Singleton.getInstance().getTest());
13
14        //获取该单例的a属性fieldA
15        fInstance.setAccessible(true);
16        Field fieldA=Singleton.class.getDeclaredField("a");
17
18        //通过反射类构造器创建新的实例newSingleton(这里因为无参构造函数是私有的,不能通过Class.newInstance创建实例)
19        Constructor constructor=Singleton.class.getDeclaredConstructor();
20        constructor.setAccessible(true);
21        Singleton newSingleton= (Singleton) constructor.newInstance();
22
23        //让fInstance指向新的实例newSingleton,此时我们的单例已经被偷梁换柱了!
24        fInstance.set(null,newSingleton);
25        //为盗版的单例的属性a设置新的值
26        fieldA.setAccessible(true);
27        fieldA.set(newSingleton,888);
28
29        //测试是否成功入侵
30        System.out.println("被反射入侵后:a="+ Singleton.getInstance().getTest());
31        fieldA.set(newSingleton,777);
32        System.out.println("被反射入侵后:a="+ Singleton.getInstance().getTest());
33}
输出结果:
1a=123
2被反射入侵后:a=888
3被反射入侵后:a=777


注意:上述四种方法要杜绝在被反序列化时重新声明对象,需要加入如下方法:
1private Object readResolve() throws ObjectStreamException{
2    return sInstance;
3}
为什么呢?因为当JVM从内存中反序列化地"组装"一个新对象时,自动调用 readResolve方法来返回我们指定好的对象
4.5


   

枚举单例
枚举反序列化不会生成新的实例
优点:线程安全
缺点:枚举耗内存,能不用枚举就不用
 1class Resource{
 2}
 3
 4public enum SomeThing {
 5    INSTANCE;
 6    private Resource instance;
 7    SomeThing() {
 8        instance = new Resource();
 9    }
10    public Resource getInstance() {
11        return instance;
12    }
13}
获取资源的方式很简单,只要 SomeThing.INSTANCE.getInstance() 即可获得所要实例。

这种方式如何保证单例?

首先,在枚举中我们明确了构造方法限制为私有,在我们访问枚举实例时会执行构造方法,同时每个枚举实例都是static final类型的,也就表明只能被实例化一次。在调用构造方法时,我们的单例被实例化。也就是说,因为enum中的实例被保证只会被实例化一次,所以我们的INSTANCE也被保证实例化一次。
上面示例中的枚举字节码文件如下:
1...
2public static final eft.reflex.SomeThing INSTANCE;
3    flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL, ACC_ENUM
4
5...
可以看出,会自动生成 ACC_STATIC, ACC_FINAL这两个修饰符

枚举类型为什么是线程安全的?

我们定义的一个枚举,在第一次被真正用到的时候,会被虚拟机加载并初始化,而这个初始化过程是线程安全的。而我们知道,解决单例的并发问题,主要解决的就是初始化过程中的线程安全问题。所以,由于枚举的以上特性,枚举实现的单例是天生线程安全的。
4.6


   

使用容器实现单例模式
在程序的初始化,将多个单例类型注入到一个统一管理的类中,使用时通过key来获取对应类型的对象,这种方式使得我们可以管理多种类型的单例,并且在使用时可以通过统一的接口进行操作。这种方式是利用了Map的key唯一性来保证单例。
 1public class SingletonManager { 
 2
 3 private static Map<String,Object> map=new HashMap<String, Object>(); 
 4
 5 private SingletonManager(){}
 6
 7 public static void registerService(String key,Object instance){
 8     if (!map.containsKey(key)){
 9         map.put(key,instance); 
10     } 
11 } 
12
13 public static Object getService(String key)
14    return map.get(key); 
15 } 
16
17}



5


   

总结
所有单例模式需要处理得问题都是:
  1. 将构造函数私有化
  2. 通过静态方法获取一个唯一实例
  3. 保证线程安全
  4. 防止反序列化造成的新实例等。
推荐使用:DCL、静态内部类
5.1


   

单例模式优点
  1. 只有一个对象,内存开支少、性能好(当一个对象的产生需要比较多的资源,如读取配置、产生其他依赖对象时,可以通过应用启动时直接产生一个单例对象,让其永驻内存的方式解决)
  2. 避免对资源的多重占用(一个写文件操作,只有一个实例存在内存中,避免对同一个资源文件同时写操作)
  3. 在系统设置全局访问点,优化和共享资源访问(如:设计一个单例类,负责所有数据表的映射处理)
5.2


   

单例模式缺点
  1. 一般没有接口,扩展难
  2. android中,单例对象持有Context容易内存泄露,此时需要注意传给单例对象的Context最好是Application Context
6


   

android源码中的单例模式
单例模式应用广泛,根据实际业务需求来,这里只引出源码中个别场景,不再详解,有兴趣的读者可以深入查看源码
在平时的Android开发中,我们经常会通过Context来获取系统服务,比如ActivityManagerService,AccountManagerService等系统服务,实际上ContextImpl也是通过SystemServiceRegistry.getSystemService来获取具体的服务,SystemServiceRegistry是个final类型的类。这里使用容器实现单例模式
SystemServiceRegistry 部分代码:
 1final class SystemServiceRegistry {
 2    private static final HashMap<Class<?>, String> SYSTEM_SERVICE_NAMES = new HashMap<Class<?>, String>();
 3    private static final HashMap<String, ServiceFetcher<?>> SYSTEM_SERVICE_FETCHERS = new HashMap<String, ServiceFetcher<?>>();
 4    private SystemServiceRegistry() { }
 5
 6    static {
 7        registerService(Context.LAYOUT_INFLATER_SERVICE, LayoutInflater.class,
 8                new CachedServiceFetcher<LayoutInflater>() {
 9            @Override
10            public LayoutInflater createService(ContextImpl ctx) {
11                return new PhoneLayoutInflater(ctx.getOuterContext());
12            }});
13        registerService(Context.ACTIVITY_SERVICE, ActivityManager.class,
14                new CachedServiceFetcher<ActivityManager>() {
15            @Override
16            public ActivityManager createService(ContextImpl ctx) {
17                return new ActivityManager(ctx.getOuterContext(), ctx.mMainThread.getHandler());
18            }});
19        .......
20    }
21
22    public static Object getSystemService(ContextImpl ctx, String name) {
23        ServiceFetcher<?> fetcher = SYSTEM_SERVICE_FETCHERS.get(name);
24        return fetcher != null ? fetcher.getService(ctx) : null;
25    }
26    private static <T> void registerService(String serviceName, Class<T> serviceClass, ServiceFetcher<T> serviceFetcher) {
27        SYSTEM_SERVICE_NAMES.put(serviceClass, serviceName);
28        SYSTEM_SERVICE_FETCHERS.put(serviceName, serviceFetcher);
29    }
30    ......
31}
WindowManagerGlobal:
1public static WindowManagerGlobal getInstance() {
2    synchronized (WindowManagerGlobal.class) {
3        if (sDefaultWindowManager == null) {
4            sDefaultWindowManager = new WindowManagerGlobal();
5        }
6        return sDefaultWindowManager;
7    }
8}


 推荐↓↓↓ 

?16个技术公众号】都在这里!

涵盖:程序员大咖、源码共读、程序员共读、数据结构与算法、黑客技术和网络安全、大数据科技、编程前端、Java、Python、Web编程开发、Android、iOS开发、Linux、数据库研发、幽默程序员等。

万水千山总是情,点个 “在看” 行不行