一、什么是单例模式
单例模式是一种常用的软件设计模式,其定义是单例对象的类只能允许一个实例存在。
许多时候整个系统只需要拥有一个的全局对象,这样有利于我们协调系统整体的行为。比如在某个服务器程序中,该服务器的配置信息存放在一个文件中,这些配置数据由一个单例对象统一读取,然后服务进程中的其他对象再通过这个单例对象获取这些配置信息。这种方式简化了在复杂环境下的配置管理。
单例的实现主要是通过以下两个步骤:
- 1、将该类的构造方法定义为私有方法,这样其他处的代码就无法通过调用该类的构造方法来实例化该类的对象,只有通过该类提供的静态方法来得到该类的唯一实例;
- 2、在该类内提供一个静态方法,当我们调用这个方法时,如果类持有的引用不为空就返回这个引用,如果类保持的引用为空就创建该类的实例并将实例的引用赋予该类保持的引用。
二、单例模式的应用场景
举一个小例子,在我们的windows桌面上,我们打开了一个回收站,当我们试图再次打开一个新的回收站时,Windows系统并不会为你弹出一个新的回收站窗口。,也就是说在整个系统运行的过程中,系统只维护一个回收站的实例。这就是一个典型的单例模式运用。
继续说回收站,我们在实际使用中并不存在需要同时打开两个回收站窗口的必要性。假如我每次创建回收站时都需要消耗大量的资源,而每个回收站之间资源是共享的,那么在没有必要多次重复创建该实例的情况下,创建了多个实例,这样做就会给系统造成不必要的负担,造成资源浪费。
再举一个例子,网站的计数器,一般也是采用单例模式实现,如果你存在多个计数器,每一个用户的访问都刷新计数器的值,这样的话你的实计数的值是难以同步的。但是如果采用单例模式实现就不会存在这样的问题,而且还可以避免线程安全问题。同样多线程的线程池的设计一般也是采用单例模式,这是由于线程池需要方便对池中的线程进行控制
同样,对于一些应用程序的日志应用,或者web开发中读取配置文件都适合使用单例模式,如HttpApplication 就是单例的典型应用。
从上述的例子中我们可以总结出适合使用单例模式的场景和优缺点:
适用场景:
- 1、需要生成唯一序列的环境
- 2、需要频繁实例化然后销毁的对象。
- 3、创建对象时耗时过多或者耗资源过多,但又经常用到的对象。
- 4、方便资源相互通信的环境
三、单例模式的优缺点
优点:
- 在内存中只有一个对象,节省内存空间;
- 避免频繁的创建销毁对象,可以提高性能;
- 避免对共享资源的多重占用,简化访问;
- 为整个系统提供一个全局访问点。
缺点:
- 不适用于变化频繁的对象;
- 滥用单例将带来一些负面问题,如为了节省资源将数据库连接池对象设计为的单例类,可能会导致共享连接池对象的程序过多而出现连接池溢出;
- 如果实例化的对象长时间不被利用,系统会认为该对象是垃圾而被回收,这可能会导致对象状态的丢失;
四、单例模式的实现
1、饿汉式
public class HungrySingleton {
private final static HungrySingleton singleton = new HungrySingleton();
private HungrySingleton(){
}
public static HungrySingleton getInstance(){
return singleton;
}
}
public class HungrySingleton {
private final static HungrySingleton singleton;
static {
singleton = new HungrySingleton();
}
private HungrySingleton(){
}
public static HungrySingleton getInstance(){
return singleton;
}
}
类加载的方式是按需加载,且加载一次。因此,在上述单例类被加载时,就会实例化一个对象并交给自己的引用,供系统使用;而且,由于这个类在整个生命周期中只会被加载一次,因此只会创建一个实例,即能够充分保证单例。该种模式以空间换时间,故不存在线程安全问题。
优点:这种写法比较简单,就是在类装载的时候就完成实例化。避免了线程同步问题。
缺点:在类装载的时候就完成实例化,没有达到Lazy Loading的效果。如果从始至终从未使用过这个实例,则会造成内存的浪费。
2、懒汉式
public class LazySingleton {
public static LazySingleton singleton = null;
private LazySingleton(){
}
public static LazySingleton getInstance(){
if(singleton == null){
singleton = new LazySingleton();
}
return singleton;
}
}
从懒汉式单例可以看到,单例实例被延迟加载,即只有在真正使用的时候才会实例化一个对象并交给自己的引用。
这种写法起到了Lazy Loading的效果,但是只能在单线程下使用。如果在多线程下,一个线程进入了if (singleton == null)判断语句块,还未来得及往下执行,另一个线程也通过了这个判断语句,这时便会产生多个实例。所以在多线程环境下不可使用这种方式。
改进方式:
public class LazySingleton {
public static LazySingleton singleton = null;
private LazySingleton(){
}
public synchronized static LazySingleton getInstance(){
if(singleton == null){
singleton = new LazySingleton();
}
return singleton;
}
}
public class LazySingleton {
public static LazySingleton singleton = null;
private LazySingleton(){
}
public static LazySingleton getInstance(){
synchronized (LazySingleton.class){
if(singleton == null){
singleton = new LazySingleton();
}
}
return singleton;
}
}
上面这两种改进方式采用synchronized去解决线程安全问题的,但是上面写法的synchronized加锁粒度太大比较消耗资源,有加锁和解锁的开销
3、双重加锁机制
public class LazyDoubleCheckSingleton {
public volatile static LazyDoubleCheckSingleton singleton = null;
private LazyDoubleCheckSingleton(){
}
public static LazyDoubleCheckSingleton getInstance(){
//先判断是否存在,不存在再加锁处理
if(singleton == null){
//在同一个时刻加了锁的那部分程序只有一个线程可以进入
synchronized (LazyDoubleCheckSingleton.class){
if(singleton == null){
singleton = new LazyDoubleCheckSingleton();
//1、分配内存给这个对象
//2、初始化对象
//3、设置singleton指向刚分配的内存地址
//singleton利用volatile关键字防止指令重排序
}
}
}
return singleton;
}
}
Double-Check概念对于多线程开发者来说不会陌生,如代码中所示,我们进行了两次if (singleton == null)检查,并且对singleton变量使用volatile关键字防止指令重排序,这样就可以保证线程安全了。这样,实例化代码只用执行一次,后面再次访问时,判断if (singleton == null),直接return实例化对象。
使用双重检测同步延迟加载去创建单例的做法是一个非常优秀的做法,其不但保证了单例,而且切实提高了程序运行效率
优点:线程安全;延迟加载;效率较高。
4、静态内部类方式
public class StaticInnerClassSingleton {
private StaticInnerClassSingleton(){
}
private static class InnerClass {
private static StaticInnerClassSingleton singleton = new StaticInnerClassSingleton();
}
public static StaticInnerClassSingleton getInstance(){
return InnerClass.singleton;
}
}
静态内部类的优点是:外部类加载时并不需要立即加载内部类,内部类不被加载则不去初始化INSTANCE,故而不占内存。即当StaticInnerClassSingleton第一次被加载时,并不需要去加载InnerClass,只有当getInstance()方法第一次被调用时,才会去初始化singleton,第一次调用getInstance()方法会导致虚拟机加载InnerClass类,这种方法不仅能确保线程安全,也能保证单例的唯一性,同时也延迟了单例的实例化。
那么,静态内部类又是如何实现线程安全的呢?首先,我们先了解下类的加载时机。
类加载时机:JAVA虚拟机在有且仅有的5种场景下会对类进行初始化。
- 1、遇到new、getstatic、setstatic或者invokestatic这4个字节码指令时,对应的java代码场景为:new一个关键字或者一个实例化对象时、读取或设置一个静态字段时(final修饰、已在编译期把结果放入常量池的除外)、调用一个类的静态方法时。
- 2、使用java.lang.reflect包的方法对类进行反射调用的时候,如果类没进行初始化,需要先调用其初始化方法进行初始化。
- 3、当初始化一个类时,如果其父类还未进行初始化,会先触发其父类的初始化。
- 4、当虚拟机启动时,用户需要指定一个要执行的主类(包含main()方法的类),虚拟机会先初始化这个类。
- 5、当使用JDK 1.7等动态语言支持时,如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄,并且这个方法句柄所对应的类没有进行过初始化,则需要先触发其初始化。
这5种情况被称为是类的主动引用,注意,这里《虚拟机规范》中使用的限定词是"有且仅有",那么,除此之外的所有引用类都不会对类进行初始化,称为被动引用。静态内部类就属于被动引用的行列。
我们再回头看下getInstance()方法,调用的是InnerClass.singleton,取的是InnerClass里的singleton对象,跟上面那个Double-Check方法不同的是,getInstance()方法并没有多次去new对象,故不管多少个线程去调用getInstance()方法,取的都是同一个singleton对象,而不用去重新创建。当getInstance()方法被调用时,InnerClass才在StaticInnerClassSingleton的运行时常量池里,把符号引用替换为直接引用,这时静态对象singleton也真正被创建,然后再被getInstance()方法返回出去,这点同饿汉模式。那么singleton在创建过程中又是如何保证线程安全的呢?在《深入理解JAVA虚拟机》中,有这么一句话:
虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁、同步,如果多个线程同时去初始化一个类,那么只会有一个线程去执行这个类的<clinit>()方法,其他线程都需要阻塞等待,直到活动线程执行<clinit>()方法完毕。如果在一个类的<clinit>()方法中有耗时很长的操作,就可能造成多个进程阻塞(需要注意的是,其他线程虽然会被阻塞,但如果执行<clinit>()方法后,其他线程唤醒之后不会再次进入<clinit>()方法。同一个加载器下,一个类型只会初始化一次。),在实际应用中,这种阻塞往往是很隐蔽的。
故而,可以看出singleton在创建过程中是线程安全的,所以说静态内部类形式的单例可保证线程安全,也能保证单例的唯一性,同时也延迟了单例的实例化。
那么,是不是可以说静态内部类单例就是最完美的单例模式了呢?其实不然,静态内部类也有着一个致命的缺点,就是传参的问题,由于是静态内部类的形式去创建单例的,故外部无法传递参数进去,例如Context这种参数,所以,我们创建单例时,可以在静态内部类与Double-Check模式里自己斟酌。
5、枚举方式
使用枚举的方式实现单例模式是《Effective Java》作者力推的方式,在很多优秀的开源代码中经常可以看到使用枚举方式实现单例模式的(身影),枚举类型不允许被继承,同样是线程安全的且只能被实例化一次,但是枚举类型不能够懒加载,对EnumInstance主动使用,比如调用其中的静态方法则INSTANCE会立即得到实例化。
public enum EnumInstance {
INSTANCE{
protected void print(){
System.out.println("print test");
}
};
//通过声明抽象方法去调用INSTANCE里面的方法
protected abstract void print();
//实例变量
private Object data;
public Object getData() {
return data;
}
public void setData(Object data) {
this.data = data;
}
public static EnumInstance getInstance(){
return INSTANCE;
}
}
直接通过EnumInstance.INSTANCE.getData()或EnumInstance.getInstance().getData()的方式调用即可。方便、简洁又安全。
6、容器方式
public class ContainerSingleton {
private ContainerSingleton(){
}
private static Map<String,Object> singletonMap = new HashMap<String,Object>();
public static void putInstance(String key,Object instance){
if(StringUtils.isEmpty(key) && instance != null){
if(!singletonMap.containsKey(key)){
singletonMap.put(key,instance);
}
}
}
public static Object getInstance(String key){
return singletonMap.get(key);
}
}
HashMap本身就是线程不安全的,所以有一定的限制,即使换成ConcurrentHashMap,在反射等手段面前也不能保证绝对的单例,所以这种容器方式需要根据不同的场景去使用。
7、ThreadLocal方式,保证同一线程拿到的是同一个实例
public class ThreadLocalInstance {
private static final ThreadLocal<ThreadLocalInstance> threadLocal = new ThreadLocal<ThreadLocalInstance>(){
@Override
protected ThreadLocalInstance initialValue() {
return new ThreadLocalInstance();
}
};
private ThreadLocalInstance(){
}
public static ThreadLocalInstance getInstance(){
return threadLocal.get();
}
}
序列化破环单例模式
这里采用饿汉式说明
public class HungrySingleton implements Serializable {
private final static HungrySingleton singleton = new HungrySingleton();
private HungrySingleton(){
}
public static HungrySingleton getInstance(){
return singleton;
}
}
序列化和反序列化对单例模式进行破坏
public class Test {
public static void main(String[] args) throws IOException, ClassNotFoundException {
HungrySingleton instance = HungrySingleton.getInstance();
ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("SINGLETON_FILE"));
oos.writeObject(instance);
File file = new File("SINGLETON_FILE");
ObjectInputStream ois = new ObjectInputStream(new FileInputStream(file));
HungrySingleton newInstance = (HungrySingleton)ois.readObject();
System.out.println(instance);
System.out.println(newInstance);
System.out.println(instance == newInstance);
}
}
此段代码执行结果如下:
com.yibo.designpattern.singleton.HungrySingleton@14ae5a5
com.yibo.designpattern.singleton.HungrySingleton@6d03e736
false
由代码执行结果可看出,对单例模式执行完序列化和反序列化后,创建了新的对象,破坏了单例模式,违背了单例模式设计初衷。
如何保证序列化方式下也能实现单例?
解决方法很简单,只需要在单例类中增加readResolve()方法,代码如下:
public class HungrySingleton implements Serializable {
private final static HungrySingleton singleton = new HungrySingleton();
private HungrySingleton(){
}
public static HungrySingleton getInstance(){
return singleton;
}
private Object readResolve(){
return singleton;
}
}
再次执行Test测试方法,执行结果如下:
com.yibo.designpattern.singleton.HungrySingleton@14ae5a5
com.yibo.designpattern.singleton.HungrySingleton@14ae5a5
true
由此可见,增加readResolve()方法后解决了序列化方法对单例模式的破坏。
反射对单例模式进行破坏
这里依然采用上面的饿汉式
public class Test {
public static void main(String[] args) throws NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException {
//反射破坏单例模式
Class clazz = HungrySingleton.class;
Constructor constructor = clazz.getDeclaredConstructor();
constructor.setAccessible(true);
HungrySingleton newInstance = (HungrySingleton)constructor.newInstance();
HungrySingleton instance = HungrySingleton.getInstance();
System.out.println(instance);
System.out.println(newInstance);
System.out.println(instance == newInstance);
}
}
此段代码执行结果如下:
com.yibo.designpattern.singleton.HungrySingleton@1b6d3586
com.yibo.designpattern.singleton.HungrySingleton@4554617c
false
如何避免反射方式创建实例?
public class HungrySingleton implements Serializable {
private final static HungrySingleton singleton = new HungrySingleton();
private HungrySingleton(){
if(singleton != null){
throw new RuntimeException("单例构造函数禁止反射调用");
}
}
public static HungrySingleton getInstance(){
return singleton;
}
private Object readResolve(){
return singleton;
}
}
但是此种方式存在问题,如果反射线程先于单例初始化线程执行,则不能保证单例模式,所以推荐使用静态内部类方式和枚举方式