1. IT知识观首页

聊透常见设计模式之单例模式

云烟 • • 未分类 • 阅读 190

聊透常见设计模式之单例模式设计模式定义：设计模式（Design pattern）是可复用面向对象软件的基础，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的

欢迎大家来到IT世界,在知识的湖畔探索吧!

聊透常见设计模式之单例模式

设计模式定义：

设计模式（Design pattern）是可复用面向对象软件的基础，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。

设计模式分类

总体来说设计模式分为三大类

  1. 创建型模式（5种）
  2. 工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式
  3. 结构型模式（7种）
  4. 适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式
  5. 行为型模式（11种）
  6. 策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式

单例模式

定义

保证一个类仅有一个实例，并提供一个该实例的全局访问点。——《设计模式》

为什么需要？

系统内存中该类只存在一个对象，节省了系统资源，对于一些需要频繁创建销毁的对象，使用单例模式可以提高系统性能。

单例模式种类

1.懒汉式V1

public class Singleton {  

    private static Singleton instance;  

    private Singleton (){}  // 构造器私有

    public static Singleton getInstance() {  
        if (instance == null) {  // 1
            instance = new Singleton();  // 2
        }  
        return instance;  
    }  

}

欢迎大家来到IT世界,在知识的湖畔探索吧!

这种方式不可用 因为线程不安全
原因是在上面1处的代码如果在多线程下，一个线程进入了 if (singleton == null) 判断语句块，还未来得及往下执行，另一个线程也通过了这个判断语句，这时便会产生多个实例。所以在多线程环境下不可使用这种方式

2.懒汉式V2(线程安全)

欢迎大家来到IT世界,在知识的湖畔探索吧!public class Singleton {

    private static Singleton singleton;

    private Singleton() {}

    public static synchronized Singleton getInstance() {
        if (singleton == null) {
            singleton = new Singleton();
        }
        return singleton;
    }
}

这种方式线程安全，getInstance() 方法进行了线程同步，但是这种方式不推荐使用

缺点：

效率太低了，每个线程在想获得类的实例时候，执行 getInstance() 方法都要进行同步。而其实这个方法只执行一次实例化代码就够了，后面的想获得该类实例，直接 return 就行了。方法进行同步效率太低要改进。

3.双重校验锁

public class Singleton {

    private static volatile Singleton singleton; // 1

    private Singleton() {}  //私有构造函数

    //静态工厂方法
    public static Singleton getInstance() {
        if (singleton == null) { //双重检测机制
            synchronized (Singleton.class) { //同步锁
                if (singleton == null) { //双重检测机制
                    singleton = new Singleton();
                }
            }
        }
        return singleton;
    }
}

双重校验锁线程安全推荐使用。

疑问：

1.这种方式为什么要检查两次？检查一次行不行？

检查一次不行

第一次判断singleton == null作用是，如果单例对象已经创建，就直接返回对象，不需要进入同步锁，提高效率（我感觉这一次检查不是必须，但是推荐）

第二次判断singleton == null，假如没有这个判断，多个线程同时通过第一次singleton == null之后，只有一个线程进入临界区，其他线程排队，没有第二次检查的话，会创建多个实例，第二次是必须检查

2：在代码1处使用了关键字volatile，为什么需要？

因为 JVM 指令重排序，也就是并不限制处理器的指令顺序，说白了就是在不影响结果的情况下，顺序可能会被打乱。

在执行sInstance = new Singleton();这条命令语句时，JMM并不是一下就执行完毕的，即不是原子性，实质上这句命令分为三大部分：

为对象分配内存执行构造方法语句，初始化实例对象把sInstance的引用指向分配的内存空间

在JMM中这三个步骤中的2和3不一定是顺序执行的，如果线程A执行的顺序为1、3、2，在第2步执行完毕的时候，恰好线程B执行第一次判空语句，则会直接返回sInstance，那么此时获取到的sInstance仅仅只是不为null，实质上没有初始化，这样的对象肯定是有问题的！

