싱글톤 모드라면 그렇게 복잡할 필요는 없겠죠?

라오마오의 디자인 패턴 칼럼이 비밀리에 공개되었습니다. 멍청한 소년이 될 의향이 없나요? 여러 번 읽은 디자인 패턴을 아직도 기억하지 못하시나요? 그렇다면 잊지 말고 늙은 고양이의 이야기를 따라가며 흥미로운 직장 이야기를 통해 디자인 패턴의 본질을 이해해 보세요. 당신은 무엇을 기다리고 있습니까? 빨리 차에 타세요

시스템 소프트웨어를 강과 호수에 비유하면 디자인 원칙은 OO 프로그래머의 무술 정신이고, 디자인 패턴은 움직임입니다. 정신적 능력만으로는 충분하지 않으며, 이를 동작과 결합해야 합니다. 정신적 기술과 움직임이 서로 보완될 때만 우리는 강력한 적(예: "치팅 시스템")을 처리하고 유연하며 무적이 될 수 있습니다.

스토리

기존에 새끼고양이가 정렬하던 비즈니스 프로세스와 코드 프로세스가 기본적으로 [시스템 정렬 방식 & 코드 정렬 방식]으로 정리되었습니다. 코드 측면에서도 시스템이 비대해진 이유(설계 원칙 위반)도 알아냈습니다. Mao Mao는 점차 올바른 방향으로 나아갔고 몇 가지 간단한 비즈니스 시나리오부터 시작하여 시스템 코드 최적화를 시작하기로 결정했습니다. 그렇다면 어떤 종류의 비즈니스 코드가 변경된 후 가장 적은 영향을 미치게 될까요? Maomao는 이를 보고 무작위로 생성된 스레드 풀부터 시작하기로 결정하고 이를 싱글톤 모드를 사용하여 재구성할 계획이었습니다.

마오마오가 인수한 시스템에서는 일반적으로 필요에 따라 특정 클래스에 멀티스레딩 기능을 직접 구현하여 스레드 풀을 생성했습니다. 따라서 스레드 풀을 생성한 흔적은 많은 서비스 서비스 클래스에서 발견될 것이다.

앞으로 쓰기

위 키티 문제를 해결하기 위해 싱글톤 모드를 사용하여 공유 스레드 풀 실행자를 생성하고 이를 팩토리 모드와 결합하여 업종에 따른 분류 관리를 할 계획입니다.

다음으로 싱글턴 모드부터 시작해 보겠습니다.

요약

단일 사례 패턴 정의

싱글턴은 시스템에 특정 클래스의 인스턴스가 하나만 있도록 보장하고 외부 액세스를 위한 전역 액세스 지점을 제공하는 것을 목표로 하는 디자인 패턴입니다. 이 모드는 시스템에서 특정 클래스의 인스턴스 수를 제어하고 시스템 리소스를 절약하며 액세스를 용이하게 하는 것으로 나타납니다. 싱글톤 모드를 통해 시스템의 개체 인스턴스를 효과적으로 관리하고, 동일한 유형의 개체가 여러 번 생성되는 것을 방지하며, 시스템 성능 및 리소스 활용도를 향상시킬 수 있습니다. 게으른 사람 스타일, 배고픈 사람 스타일, 이중 확인 잠금 등을 포함하여 싱글턴 패턴을 구현하는 방법에는 여러 가지가 있습니다. 소프트웨어 개발에서 싱글톤 패턴은 구성 정보, 로깅, 스레드 풀 등과 같은 고유한 인스턴스가 필요한 시나리오에서 자주 사용됩니다. 싱글톤 모드를 통해 시스템 아키텍처를 단순화할 수 있고, 결합도를 줄일 수 있으며, 코드의 유지보수성 및 확장성을 향상시킬 수 있습니다.

싱글턴 모드의 간단한 다이어그램

Hungry 중국식 싱글턴 패턴

