单例模式

说到单例模式,顾名思义可以知道指的是一个类在整个系统中有且只有一个实例,就像古代的皇帝一样是唯一的唯吾独尊的。那我们今天就来研究一下这个霸道的“单例模式”。

首先我们来看看,单例模式的定义:一个类有且仅有一个实例,并且自行实例化并向整个系统提供。那么实现单例的步骤有哪些呢?

  1. 既然单例模式要求有且只有一个实例,那首先得私有化构造函数——让用户不能自行new出对象。

  2. 要求要自行实例化并向整个系统提供该实例,那就得自己new出一个唯一的实例,并提供一个公有静态的方法向外提供这个实例。

public class Emperor {  
    //1、私有化构造函数  
    private Emperor() {  
    }  
    //2、自行实例化出一个唯一的对象  
    private static Emperor mEmperor = new Emperor();  
    //3、向外提供一个公有的静态方法用于获取该唯一实例  
    public static Emperor getInstance(){  
        return mEmperor;  
    }  
}

从上述代码我们可以发现,确实实现了单例模式,但是该Emperor类,在类加载的时候就实例化出了mHungryEmperor实例,这就是传说中的“饿汉式”。这显然不是我们希望看到的,我们希望在我们需要该实例的时候再去创建,那我们再将代码改一下:

public class LazyEmperor {  
    //1、私有化构造函数。  
    private LazyEmperor() {  
    }  
    //2、声明一个LazyEmperor成员变量。  
    private static LazyEmperor mLazyEmperor;  
    //3、提供一个公有的静态方法向外提供唯一实例,先判断该实例是否存在,不存在再new  
    public static LazyEmperor getInstance(){  
        if (mLazyEmperor == null){  
            mLazyEmperor = new LazyEmperor();  
        }  
        return mLazyEmperor;  
    }  
}

从上述代码我们可以看到,是当我们调用getInstance方法的时候才将mLazyEmperor对象创建出来,不会过早创建,这就是传说中的“懒汉式”。但是由于这里存在判断,那么我们肯定要考虑线程安全的问题,当多线程并发访问的时候会不会出现线程不安全的情况呢?我们举个例子:

假如现在有A、B两个线程同时访问该LazyEmperor类,当A线程走到getInstance方法的时候判断mLazyEmperor是否为空,此时肯定是为空的,那么A线程准备new 一个LazyEmperor对象。但是A线程还没来得及new的时候B线程也走到了getInstance方法判断mLazyEmperor是否为空,显然此时还是为空的,那么B线程也准备new一个LazyEmperor对象。此时就有了两个LazyEmperor对象,就不符合单例模式的要求了。

那么,我们怎么解决这类问题呢?针对线程安全性问题,我们一般的方法是使用synchronized加锁:

public class LazyEmperor {  
    //1、私有化构造函数。  
    private LazyEmperor() {  
    }  
    //2、声明一个LazyEmperor成员变量。  
    private static LazyEmperor mLazyEmperor;  
    //3、提供一个公有的静态方法向外提供唯一实例,先判断该实例是否存在,不存在再new  
    public synchronized static LazyEmperor getInstance(){  
        if (mLazyEmperor == null){  
            mLazyEmperor = new LazyEmperor();  
        }  
        return mLazyEmperor;  
    }  
}

但是我们都知道,synchronized给系统带来的消耗较大,如果像上述代码所示,那么每次调用getInstance方法都得加锁,这样难免会给系统带来不必要的消耗。我们的想法是:在需要加锁的时候再加锁,也就是需要考虑线程安全性的时候使用synchronize。如果mLazyEmperor不为空,则不需要考虑线程安全问题。那我们再将代码改一下:

public class LazyEmperor {  
    //1、私有化构造函数。  
    private LazyEmperor() {  
    }  
    //2、声明一个LazyEmperor成员变量。  
    private static LazyEmperor mLazyEmperor;  
    //3、提供一个公有的静态方法向外提供唯一实例,先判断该实例是否存在,不存在再new  
    public static LazyEmperor getInstance(){  
        //第一次判断是为了减少不必要的加锁  
        if (mLazyEmperor == null){  
            synchronized(LazyEmperor.class){  
                //第二次判断是为了确保只有一个对象  
                if (mLazyEmperor == null){  
                    mLazyEmperor = new LazyEmperor();  
                }  
            }  
        }  
        return mLazyEmperor;  
    }  
}

上述代码就是传说中的“双重判断锁机制”,既保证了在多线程并发访问的情况下能保持单例,又满足了在需要的时候才创建实例,不会过早创建。

但是人总是不满足的,“双重判断锁机制”虽然好,但它还是用到了synchronize,多少会带来一些不必要的消耗。如果能不使用synchronize就能既保证了在多线程并发访问的情况下能保持单例,又满足了在需要的时候才创建实例就好了。那我们来看一下下面这种写法吧:

public class Emperor {  
    //私有化构造函数  
    private Emperor() {  
    }  
    //声明一个静态类,为该类的静态成员变量赋值为Emperor的唯一实例  
    private static class SingleInstance{  
        private static Emperor INSTANCE = new Emperor();  
    }  
    //声明一个公有的静态方法获取唯一实例  
    public static Emperor getInstance(){  
        return SingleInstance.INSTANCE;  
    }  
}

上面这种写法是不是很新奇,从上述代码可以看出,当静态内部类加载的时候才会创建实例,也就是调用getInstance方法的时候才会创建实例,保证了不会过早创建。而且这种写法也不会出现线程安全问题,反正只会在静态内部类实例化的时候创建一次对象。

以上方法当然已经很好了,但是如果要考虑到反序列化的时候会重新创建对象的话,“静态内部类”实现单例显然还不是最佳的方法,那么那种方法能够防止反序列化时重复创建实例呢?——那就是使用枚举来实现单例:

public enum  EnumEmperor {  
    INSTANCE;  

    private EnumEmperor() {  
        //初始化实例时该做的事  
    }  
    //任何方法  
    public void doAnything(){  

    }  
}

当我们要使用该单例对象的时候,我们就这样做:

EnumEmperor.INSTANCE.doAnything();

这样,既确保了线程安全,也确保了反序列化时不会重复创建对象。

以上就是单例的多种写法,建议使用静态内部类和enum的形式来设计单例。因为enum是JDK1.5之后才引入的,所以使用时要注意JDK版本。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值