而volatile关键字的存在意义就是保证了执行命令不会被重排序，也就避免了这种异常情况的发生，所以这种获取单例的方法才是真正的安全可靠！

4.饿汉式

欢迎大家来到IT世界,在知识的湖畔探索吧!public class Singleton {  

    private static Singleton instance = new Singleton();  

    private Singleton (){}  

    public static Singleton getInstance() {  
        return instance;  
    }  

}

5.饿汉式其他变种1 静态常量

public class Singleton {  

    private static final Singleton INSTANCE = new Singleton();  

    private Singleton (){}  

    public static Singleton getInstance() {  
        return INSTANCE;  
    }  

}

6.饿汉式其他变种2 静态代码块

public class Singleton {  

    private static Singleton instance;

    static {
       instance = new Singleton();  
    }

    private Singleton (){}  

    public static Singleton getInstance() {  
        return instance;  
    }  
}

上面几种本质一样

优点：无线程安全问题

缺点：不能延迟加载，如果这个对象没有使用到，浪费内存

7.静态内部类

public class Singleton {

    private Singleton() {}

    private static class SingletonInstance {
        private static final Singleton INSTANCE = new Singleton();
    }

    public static Singleton getInstance() {
        return SingletonInstance.INSTANCE;
    }
}

这种方式 避免了线程不安全，延迟加载，效率高

8.枚举

public enum EnumSingleton {
    INSTANCE;
    private Object object;
    EnumSingleton() {
        object = new Object();
    }
    public Object getInstance() {
        return object;
    }
}

优点：线程安全，能防止序列化破坏（后面说）

思考：饿汉式/静态内部类/枚举是通用什么方式保证线程安全？

以上的静态内部类、饿汉等模式均是通过定义静态的成员变量，以保证单例对象可以在类初始化的过程中被实例化。

这其实是利用了ClassLoader的线程安全机制。ClassLoader的loadClass方法在加载类的时候使用了synchronized关键字。

所以， 除非被重写，这个方法默认在整个装载过程中都是线程安全的。所以在类加载过程中对象的创建也是线程安全的。

扩展讨论：

那么这些方式都是和synchronized有关系的，有没有哪种方式可以完全不使用synchronized的吗？

9.CAS（AtomicReference）实现单例模式


public class Singleton {
    private static final AtomicReference<Singleton> INSTANCE = new AtomicReference<Singleton>();

    private Singleton() {}

    public static Singleton getInstance() {
        for (;;) {
            Singleton singleton = INSTANCE.get();
            if (null != singleton) {
                return singleton;
            }

            singleton = new Singleton();
            if (INSTANCE.compareAndSet(null, singleton)) {
                return singleton;
            }
        }
    }
}

优点：

用CAS的好处在于不需要使用传统的锁机制来保证线程安全，CAS是一种基于忙等待的算法，依赖底层硬件的实现，相对于锁它没有线程切换和阻塞的额外消耗，可以支持较大的并行度。（CAS具体可以在JUC那块分享）

缺点：

CAS的一个重要缺点在于如果忙等待一直执行不成功(一直在死循环中)，会对CPU造成较大的执行开销。

另外，代码中，如果N个线程同时执行到 singleton = new Singleton();的时候，会有大量对象被创建，可能导致内存溢出。

10.ThreadLocal实现单例模式

public class Singleton {
     private static final ThreadLocal<Singleton> singleton =
     new ThreadLocal<Singleton>() {
         @Override
         protected Singleton initialValue() {
            return new Singleton();
         }
     };
     public static Singleton getInstance() {
        return singleton.get();
     }

     private Singleton() {}
}

这种方式仅了解，不推荐使用，因为它其实失去了单例的意义

ThreadLocal 和 同步模式创建的单例区别：

ThreadLocal会为每一个线程提供一个独立的变量副本，从而隔离了多个线程对数据的访问冲突。对于多线程资源共享的问题，同步机制(synchronized)采用了“以时间换空间”的方式，而ThreadLocal采用了“以空间换时间”的方式。这种是