배고픈 중국인 싱글턴이란? 기억을 쉽게 하기 위해 늙은 고양이는 배고픈 사람의 이미지가 음식이 있으면 먹고 싶어하는 이미지임을 이해합니다. 그래서 배고픈 싱글톤 패턴의 이미지는 클래스가 생성될 때 싱글톤 객체를 생성하기를 기다릴 수 없다는 것입니다. 이 싱글톤 패턴은 스레드가 생성되기 전에 이미 싱글톤 객체를 생성했기 때문에 절대적으로 스레드로부터 안전합니다. . 예.

다음 예를 살펴보세요.

으아악

위 사례의 장단점을 살펴보겠습니다.

• 장점: 스레드 안전성, 클래스 로드 시 초기화가 완료되고 객체 획득이 더 빠릅니다.
• 단점: 클래스가 로드되면 객체 생성이 완료되기 때문에 호출하지 않고 객체가 이미 존재하는 경우가 있어 메모리 낭비가 발생합니다.

현재 하드웨어와 서버의 발전은 소프트웨어의 발전보다 빠릅니다. 게다가 마이크로서비스와 클러스터 배포로 인해 수평적 확장의 한계점과 비용이 크게 줄어들었습니다. 따라서 Laomao는 현재의 메모리가 사실상 쓸모가 없다고 생각합니다. 싱글톤 모델의 단점이 얼마나 심각한지 말하는 것은 사실이 아닙니다. 개인적으로는 실제 개발 과정에서 이 모델을 사용하는데 문제가 없다고 생각합니다.

사실 우리가 매일 사용하는 스프링 프레임워크에서는 IOC 컨테이너 자체가 중국식 싱글톤 모드입니다. 스프링이 시작되면 객체가 메모리에 로드됩니다. 여기서는 스프링 소스를 정리하지 않겠습니다. 나중에 이에 대해 확장해 보겠습니다.

게으른 싱글톤 패턴

위에서 언급한 게으른 사람 싱글톤 모드의 단점은 클래스가 로드될 때 객체를 생성하기 때문에 메모리 낭비라고 했습니다. 그래서 이러한 종류의 메모리 낭비를 해결하기 위해 "게으른 사람 모드"가 있습니다. 이것이 Laomao가 이러한 유형의 싱글톤 패턴을 이해하는 방법입니다. 게으른 사람의 정의는 사람들에게 게으름과 꾸물거림에 대한 직관적인 느낌을 줍니다. 해당 모델의 경우, 이 방식에서 객체를 생성하는 방법은 프로그램이 객체를 사용하기 전에 객체가 인스턴스화되었는지(판단 공백) 먼저 확인하는 것입니다. 인스턴스화되면 해당 객체를 직접 반환합니다. 그렇지 않으면 인스턴스화가 먼저 수행됩니다.

다음 예를 살펴보세요.

으아악

위의 싱글톤 모드로 객체를 생성하면 메모리 문제가 해결된 것 같은데, 이 생성 방법이 과연 스레드로부터 안전한가요? 다음에는 간단한 테스트 데모를 작성해 보겠습니다.

으아악

실행 출력은 다음과 같습니다.

으아악

위 출력에서 ​​우리는 두 스레드에서 얻은 객체가 서로 다르다는 것을 쉽게 알 수 있습니다. 물론 여기에는 일정한 확률이 있습니다. 따라서 이 다중 스레드 요청 시나리오에서는 스레드 안전 문제가 발생합니다.

聊到共享变量访问线程安全性的问题，我们往往就想到了锁，所以，咱们在原有的代码块上加上锁对其优化试试，我们首先想到的是给方法代码块加上锁。

加锁后代码如下：

public class LazySingleton {

private LazySingleton() {
}

private static LazySingleton lazySingleton = null;
public synchronized static LazySingleton getInstance() {
if (lazySingleton == null) {
lazySingleton =new LazySingleton();
}
return lazySingleton;
}
}

经过上述同样的测试类运行之后，我们发现问题似乎解决了，每次运行之后得到的结果，两个线程对象的输出都是一致的。

