在软件开发中,有些对象我们只需要一个实例,通过单例模式可以确保一个类只有一个实例,并提供了全局访问点以便其他对象可以使用该实例。本文将介绍单例模式的使用场景、实现方式和总结。
单例模式属于创建型设计模式,它限制一个类只能创建一个实例。这个实例可以通过全局访问点来获取,从而确保所有代码都共享同一个实例。
Spring 框架应用中的 ApplicationContext 就是单例模式中的饿汉式。
单例模式在很多场景下都有应用,比如线程池、数据库连接池、配置对象等。通过使用单例模式,可以降低系统中对象的数量,减少资源开销,并且方便管理和控制这些共享的实例。
优点
- 由于单例模式在内存中只有一个实例,减少了内存开支,特别是一个对象需要频繁地创建、销毁时,而且创建或销毁时性能又无法优化,单例模式的优势就非常明显。
- 由于单例模式只生成一个实例,所以减少了系统的性能开销,当一个对象的产生需要比较多的资源时,如读取配置、产生其他依赖对象时,则可以通过在应用启动时直接产生一个单例对象,然后用永久驻留内存的方式来解决(在Java EE中采用单例模式时需要注意JVM 垃圾回收机制)。
- 单例模式可以避免对资源的多重占用,例如一个写文件动作,由于只有一个实例存在内存中,避免对同一个资源文件的同时写操作。
- 单例模式可以在系统设置全局的访问点,优化和共享资源访问,例如可以设计一个单例类,负责所有数据表的映射处理。
缺点
- 单例模式一般没有接口,扩展很困难,若要扩展,除了修改代码基本上没有第二种途 径可以实现。单例模式为什么不能增加接口呢?因为接口对单例模式是没有任何意义的,它要求“自行实例化”,并且提供单一实例、接口或抽象类是不可能被实例化的。当然,在特殊情况下,单例模式可以实现接口、被继承等,需要在系统开发中根据环境判断。
- 单例模式对测试是不利的,在并行开发环境中,如果单例模式没有完成,是不能进行测试的,没有接口也不能使用mock的方式虚拟一个对象。
- 单例模式与单一职责原则有冲突。一个类应该只实现一个逻辑,而不关心它是否是单例的,是不是要单例取决于环境,单例模式把“要单例”和业务逻辑融合在一个类中。
使用场景
为什么要用单例模式?
- 单例模式节省公共资源
比如:大家都要喝水,但是没必要每人家里都打一口井是吧,通常的做法是整个村里打一个井就够了,大家都从这个井里面打水喝。
对应到我们计算机里面,像日志管理、打印机、数据库连接池、应用配置。
- 单例模式方便控制
就像日志管理,如果多个人同时来写日志,你一笔我一笔那整个日志文件都乱七八糟,如果想要控制日志的正确性,那么必须要对关键的代码进行上锁,只能一个一个按照顺序来写,而单例模式只有一个人来向日志里写入信息方便控制,避免了这种多人干扰的问题出现。
单例模式适用于以下场景:
- 当一个类只需要一个实例时。
- 当多个对象需要共享同一个实例时。
- 当创建实例需要耗费大量资源时。
单例模式的应用场景之一:日志记录器。
public class Logger {
private static Logger instance;
private Logger() {
// 私有构造方法,防止外部实例化
}
public static synchronized Logger getInstance() {
if (instance == null) {
instance = new Logger();
}
return instance;
}
public void log(String message) {
System.out.println("Log: " + message);
}
}
在上述示例中,Logger 类只能创建一个实例。通过 getInstance() 静态方法,我们可以获取该实例,并且在需要记录日志的地方调用 log 方法进行日志记录。
序列化对单例模式的破坏
序列化可能会破坏某些单例模式实现方式,特别是那些使用懒加载或延迟初始化的方式。在进行反序列化时,会创建一个新的对象实例,从而破坏了原本的单例特性。
以下是一个简单的示例代码,演示了序列化对懒汉式单例模式的影响:
public class Singleton implements Serializable {
private static Singleton instance;
private Singleton() {
// 私有构造方法
}
public static Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
public static void main(String[] args) {
Singleton singleton1 = Singleton.getInstance();
try {
// 将singleton1对象序列化到文件中
ObjectOutputStream outputStream = new ObjectOutputStream(new FileOutputStream("singleton.ser"));
outputStream.writeObject(singleton1);
outputStream.close();
// 从文件中反序列化出一个新对象
ObjectInputStream inputStream = new ObjectInputStream(new FileInputStream("singleton.ser"));
Singleton singleton2 = (Singleton) inputStream.readObject();
inputStream.close();
// 比较两个对象是否相同
System.out.println("singleton1: " + singleton1.hashCode());
System.out.println("singleton2: " + singleton2.hashCode());
} catch (Exception e) {
e.printStackTrace();
}
}
}
输出:
singleton1: 868693306
singleton2: 625576447
运行以上代码,输出结果会显示 singleton1 和 singleton2 的哈希码不同,说明反序列化过程创建了一个新的对象实例,破坏了单例模式。
要解决这个问题,可以使用枚举方式实现单例模式,或者可以在类中添加一个 readResolve() 方法,并返回单例实例。这样在反序列化时会调用该方法,从而确保只返回单例对象:
private Object readResolve() throws ObjectStreamException {
return instance;
}
在上述示例的 Singleton 类中添加 readResolve() 方法后,再运行代码,输出结果将会显示 singleton1 和 singleton2 的哈希码相同,保证了单例模式的正确性。readResolve() 方法能够让我们控制反序列化时返回的对象,从而避免破坏单例特性。
实现方式
单例模式的实现有多种方式,如下所示:
饿汉式
public class EagerSingleton {
//确保对象实例只有一个
private static final EagerSingleton instance = new EagerSingleton();
// 私有构造方法,防止外部实例化
private EagerSingleton() {
}
//以静态方法返回实例
public static EagerSingleton getInstance() {
return instance;
}
}
优点:
- 线程安全:由于在类加载时就创建了实例,所以不会出现多线程并发访问时创建多个实例的问题。
- 简单直观:饿汉模式的实现相对简单,代码易于理解和维护。
- 性能高:由于实例在类加载时就创建了,因此获取实例的速度较快。
缺点:
- 不能懒加载:由于实例在类加载时就创建了,即使在某些情况下并不需要使用该实例,也会占用一定的资源。
饿汉模式适用于在程序运行期间始终需要使用的实例,并且对性能要求较高的场景。但是需要注意内存浪费的问题。
懒汉式
public class LazySingleton {
private static LazySingleton instance;
// 私有构造方法,防止外部实例化
private LazySingleton() {
}
public static LazySingleton getInstance() {
if (instance == null) {
instance = new LazySingleton();
}
return instance;
}
}
在懒汉式中,实例在第一次被使用时才会被创建。但是当多个线程同时调用 getInstance() 方法时,可能会导致创建多个实例。存在线程安全问题。
优点:
- 延迟加载:懒汉模式在第一次使用时才会创建实例,可以避免不必要的资源消耗。
缺点:
- 线程安全性需要额外考虑:在最简单的懒汉模式实现中,当多个线程同时调用 getInstance() 方法时,可能会创建多个实例。为了解决这个问题,可以使用同步关键字或者其他线程安全的方式进行控制,但这可能会影响性能。
- 性能开销:由于懒汉模式需要在获取实例时进行判断和创建,会带来一定的性能开销,特别是在高并发的情况下。
总体来说,懒汉模式适用于在程序运行期间可能不会立即使用到实例的情况,可以实现延迟加载。但是需要注意线程安全性和性能开销的问题,在多线程环境下要特别小心处理。
如果要保证懒汉模式的线程安全性,则需要加锁解决线程同步问题。
双重校验锁
public class LazySingleton{
/**
* volatile 关键字可以保证线程间变量的可见性,还有一个作用就是阻止局部重排序的发生
*/
private volatile static LazySingleton INSTANCE = null;
private LazySingleton(){}
public static LazySingleton getInstance(){
if(INSTANCE == null)
{
synchronized(LazySingleton.class){
if(INSTANCE == null){
INSTANCE = new LazySingleton();
}
}
return INSTANCE;
}
}
}
双层校验锁的懒汉模式可以确保在多线程环境下仅创建一个实例,并保证线程安全性。具体解释如下:
- 首先,如果实例已经被创建,则直接返回该实例,避免了不必要的同步开销。
- 当第一个线程到达getInstance()方法时,会检查实例是否为空。由于在多线程环境下可能有多个线程同时通过这一判断,因此需要在 synchronized 关键字内再次进行空检查。
- 在进入 synchronized 块之前,使用双重检查来确保只有第一个线程能够创建实例。即使有其他线程在第一个线程进入 synchronized 块之后抢占CPU资源,它们也会发现实例已经被创建,从而避免重复创建实例。
- 使用volatile关键字修饰 INSTANCE 变量,可以确保变量的可见性,在多线程环境下,一个线程修改了 INSTANCE 的值,其他线程能够立即看到最新的值,避免了指令重排序带来的问题。
静态内部类
基于静态内部类实现线程安全,性能比双重检查锁要好。
public class Singleton {
private static class LazyHolder {
private static final Singleton INSTANCE = new Singleton();
}
private Singleton (){
/*为了避免反射破坏单例,需要在构造方法中增加限制,一旦出现多次重复创建,直接抛出异常*/
if (null != LazyHolder.INSTANCE) {
throw new RuntimeException("创建Singleton异常,不允许创建多个实例!");
}
}
/**
* 调用静态方法的时候会先加载Singleton类,静态内部类只有在使用的时候才会被加载。
* 而ClassLoader加载的时候是单个线程的。所以既能够实现需要的时候才被加载,也能够实现线程安全。
*/
public static final Singleton getInstance() {
return LazyHolder.INSTANCE;
}
}
这种方式利用了类加载机制来保证只创建一个instance实例,从而保证线程安全性。具体解释如下:
- 静态内部类 LazyHolder 只有在 getInstance() 方法被调用时才会被加载,从而实现了延迟加载的效果。
- 类加载是由 ClassLoader 负责的,ClassLoader 在加载类的过程中是单线程进行的,因此在加载 LazyHolder 类时是线程安全的。
- LazyHolder 类中的 INSTANCE 是final修饰的,保证了实例的唯一性和不可更改性。
- 在 Singleton 的构造方法中,通过判断 LazyHolder.INSTANCE 是否为 null 来防止通过反射手段创建多个实例。如果尝试重复创建实例,将抛出异常。
枚举式
枚举方式理论上是实现单例模式的最佳方式,这种方式也是《Effective Java》的作者 Josh Bloch 提倡的方式。
public enum Singleton {
INSTANCE;
// 其他成员方法和属性
public void doSomething() {
// 实现具体的功能
}
}
枚举方式实现的单例模式能够保证线程安全,原因如下:
- 枚举类型在Java中是线程安全的,线程安全性由JVM本身来保证,它的实例在类加载过程中被初始化,并且只会被初始化一次。这意味着在多线程环境下,不会出现多个线程创建多个实例的情况。
- 枚举实例是在类加载时被创建的,而且是静态常量,因此在整个应用程序生命周期内,只会存在一个实例。无论何时访问枚举实例,都会返回同一个对象。
相比前面的实现方式,枚举方式有两大优点:
- 防止反射攻击和序列化破坏:枚举本身就具有防止反射攻击和序列化破坏的特性。枚举实例的创建由JVM自动管理,不可通过反射调用私有构造函数创建新的实例,同时枚举类型默认实现了Serializable接口,因此也能够防止序列化破坏单例。
- 简洁明了:使用枚举方式实现单例模式非常简洁清晰,代码量少,易于理解和维护。
总结
选择单例模式的实现方式取决于具体的需求和场景。下面是对不同实现方式的一些建议:
- 饿汉式:如果单例对象在程序运行期间始终需要存在,并且占用资源较小,则可以考虑使用饿汉式。它能够保证在任何时候都能获得单例对象,但可能会提前加载实例造成资源浪费。
- 懒汉式:如果单例对象在程序中的使用并不频繁,或者占用资源较大,希望在需要时才进行初始化,可以选择懒汉式。懒汉式能够延迟加载实例,节省资源,但需要考虑线程安全性。
- 双重校验锁(Double-Checked Locking):这种方式结合了懒汉式和饿汉式的优点,即实现了延迟加载和线程安全。适用于资源消耗较大、需要延迟加载的情况。
- 静态内部类:静态内部类方式实现的单例模式具有延迟加载和线程安全的特点,同时也解决了双重校验锁的问题。适用于资源消耗较小、只在需要时才进行初始化的情况。
- 枚举方式:枚举方式是最简洁且安全可靠的单例实现方式,适用于任何情况。它具有线程安全性、实例唯一性和防止反射攻击、序列化破坏等优点。
总而言之,单例模式作为一种常见的设计模式,在软件开发中有着广泛的应用。选择适合的实现方式,并根据具体需求进行灵活运用,将有助于提升系统的性能和可维护性。
选择合适的单例模式实现方式需要综合考虑需求、资源消耗、线程安全性以及代码简洁性等因素。无论选择哪种方式,保证线程安全是非常重要的,同时也需要注意防止反射攻击和序列化破坏。