单例模式较为简答，就不上场景了，直接上代码：
构造器私有，只有内部New的实例公开
延迟创建实例可能在多线程并行的时候出现问题，可以使用同步，加锁，或者一开始就New
让我们来看看六大原则：
单一职责原则（Single Responsibility Principle）：只有一个实例存在，并提供一个全局访问点，符合单一职责
开放封闭原则（Open-Closed Principle）：单例模式在实现上是封闭的，因为它只允许创建一个实例。但是，如果需要修改单例类的行为或扩展其功能，可能需要修改该类的代码，违反了开放封闭原则。
里氏替换原则（Liskov Substitution Principle）：一般没有什么继承关系
接口隔离原则（Interface Segregation Principle）：一般也没有接口
依赖倒置原则（Dependency Inversion Principle）：本来就是个具体的类
迪米特法则（LoD）：全世界都在用，严重违反
六大原则基本违反了个遍，但是还是有些地方还是单例模式好：
资源共享 全局状态控制 日志记录 线程池
这时候就有人不禁要问了，那我为什么不用静态类代替单例呢？
使用静态类代替单例模式有以下优势：
简化代码：静态类不需要显式地创建实例，也不需要实现单例模式的复杂逻辑，因此可以简化代码。你可以直接通过静态类的成员访问相关功能，而不需要先获取单例实例。
避免线程安全问题：静态类的成员在应用程序启动时被初始化，且无法被修改。因此，不需要考虑多线程环境下的线程安全问题，避免了在单例模式中需要进行线程同步的复杂性。
更好的性能：由于静态类的成员在应用程序启动时就被初始化，因此在使用时无需再进行实例化操作，这可以提高性能。而在单例模式中，首次获取单例实例时需要进行实例化操作，可能会引入一定的性能开销。
需要注意的是，使用静态类代替单例模式也有一些限制：
无法实现延迟加载：静态类的成员在应用程序启动时就被初始化，无法实现按需延迟加载的效果。而在某些情况下，延迟加载是单例模式的一个重要特性。
无法替换实现：静态类的成员是静态的，无法被继承或替换。而在单例模式中，可以通过继承和接口实现来替换单例实例的具体实现。
因此，当你需要一个全局唯一的实例，并且不需要延迟加载或替换实现时，使用静态类可以是一个更简洁和高效的选择。但在其他情况下，单例模式可能更为适合。
最后，没有什么设计模式是最好的，只有最好的使用方法