我们用线程debug的方式看一下具体的运行情况，如下图：

线程输出

我们可以发现，当一个线程进行初始化实例时，另一个线程就会从Running状态自动变成了Monitor状态。试想一下，如果有大量的线程同时访问的时候，在这样一个锁的争夺过程中就会有很多的线程被挂起为Monitor状态。CPU压力随着线程数的增加而持续增加，显然这种实现对性能还是很有影响的。

那还有优化的空间么？当然有，那就是大家经常听到的“DCL”即“Double Check Lock” 实现如下：

/**
 * 公众号：程序员老猫
 * 懒汉式单例模式(DCL)
 * Double Check Lock
 */
public class LazySingleton {

private LazySingleton() {
}
//使用volatile防止指令重排
private volatile static LazySingleton lazySingleton = null;
public static LazySingleton getInstance() {
if (lazySingleton == null) {
synchronized (LazySingleton.class) {
if(lazySingleton == null){
lazySingleton =new LazySingleton();
}
}
}
return lazySingleton;
}
}

通过DEBUG，我们来看一下下图：

双重校验锁

这里引申一个常见的问题，大家在面试的时候估计也会碰到。问题：为什么要double check？去掉第二次check行不行？

回答：当2个线程同时执行getInstance方法时，都会执行第一个if判断，由于锁机制的存在，会有一个线程先进入同步语句，而另一个线程等待，当第一个线程执行了new Singleton()之后，就会退出synchronized的保护区域，这时如果没有第二重if判断，那么第二个线程也会创建一个实例，这就破坏了单例。

问题：这里为什么要加上volatile修饰关键字？回答：这里加上该关键字主要是为了防止”指令重排”。关于“指令重排”具体产生的原因我们这里不做细究，有兴趣的小伙伴可以自己去研究一下，我们这里只是去分析一下，“指令重排”所带来的影响。

lazySingleton =new LazySingleton();

这样一个看似简单的动作，其实从JVM层来看并不是一个原子性的行为，这里其实发生了三件事：

• 给LazySingleton分配内存空间。
• 调用LazySingleton的构造函数，初始化成员字段。
• 将LazySingleton指向分配的内存空间(注意此时的LazySingleton就不是null了)

在此期间存在着指令重排序的优化，第2、3步的顺序是不能保证的，最后的执行顺序可能是1-2-3，也可能是1-3-2，假如执行顺序是1-3-2，我们看看会出现什么问题。看一下下图：

指令重排执行

从上图中我们看到虽然LazySingleton不是null，但是指向的空间并没有初始化，最终被业务使用的时候还是会报错，这就是DCL失效的问题，这种问题难以跟踪难以重现可能会隐藏很久。

JDK1.5之前JMM(Java Memory Model，即Java内存模型)中的Cache、寄存器到主存的回写规定，上面第二第三的顺序无法保证。JDK1.5之后，SUN官方调整了JVM，具体化了volatile关键字，private volatile static LazySingleton lazySingleton;只要加上volatile，就可以保证每次从主存中读取（这涉及到CPU缓存一致性问题，感兴趣的小伙伴可以研究研究），也可以防止指令重排序的发生，避免拿到未完成初始化的对象。

上面这种方式可以有效降低锁的竞争，锁不会将整个方法全部锁定，而是锁定了某个代码块。其实完全做完调试之后我们还是会发现锁争夺的问题并没有完全解决，用到了锁肯定会对整个代码的执行效率带来一定的影响。所以是否存在保证线程的安全，并且能够不浪费内存完美的解决方案呢？一起看下下面的解决方案。

内部静态类单例模式

这种方式其实是利用了静态对象创建的特性来解决上述内存浪费以及线程不安全的问题。在这里我们要弄清楚，被static修饰的属性，类加载的时候，基本属性就已经加载完毕，但是静态方法却不会加载的时候自动执行，而是等到被调用之后才会执行。并且被STATIC修饰的变量JVM只为静态分配一次内存。(这里老猫不展开去聊static相关知识点，有兴趣的小伙伴也可以自行去了解一下更多JAVA中static关键字修饰之后的类、属性、方法的加载机制以及存储机制)

