单例模式he统一异常处理

设计模式—单例模式

在软件开发中，有些对象我们只需要一个实例，通过单例模式可以确保一个类只有一个实例，并提供了全局访问点以便其他对象可以使用该实例。本文将介绍单例模式的使用场景、实现方式和总结。

单例模式属于创建型设计模式，它限制一个类只能创建一个实例。这个实例可以通过全局访问点来获取，从而确保所有代码都共享同一个实例。

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 来防止通过反射手段创建多个实例。如果尝试重复创建实例，将抛出异常。