同步机制仅提供一份变量，让不同的线程排队访问，而ThreadLocal为每一个线程都提供了一份变量，因此可以同时访问而互不影响。

聊透常见设计模式之单例模式

破坏单例模式的方式和解决办法

1.反射破坏单例

可以通过setAccessible(true)来绕过 private 限制，从而调用到类的私有构造函数创建对象。

   Singleton1 singleton1 = Singleton1.getInstance();
    Constructor<Singleton1> cons = Singleton1.class.getDeclaredConstructor();
    cons.setAccessible(true);
    Singleton1 singleton2 =  cons.newInstance(); // 注意 需要通过 Constructor newInstance
    System.out.println(singleton1);
    System.out.println(singleton2);

结果

com.pandacase.single.Singleton1@71bc1ae4
com.pandacase.single.Singleton1@6ed3ef1

解决办法？
思路：解决的办法可以是在私有构造器中，判断是否已经存在单例对象了，如果存在，则抛出异常
例如：

public class Singleton {

    private static int count = 0;
    private static volatile Singleton singleton; // 1

    //私有构造函数
    private Singleton() {
         synchronized (Singleton.class) {
            if (count > 0){
                throw new RuntimeException("反射破坏单例对象.....");
            }
            count++;
        }
    } 

    //静态工厂方法
    public static Singleton getInstance() {
        if (singleton == null) { //双重检测机制
            synchronized (Singleton.class) { //同步锁
                if (singleton == null) { //双重检测机制
                    singleton = new Singleton();
                }
            }
        }
        return singleton;
    }
}

2.序列化破坏单例（前提是单例类实现了Serializable接口）

一是可以将一个单例的实例对象写到磁盘，实现数据的持久化；二是实现对象数据的远程传输。 当单例对象有必要实现 Serializable 接口时，即使将其构造函数设为私有，在它反序列化时依然会通过特殊的途径再创建类的一个新的实例，相当于调用了该类的构造函数有效地获得了一个新实例！

解决办法？

 /* 如果该对象被用于序列化，可以保证对象在序列化前后保持一致 */  
 public Object readResolve() {  
        return instance;  
}

3.对象克隆破坏单例

clone()是 Object 的方法，每一个对象都是 Object 的子类，都有clone()方法。clone()方法并不是调用构造函数来创建对象，而是直接拷贝内存区域。因此当我们的单例对象实现了 Cloneable 接口时，尽管其构造函数是私有的，仍可以通过克隆来创建一个新对象，单例模式也相应失效了。

解决办法？

解决思想是，重写clone()方法，调clone()时直接返回已经实例的对象

public class Singleton implements Cloneable{

    private static int count = 0;
    private static volatile Singleton singleton; // 1

    //私有构造函数
    private Singleton() {
         synchronized (Singleton.class) {
            if (count > 0){
                throw new RuntimeException("反射破坏单例对象.....");
            }
            count++;
        }
    } 

    //静态工厂方法
    public static Singleton getInstance() {
        if (singleton == null) { //双重检测机制
            synchronized (Singleton.class) { //同步锁
                if (singleton == null) { //双重检测机制
                    singleton = new Singleton();
                }
            }
        }
        return singleton;
    }

  // 重写 clone 方法
  @Override
  protected Object clone() throws CloneNotSupportedException {
    return singleton;
  }
}

单例模式在JDK中的应用

java.lang.Runtime#getRuntime()

应用场景

  1. 需要频繁的进行创建和销毁的对象；
  2. 创建对象时耗时过多或耗费资源过多，但又经常用到的对象；
  3. 工具类对象；
  4. 频繁访问数据库或文件的对象。

免责声明：本站所有文章内容,图片，视频等均是来源于用户投稿和互联网及文摘转载整编而成，不代表本站观点，不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益，请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权，请联系删除，如若转载，请注明出处：https://itzsg.com/32839.html

赞 (0)
云烟云烟
0

相关推荐

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

联系我们YX

mu99908888

在线咨询： 微信交谈

邮件：itzsgw@126.com

工作时间：时刻准备着!

关注微信