所以综合这一特性，我们就有了下面这样的写法：

public class LazyInnerClassSingleton {
private LazyInnerClassSingleton () {
}

public static final LazyInnerClassSingleton getInstance() {
return LazyHolder.LAZY;
}

private static class LazyHolder {
private static final LazyInnerClassSingleton LAZY = new LazyInnerClassSingleton();
}
}

上面这种写法，其实也属于“懒汉式单例模式”，并且这种模式相对于“无脑加锁”以及“DCL”以及“饿汉式单例模式”来说无疑是最优的一种实现方式。

但是深度去追究的话，其实这种方式也会有问题，这种写法并不能防止反序列化和反射生成多个实例。我们简单看一下反射的破坏的测试类：

public class DestructionSingletonTest {
public static void main(String[] args) throws NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException {
Class enumSingletonClass = LazyInnerClassSingleton.class;
//枚举默认有个String 和 int 类型的构造器
Constructor constructor = enumSingletonClass.getDeclaredConstructor();
constructor.setAccessible(true);
//利用反射调用构造方法两次直接创建两个对象，直接破坏单例模式
LazyInnerClassSingleton singleton1 = (LazyInnerClassSingleton) constructor.newInstance();
LazyInnerClassSingleton singleton2 = (LazyInnerClassSingleton) constructor.newInstance();
}
}

这里序列化反序列化单例模式破坏老猫偷个懒，因为下面会有写到，有兴趣的小伙伴继续看下文，老猫觉得这种破坏场景在真实的业务使用场景比较极端，如果不涉及底层框架变动，光从业务角度来看，上面这些单例模式的实现已经管够了。当然如果硬是要防止上面的反射创建单例两次问题也能解决,如下：

public class LazyInnerClassSingleton {
private LazyInnerClassSingleton () {
if(LazyHolder.LAZY != null) {
throw new RuntimeException("不允许创建多个实例");
}
}

public static final LazyInnerClassSingleton getInstance() {
return LazyHolder.LAZY;
}

private static class LazyHolder {
private static final LazyInnerClassSingleton LAZY = new LazyInnerClassSingleton();
}
}

写到这里，可能大家都很疑惑了，咋还没提及用单例模式优化线程池创建。下面这不来了么，老猫个人觉得上面的这种方式进行创建单例还是比较好的，所以就用这种方式重构一下线程池的创建，具体代码如下：

public class InnerClassLazyThreadPoolHelper {
public static void execute(Runnable runnable) {
ThreadPoolExecutor threadPoolExecutor = ThreadPoolHelperHolder.THREAD_POOL_EXECUTOR;
threadPoolExecutor.execute(runnable);
}
/**
 * 静态内部类创建实例(单例).
 * 优点：被调用时才会创建一次实例
 */
public static class ThreadPoolHelperHolder {
private static final int CPU = Runtime.getRuntime().availableProcessors();
private static final int CORE_POOL_SIZE = CPU + 1;
private static final int MAXIMUM_POOL_SIZE = CPU * 2 + 1;
private static final long KEEP_ALIVE_TIME = 1L;
private static final TimeUnit TIME_UNIT = TimeUnit.SECONDS;
private static final int MAX_QUEUE_NUM = 1024;

private ThreadPoolHelperHolder() {
}

private static final ThreadPoolExecutor THREAD_POOL_EXECUTOR = new ThreadPoolExecutor(
CORE_POOL_SIZE, MAXIMUM_POOL_SIZE, KEEP_ALIVE_TIME, TIME_UNIT,
new LinkedBlockingQueue(MAX_QUEUE_NUM),
new ThreadPoolExecutor.AbortPolicy());
}
}

위 내용은 싱글톤 모드라면 그렇게 복잡할 필요는 없겠죠?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!