前言
提示：设计者模式有利于提高开发者的编程效率和代码质量：
GoF（Gang of Four，四人帮）设计模式由Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides四位作者合著，介绍了23种经典的设计模式。
分为三大类：创建型模式、结构型模式和行为型模式。
提示：以下是本篇文章正文内容，下面案例可供参考
一、什么是单例模式？
单例模式是一种创建型设计模式，它保证一个类只有一个实例，并提供一个全局访问点来获取这个实例。这通常用于需要集中控制或管理资源的场景，例如数据库连接、线程池、配置文件读取等。
二、为什么要用单例模式？
使用单例模式的原因包括但不限于以下几点：
- 资源控制：确保系统中某个资源仅有一个实例，避免资源浪费或冲突。
- 全局访问：提供一个全局访问点，使得系统中的任何部分都可以方便地访问该实例。
- 节省内存：因为只有一个实例存在，所以可以节省系统资源，特别是当对象占用大量内存时。
- 状态共享：对于需要在多个地方共享状态的情况，单例模式可以确保状态的一致性。
- 初始化成本高：如果对象的创建过程非常复杂或者耗时，那么使用单例模式可以在第一次使用时才进行创建，从而延迟初始化，提高性能。
三、如何实现单例模式？
单例模式的实现有多种方式，下面是一些常见的实现方法：
1、懒汉式（Lazy Initialization）
懒汉式是在第一次调用 getInstance 方法时才创建实例，这样可以实现延迟加载，节省资源。
public class Singleton {
private static Singleton instance;
private Singleton() {} // 私有构造函数防止外部实例化
public static synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
优点：实现了真正的懒加载，即只有在真正需要的时候才会创建实例。
缺点：每次调用 getInstance 方法都需要进行同步，这可能会带来性能问题。
2、饿汉式（Eager Initialization）
饿汉式是在类加载时就创建实例，因此不需要同步，性能较好。
public class Singleton {
private static final Singleton instance = new Singleton();
private Singleton() {} // 私有构造函数防止外部实例化
public static Singleton getInstance() {
return instance;
}
}
优点：没有线程安全问题，也不需要同步，性能较高。
缺点：无论是否使用，都会创建实例，无法实现懒加载。
3、双重检查锁定（Double-Checked Locking）
双重检查锁定是一种优化过的懒汉式实现，减少了不必要的同步操作，提高了性能。
public class Singleton {
private static volatile Singleton instance;
private Singleton() {} // 私有构造函数防止外部实例化
public static Singleton getInstance() {
if (instance == null) { // 第一次检查
synchronized (Singleton.class) {
if (instance == null) { // 第二次检查
instance = new Singleton();
}
}
}
return instance;
}
}
优点：既实现了懒加载，又避免了每次调用 getInstance 时都进行同步，性能较高。
缺点：实现稍微复杂一些，而且需要理解Java内存模型和volatile关键字的作用。
4、静态内部类（Static Inner Class）
静态内部类是另一种实现懒加载的方式，利用了类加载机制确保线程安全。（常用）
public class Singleton {
private Singleton() {} // 私有构造函数防止外部实例化
private static class SingletonHolder {
private static final Singleton INSTANCE = new Singleton();
}
public static Singleton getInstance() {
return SingletonHolder.INSTANCE;
}
}
优点：线程安全，且实现了懒加载，性能良好，代码简洁。
缺点：与其它方式相比，可能不是最直观的理解方式。
总结
选择哪种实现方式取决于具体的应用场景和需求，后期会新增关于单例模式的具体应用场景。