概述
单例模式：单例对象能保证在一个JVM中，该对象只有一个实例存在。保证被创建一次，节省系统开销
解决的问题：保证一个类在内存中的对象唯一性
所谓单例，指的就是单实例，有且仅有一个类实例，这个单例不应该由人来控制，而应该由代码来限制，强制单例。
单例有其独有的使用场景，一般是对于那些业务逻辑上限定不能多例只能单例的情况，例如：类似于计数器之类的存在，
一般都需要使用一个实例来进行记录，若多例计数则会不准确。
其实单例就是那些很明显的使用场合，没有之前学习的那些模式所使用的复杂场景，只要你需要使用单例，那你就使用单例，简单易理解。
所以我认为有关单例模式的重点不在于场景，而在于如何使用。
懒汉式
何为懒？顾名思义，就是不做事，这里也是同义，懒汉式就是不在系统加载时就创建类的单例，而是在第一次使用实例的时候再创建。
详见下方代码示例：
public class LHanDanli {
//定义一个私有类变量来存放单例，私有的目的是指外部无法直接获取这个变量，而要使用提供的公共方法来获取
private static LHanDanli dl = null;
//定义私有构造器，表示只在类内部使用，亦指单例的实例只能在单例类内部创建
private LHanDanli(){}
//定义一个公共的公开的方法来返回该类的实例，由于是懒汉式，需要在第一次使用时生成实例，所以为了线程安全，使用synchronized关键字来确保只会生成单例
public static synchronized LHanDanli getInstance(){
if(dl == null){
dl = new LHanDanli();
}
return dl;
}
}
饿汉式
又何为饿？饿者，饥不择食；但凡有食，必急食之。此处同义：在加载类的时候就会创建类的单例，并保存在类中。
详见下方代码示例：
public class EHanDanli {
//此处定义类变量实例并直接实例化，在类加载的时候就完成了实例化并保存在类中
private static EHanDanli dl = new EHanDanli();
//定义无参构造器，用于单例实例
private EHanDanli(){}
//定义公开方法，返回已创建的单例
public static EHanDanli getInstance(){
return dl;
}
}
双重加锁机制
在懒汉式实现单例模式的代码中，有使用synchronized关键字来同步获取实例，保证单例的唯一性，但是上面的代码在每一次执行时都要进行同步和判断，
DCL是一种单例模式写法的简称，全称是Double Check Lock，翻译过来叫双重检查锁。从命名上来理解，
就是两次检查加一把锁。那么，两次检查又是检查什么，锁又是锁的什么？
从代码中，我们发现两次检查的判断条件都是 null == instance，而且两个检查条件是嵌套的。在第1次检查条
件的代码块中，加了一段synchronized代码块，synchronized就是锁。
相当于，不管单例对象是否已经创建，每次调用都可能阻塞，会影响程序的执行效率。所以，加上第1次检查的
目的是，保证只有第一次出现并发的情况会阻塞，提高性能。
因此，第2次检查的目的是，保证单例，避免重复创建单例对象。
第1次检查是为了保证只有首次并发的情况下才阻塞，提高性能，
第2次检查是为了保证，避免重复创建对象。加锁，当然就是为了保证线程安全。
在今天的分享，我还有一个细节没有讲到，就是在并发情况下，new一个对象可能会出现指令重排的现象。这时
候，我们需要给声明的单例对象加上volatile关键字，保证可见性。
无疑会拖慢速度，使用双重加锁机制正好可以解决这个问题：
public class SLHanDanli {
private static volatile SLHanDanli dl = null;
private SLHanDanli(){}
public static SLHanDanli getInstance(){
if(dl == null){
synchronized (SLHanDanli.class) {
if(dl == null){
dl = new SLHanDanli();
}
}
}
return dl;
}
}
看了上面的代码，有没有感觉很无语，双重加锁难道不是需要两个synchronized进行加锁的吗？
…
其实不然，这里的双重指的的双重判断，而加锁单指那个synchronized，为什么要进行双重判断，其实很简单，第一重判断，如果单例已经存在，
那么就不再需要进行同步操作，而是直接返回这个实例，如果没有创建，才会进入同步块，同步块的目的与之前相同，目的是为了防止有两个调用同时进行时，
导致生成多个实例，有了同步块，每次只能有一个线程调用能访问同步块内容，当第一个抢到锁的调用获取了实例之后，这个实例就会被创建，之后的所有调用
都不会进入同步块，直接在第一重判断就返回了单例。至于第二个判断，个人感觉有点查遗补漏的意味在内（期待高人高见）。
补充：关于锁内部的第二重空判断的作用，当多个线程一起到达锁位置时，进行锁竞争，其中一个线程获取锁，如果是第一次进入则dl为null，会进行单例对象的创建，完成后释放锁，其他线程获取锁后就会被空判断拦截，直接返回已创建的单例对象。
不论如何，使用了双重加锁机制后，程序的执行速度有了显著提升，不必每次都同步加锁。
其实我最在意的是volatile的使用，volatile关键字的含义是：被其所修饰的变量的值不会被本地线程缓存，所有对该变量的读写都是直接操作共享内存来实现，
从而确保多个线程能正确的处理该变量。该关键字可能会屏蔽掉虚拟机中的一些代码优化，所以其运行效率可能不是很高，所以，一般情况下，并不建议使用双重
加锁机制，酌情使用才是正理！
更进一步说，其实使用volatile的目的是为了防止暴露一个未初始化的不完整单例实例，导致系统崩溃。因为创建单例实例其实需要经过以下几步：
首先分配内存空间、然后将内存空间的首地址指向引用（指针），最后调用构造器创建实例，由于在第二步的时候这个引用（指针）就会变的非null，
那么在第三步未执行，真正的单例实例还未创建完成的时候，一个线程过来在第一个校验中为false，将会直接将不完整的实例返回，从而造成系统崩溃。
类级内部类方式
饿汉式会占用较多的空间，因为其在类加载时就会完成实例化，而懒汉式又存在执行速率慢的情况，双重加锁机制呢？又有执行效率差的毛病，
有没有一种完美的方式可以规避这些毛病呢？
貌似有的，就是使用类级内部类结合多线程默认同步锁，同时实现延迟加载和线程安全。
public class ClassInnerClassDanli {
public static class DanliHolder{
private static ClassInnerClassDanli dl = new ClassInnerClassDanli();
}
private ClassInnerClassDanli(){}
public static ClassInnerClassDanli getInstance(){
return DanliHolder.dl;
}
}
如上代码，所谓类级内部类，就是静态内部类，这种内部类与其外部类之间并没有从属关系，加载外部类的时候，并不会同时加载其静态内部类，
只有在发生调用的时候才会进行加载，加载的时候就会创建单例实例并返回，有效实现了懒加载（延迟加载），至于同步问题，我们采用和饿汉式
同样的静态初始化器的方式，借助JVM来实现线程安全。
其实使用静态初始化器的方式会在类加载时创建类的实例，但是我们将实例的创建显式放置在静态内部类中，它会导致在外部类加载时不进行实例创建，
这样就能实现我们的双重目的：延迟加载和线程安全。
单例模式适用场景
好多没怎么使用过的人可能会想，单例模式感觉不怎么用到，实际的应用场景有哪些呢？以下，我将列出一些就在咱们周边和很有意义的单例应用场景。
Windows的Task Manager（任务管理器）就是很典型的单例模式（这个很熟悉吧），想想看，是不是呢，你能打开两个windows task manager吗？ 不信你自己试试看哦~
windows的Recycle Bin（回收站）也是典型的单例应用。在整个系统运行过程中，回收站一直维护着仅有的一个实例。
网站的计数器，一般也是采用单例模式实现，否则难以同步。
应用程序的日志应用，一般都何用单例模式实现，这一般是由于共享的日志文件一直处于打开状态，因为只能有一个实例去操作，否则内容不好追加。
Web应用的配置对象的读取，一般也应用单例模式，这个是由于配置文件是共享的资源。
数据库连接池的设计一般也是采用单例模式，因为数据库连接是一种数据库资源。数据库软件系统中使用数据库连接池，主要是节省打开或者关闭数据库
连接所引起的效率损耗，这种效率上的损耗还是非常昂贵的，因为何用单例模式来维护，就可以大大降低这种损耗。多线程的线程池的设计一般也是采用单例模式，这是由于线程池要方便对池中的线程进行控制。
操作系统的文件系统，也是大的单例模式实现的具体例子，一个操作系统只能有一个文件系统。
HttpApplication 也是单位例的典型应用。熟悉ASP.Net(IIS)的整个请求生命周期的人应该知道HttpApplication也是单例模式，所有的HttpModule都共享
一个HttpApplication实例.1.需要生成唯一序列的环境
2.需要频繁实例化然后销毁的对象。
3.创建对象时耗时过多或者耗资源过多，但又经常用到的对象。
4.方便资源相互通信的环境
优点：1.实现了对唯一实例访问的可控
2.对于一些需要频繁创建和销毁的对象来说可以提高系统的性能。
缺点：1. 不适用于变化频繁的对象
2.滥用单例将带来一些负面问题，如为了节省资源将数据库连接池对象设计为的单例类，可能会导致共享连接池对象的程序过多而出现连接池溢出。
3.如果实例化的对象长时间不被利用，系统会认为该对象是垃圾而被回收，这可能会导致对象状态的丢失。
Spring 的单例实现原理
在Spring中，Bean默认是单例的，这是因为Spring容器在初始化时会将Bean对象创建并缓存在容器中，默认情况下，Spring容器使用单例模式来管理Bean实例。
以下是 Spring 实现单例的主要步骤和原理：
- Bean 定义：在 Spring 的配置文件中（如 XML 文件）或通过注解方式，我们定义 Bean 及其相关属性。其中，scope 属性用于指定 Bean 的作用域，默认值是 “singleton”，表示该 Bean 是一个单例。
- 容器初始化：当 Spring 容器启动时，它会读取配置文件或注解信息，并解析 Bean 的定义。对于每个单例 Bean，Spring 容器会创建一个实例，并将其存储在容器的内部缓存中。
- Bean 获取：当应用中的代码通过 ApplicationContext 或 BeanFactory 调用 getBean() 方法来获取某个单例 Bean 时，Spring 容器会首先检查其内部缓存。如果该 Bean 已经存在（即已经被创建过），则直接返回该实例；否则，根据 Bean 的定义创建一个新的实例，并存储在缓存中，然后返回该实例。
- 单例保证：由于 Spring 容器在内部缓存了单例 Bean 的实例，并且在每次获取 Bean 时都优先从缓存中查找，因此确保了在整个应用上下文中，对于同一个单例 Bean 的定义，始终返回同一个实例。
- 容器销毁：当 Spring 容器被销毁时，它会负责销毁所有它管理的 Bean，包括单例 Bean。这确保了资源的正确释放和避免内存泄漏。
需要注意的是，虽然 Spring 保证了单例 Bean 在容器范围内的唯一性，但并不意味着它在整个 JVM 中都是唯一的。如果有多个 Spring 容器（例如，每个 Web 应用都有一个自己的 Spring 容器），那么每个容器都会创建自己的单例 Bean 实例。此外，对于原型（prototype）作用域的 Bean，Spring 每次都会创建一个新的实例，而不是共享同一个实例。
Spring的单例实现原理主要基于两个方面： - 默认作用域： 在Spring中，默认情况下，Bean的作用域（Scope）是单例（Singleton）。这意味着Spring容器中的每个Bean定义都只会创建一个实例，并在需要时重复使用这个实例。
- 容器管理： Spring容器是一个大型的对象管理容器，它负责创建、装配和管理Bean对象。当配置文件或注解启动Spring容器时，容器会按照配置创建Bean的实例并管理它们的生命周期。容器会在启动时实例化所有的单例Bean，并在需要时返回它们的引用，以确保单例的唯一性。
需要注意的是，虽然Spring默认将Bean配置为单例模式，但也可以通过在Bean的定义中显式地指定其他作用域（如原型、请求、会话等）来改变Bean的作用域。例如，在XML配置文件中可以使用元素的scope属性，或者在使用注解配置时可以使用@Scope注解来指定Bean的作用域。
总的来说，Spring的单例实现原理是基于容器管理和作用域定义的，它确保在Spring容器中每个Bean的实例是唯一的，并且可以在需要时被共享和重用。
Spring 框架中的单例实现原理主要依赖于其 IoC（控制反转）容器。在 Spring 中，当我们定义一个 Bean 时，Spring 容器会负责创建和管理这个 Bean 的生命周期。对于单例模式的 Bean，Spring 容器会确保只创建一个实例，并在整个应用上下文中共享这个实例。
单例被破坏的五个场景
分别为多线程破坏单例、指令重排破坏单例、克隆破坏单例、反序列化破坏单例、反射破坏单例。
1.多线程破坏单例
在多线程环境下，线程的时间片是由CPU自由分配的，具有随机性，而单例对象作为共享资源可能会
同时被多个线程同时操作，从而导致同时创建多个对象。当然，这种情况只出现在懒汉式单例中。如果是
饿汉式单例，在线程启动前就被初始化了，不存在线程再创建对象的情况。
如果懒汉式单例出现多线程破坏的情况，我给出以下两种解决方案：
1、改为DCL双重检查锁的写法。
2、使用静态内部类的写法，性能更高。
2.指令重排
指令重排也可能导致懒汉式单例被破坏。来看这样一句代码：
instance = new Singleton();
看似简单的一段赋值语句：instance = new Singleton();
其实JVM内部已经被转换为多条执行指令：
memory = allocate(); 分配对象的内存空间指令
ctorInstance(memory); 初始化对象
instance = memory; 将已分配存地址赋值给对象引用
1、分配对象的内存空间指令，调用allocate()方法分配内存。
2、调用ctorInstance()方法初始化对象
3、将已分配存地址赋值给对象引用
但是经过重排序后，执行顺序可能是这样的：
memory = allocate(); 分配对象的内存空间指令
instance = memory; 将已分配存地址赋值给对象引用
ctorInstance(memory); 初始化对象
1、分配对象的内存空间指令
2、设置instance指向刚分配的内存地址
3、初始化对象
我们可以看到指令重排之后，instance指向分配好的内存放在了前面，而这段内存的初始化的指令被
排在了后面，在线程 T1 初始化完成这段内存之前，线程T2 虽然进不去同步代码块，但是在同步代码块之
前的判断就会发现 instance 不为空，此时线程T2 获得 instance 对象，如果直接使用就可能发生错误。
如果出现这种情况，我该如何解决呢？只需要在成员变量前加volatile，保证所有线程的可见性就可
以了。private static volatile Singleton instance = null;
3.克隆破坏单例
在Java中，所有的类就继承自Object，也就是说所有的类都实现了clone()方法。如果是深clone()，
每次都会重新创建新的实例。那如果我们定义的是单例对象，岂不是也可调用clone()方法来反复创建新的
实例呢？确实，这种情况是有可能发生的。为了避免发生这样结果，我们可以在单例对象中重写clone()
方法，将单例自身的引用作为返回值。这样，就能避免这种情况发生。
4.反序列化破坏单例
我们将Java对象序列化以后，对象通常会被持久化到磁盘或者数据库。如果我们要再次加载到内存，
就需要将持久化的内容反序列化成Java对象。反序列化是基于字节码来操作的，我们要序列化以前的内容
进行反序列化到内存，就需要重新分配内存，也就是说，要重新创建对象。那如果要反序列化的对象恰恰
是单例对象，我们该怎么办呢？
我告诉大家一种解决方案，在反序列的过程中，Java API会调用readResolve()方法，可以通过获取
readResolve()方法的返回值覆盖反序列化创建的对象。
因此，只需要重写readResolve()方法，将返回值设置为已经存在的单例对象，就可以保证反序列化
以后的对象是同一个了。之后再将反序列化后的对象中的值，克隆到单例对象中。
5.反射破坏单例
以上讲的所有单例情况都有可能被反射破坏。因为Java中的反射机制是可以拿到对象的私有的构造方
法，也就是说，反射可以任意调用私有构造方法创建单例对象。当然，没有人会故意这样做，但是如果出
现意外的情况，该如何处理呢？我推荐大家两种解决方案，
第一种方案是在所有的构造方法中第一行代码进行判断，检查单例对象是否已经被创建，如果已经被
创建，则抛出异常。这样，构造方法将会被终止调用，也就无法创建新的实例。
第二种方案，将单例的实现方式改为枚举式单例，因为在JDK源码层面规定了，不允许反射访问枚举。
单例的实现方式
饿汉式单例
懒汉式-延迟加载方式
懒汉式双重加锁机制
静态内部类
容器式单例
注册式-枚举单例
ThreadLocal 线程内部
饿汉式单例
优点：执行效率高，性能高，线程安全
缺点：类加载时用不用都会初始化，资源浪费
package com.lc.singleton;
/**
* @Author lc
* @description:
* 1. * 饿汉式单例
* 2. * 优点：执行效率高，性能高，线程安全
* 3. * 缺点：类加载时用不用都会初始化，资源浪费
* @Date 2023/4/1 18:25
*/
public class HungrySingleton {
private HungrySingleton() {
};
private static HungrySingleton hungrySingleton = new HungrySingleton();
public static HungrySingleton getInstance() {
return hungrySingleton;
}
public static void main(String[] args) {
for (int i = 0; i <20 ; i++) {
new Thread(()->{
System.out.println(HungrySingleton.getInstance().hashCode());
}).start();
}
}
}
懒汉式-延迟加载方式
/**
*
* @Author lc
* @description:懒汉式-延迟加载方式
* @Date 2023/4/1 16:26
*/
public class SingletonLazy {
private SingletonLazy(){};
private static SingletonLazy singletonLazy ;
public static SingletonLazy getInstance(){
if(singletonLazy==null){
singletonLazy=new SingletonLazy();
}
return singletonLazy;
}
}
懒汉式双重加锁机制
package com.lc.singleton.lazy;
/**
* @Author lc
* @description: 懒汉式双重加锁机制
* 有使用synchronized关键字来同步获取实例，保证单例的唯一性，使用双重加锁机制正
*
* 懒汉式-双重检查锁
* 优点：被外部调用的时候创建对象，节省资源，性能高，线程安全
* 缺点：可读性难度加大，代码不够优雅
* @Date 2023/4/1 16:26
*/
public class SingletonLazyDoubleCheck {
private SingletonLazyDoubleCheck() {};
//volatile关键字的含义是：被其所修饰的变量的值不会被本地线程缓存，所有对该变量的读写都是直接操作共享内存来实现，
// 从而确保多个线程能正确的处理该变量,volatile的目的是为了防止暴露一个未初始化的不完整单例实例，导致系统崩溃
private volatile static SingletonLazyDoubleCheck singletonLazy;
//volatile来禁止指令重排
public static SingletonLazyDoubleCheck getInstance() {
//检查是否阻塞，如果已经创建过，就不需要再进入加锁代码块拉
//低性能，大大的提升性能，如果没有该检查，每次都会去竞争锁
if (singletonLazy == null) {
synchronized (SingletonLazyDoubleCheck.class) {
//检查是否重新创建实例
if (singletonLazy == null) {
singletonLazy = new SingletonLazyDoubleCheck();
}
}
}
return singletonLazy;
}
}
静态内部类
package com.lc.singleton.lazy;
/**
* @Author lc
* @description: 静态内部类
* 懒汉式-静态内部类
* * 优点：性能高，节省资源，利用了java本身的语法特点，不能够被反射破坏
* * 缺点：代码不优雅
* @Date 2023/4/1 20:39
*/
public class SingletonLazyStaticInnerClass {
private SingletonLazyStaticInnerClass(){};
private static SingletonLazyStaticInnerClass getInstance(){
return lazyHolder.STATIC_INNER_CLASS;
}
private static class lazyHolder{
private static final SingletonLazyStaticInnerClass STATIC_INNER_CLASS=new SingletonLazyStaticInnerClass();
}
}
容器式单例
package com.lc.singleton.register;
import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
/**
* @Author lc
* @description: 容器式单例 目前线程不安全 ，解决方案 加锁
* 可参考spring--AbstractFactoryBean getBean(String name)
* @Date 2023/4/1 20:47
*/
public class ContainerSingleton {
private ContainerSingleton() {};
private static Map<String, Object> ioc = new ConcurrentHashMap<>();
public static Object getInstance(String className) {
Object instance = null;
if (!ioc.containsKey(className)){
try {
instance = Class.forName(className).newInstance();
ioc.put(className,instance);
} catch (Exception e) {
throw new RuntimeException(e);
}
}else{
instance= ioc.get(className);
}
return instance;
}
public static void main(String[] args) {
Object instance1 = ContainerSingleton.getInstance("com.lc.singleton.register.User");
Object instance2 = ContainerSingleton.getInstance("com.lc.singleton.register.User");
System.out.println(instance1==instance2);
}
}
注册式-枚举单例
package com.lc.singleton.register;
/**
* @Author lc
* @description:注册式-枚举
* * 枚举式单例
* * 优点：线程安全，不能被反射破坏
* * 缺点：不适用大批量单例对象，浪费资源
* @Date 2023/4/1 20:24
*/
public enum EnunSingleton {
INSTANCE;
private Object data;
public Object getData() {
return data;
}
public void setData(Object data) {
this.data = data;
}
public static EnunSingleton getInstance() {
return INSTANCE;
}
public static void main(String[] args) {
EnunSingleton.getInstance().setData("你好");
}
}
ThreadLocal 线程内部
package com.lc.singleton;
/**
* @Author lc
* @description: ThreadLocal 线程内部
* @Date 2023/4/1 21:35
*/
public class ThreadLocalSingleton {
private static final ThreadLocal<ThreadLocalSingleton> THREAD_LOCAL_SINGLETON_THREAD_LOCAL =
new ThreadLocal<ThreadLocalSingleton>() {
@Override
protected ThreadLocalSingleton initialValue() {
return new ThreadLocalSingleton();
}
};
private ThreadLocalSingleton() {};
public static ThreadLocalSingleton getInstance() {
return THREAD_LOCAL_SINGLETON_THREAD_LOCAL.get();
}
public static void main(String[] args) {
System.out.println(ThreadLocalSingleton.getInstance());
System.out.println(ThreadLocalSingleton.getInstance());
}
}
实现线程安全的单例模式
● 在多线程环境中，不要使用简单的懒加载方式（只在getInstance()方法内部使用synchronized），因为这种方式在每次调用getInstance()时都会进行同步，性能较差。
● 使用双重检查锁定或静态内部类方式时，要注意构造函数不要有复杂的逻辑，以避免指令重排导致的问题。虽然使用volatile可以解决这个问题，但最好保持构造函数的简单性。
● 如果单例需要被序列化，需要增加防止反序列化的机制，例如实现readResolve()方法。
通常推荐使用枚举或静态内部类的方式来实现线程安全的单例，因为它们既简单又安全。
实现线程安全的单例模式，有多种方式可以确保在并发环境下单例的唯一性。以下是一些常见的方法：
1. 饿汉式（静态初始化）
public class Singleton {
private static final Singleton INSTANCE = new Singleton();
private Singleton() {
// 私有构造方法，防止外部通过 new Singleton() 创建实例
}
public static Singleton getInstance() {
return INSTANCE;
}
}
这种方式在类加载时就完成了初始化，所以天生就是线程安全的。
2. 懒汉式（双重检查锁定）
public class Singleton {
private volatile static Singleton instance;
private Singleton() {
// 私有构造方法，防止外部通过 new Singleton() 创建实例
}
public static Singleton getInstance() {
if (instance == null) { // 第一次检查实例是否存在，如果不存在才进入下面的同步块
synchronized (Singleton.class) {
if (instance == null) { // 第二次检查实例是否存在，如果不存在才创建实例
instance = new Singleton();
}
}
}
return instance;
}
}
双重检查锁定是一种延迟加载技术，避免了饿汉式在类加载时就完成初始化的开销。同时，由于使用了volatile关键字和双重检查，保证了线程安全。
3. 静态内部类
public class Singleton {
private Singleton() {
// 私有构造方法，防止外部通过 new Singleton() 创建实例
}
private static class SingletonHolder {
private static final Singleton INSTANCE = new Singleton();
}
public static Singleton getInstance() {
return SingletonHolder.INSTANCE;
}
}
静态内部类的方式利用了 JVM 的类加载机制来保证线程安全。当SingletonHolder类被加载时，会初始化其静态变量INSTANCE，由于 JVM 在类加载时是线程安全的，因此这种方式也是线程安全的。
4. 枚举（推荐）
public enum Singleton {
INSTANCE;
public void whateverMethod() {
// 方法体
}
}
在 Java 中，枚举是线程安全的，并且只会加载一次。因此，使用枚举来实现单例是最简单且最安全的方式。
5. 使用 java.util.concurrent.atomic.AtomicReference
import java.util.concurrent.atomic.AtomicReference;
public class Singleton {
private static final AtomicReference<Singleton> INSTANCE_REF = new AtomicReference<>();
private Singleton() {
// 私有构造方法，防止外部通过 new Singleton() 创建实例
}
public static Singleton getInstance() {
for (;;) {
Singleton current = INSTANCE_REF.get();
if (current != null) {
return current;
}
Singleton newInstance = new Singleton();
if (INSTANCE_REF.compareAndSet(null, newInstance)) {
return newInstance;
}
// 如果当前实例已经被其他线程初始化，则丢弃新创建的实例，并重试
}
}
}
使用AtomicReference和CAS（Compare-and-Swap）操作可以确保线程安全地实现单例。这种方式比双重检查锁定更为复杂，但在高并发场景下可能具有更好的性能。