Un mode singleton, il n'y a pas besoin d'être si compliqué, non ?

La colonne des modèles de conception de Laomao a été secrètement publiée. Vous ne voulez pas être un garçon grossier ? Vous ne vous souvenez toujours pas du modèle de conception que vous avez lu plusieurs fois ? Alors ne l’oubliez pas, suivez le vieux chat et comprenez l’essence des modèles de conception à travers des histoires intéressantes sur le lieu de travail. Qu'est-ce que tu attends? Dépêchez-vous et montez dans la voiture

Comparez le logiciel système à une rivière et à un lac, les principes de conception sont la mentalité d'arts martiaux des programmeurs OO et les modèles de conception sont des mouvements. Il ne suffit pas d'avoir des compétences mentales, il faut les combiner avec des mouvements. Ce n'est que lorsque les compétences mentales et les mouvements se complètent que nous pouvons faire face à des ennemis puissants (comme le « système de triche »), être flexibles et invincibles.

Histoire

Le processus métier et le processus de code qui étaient auparavant triés par le chaton ont été essentiellement triés [méthode de tri du système et méthode de tri du code]. Du côté du code, nous avons également découvert la raison pour laquelle le système était gonflé [en violation des principes de conception]. Mao Mao s'est progressivement mis sur la bonne voie et il a décidé de commencer par quelques scénarios commerciaux simples et de commencer à optimiser le code du système. Alors, quel type de code commercial aura le moins d’impact après avoir été modifié ? Maomao l'a examiné et a décidé de commencer avec le pool de threads créé aléatoirement. Il a prévu d'utiliser le mode singleton pour le reconstruire.

Dans le système repris par Mao Mao, le pool de threads est généralement créé en implémentant directement des fonctions multithread dans des classes spécifiques selon les besoins. Par conséquent, des traces de création de pools de threads seront trouvées dans de nombreuses classes de services de service.

Écrivez devant

Afin de résoudre le problème du chaton ci-dessus, nous prévoyons d'utiliser le mode singleton pour créer un exécuteur de pool de threads partagé et de le combiner avec le mode usine pour la gestion de la classification selon les types d'entreprise.

Ensuite, commençons par le mode singleton.

Résumé

Définition du modèle de cas unique

Singleton est un modèle de conception qui vise à garantir qu'il n'y a qu'une seule instance d'une classe spécifique dans le système et fournit un point d'accès global pour l'accès externe. Ce mode semble contrôler le nombre d'instances d'une certaine classe dans le système, économiser les ressources du système et faciliter l'accès. Grâce au mode singleton, vous pouvez gérer efficacement les instances d'objets dans le système, éviter de créer plusieurs fois le même type d'objets et améliorer les performances du système et l'utilisation des ressources. Il existe de nombreuses façons de mettre en œuvre le modèle singleton, notamment le style de l'homme paresseux, le style de l'homme affamé, le verrouillage à double contrôle, etc. Dans le développement de logiciels, le modèle singleton est souvent utilisé dans des scénarios nécessitant une instance unique, tels que les informations de configuration, la journalisation, les pools de threads, etc. Grâce au mode singleton, l'architecture du système peut être simplifiée, le degré de couplage peut être réduit et la maintenabilité et l'évolutivité du code peuvent être améliorées.

Schéma simple du mode singleton

Modèle singleton de style chinois affamé

Qu'est-ce qu'un singleton chinois affamé ? Afin de faciliter la mémoire, le vieux chat comprend cela. L'image d'un homme affamé est celle d'un homme impatient de manger quand il y a de la nourriture. Ainsi, l'image du modèle singleton de style Hungry est que lorsque la classe est créée, vous ne pouvez pas attendre pour créer un objet singleton. Ce modèle singleton est absolument thread-safe, car ce modèle a déjà créé l'objet singleton avant un thread. est généré exemple.

Regardez l'exemple suivant :

/**
 * 公众号：程序员老猫
 * 饿汉单例模式 
 */
public class HungrySingleton {

private static final HungrySingleton HUNGRY_SINGLETON = new HungrySingleton();

//构造函数私有化，保证不被new方式多次创建新对象
private HungrySingleton() {
}

public static HungrySingleton getInstance(){
return HUNGRY_SINGLETON;
}
}

Jetons un coup d'œil aux avantages et aux inconvénients des cas ci-dessus :

• Avantages : sécurité des threads, l'initialisation est terminée lorsque la classe est chargée et l'acquisition d'objets est plus rapide.
• Inconvénients : La création de l'objet étant terminée au chargement de la classe, parfois l'objet existe déjà sans l'appeler, ce qui entraînera un gaspillage de mémoire.

Le développement actuel du matériel et des serveurs est plus rapide que le développement des logiciels. De plus, les microservices et le déploiement de clusters ont considérablement réduit le seuil et le coût de l'expansion horizontale. Par conséquent, Laomao estime que la mémoire actuelle ne vaut en réalité rien, donc ce qui précède. Il n'est pas vrai de dire à quel point les défauts du modèle singleton sont graves. Personnellement, je pense qu'il n'y a aucun problème à utiliser ce modèle dans le processus de développement réel.

En fait, dans le framework spring que nous utilisons quotidiennement, le conteneur IOC lui-même est un mode singleton de style chinois. Lorsque le spring démarre, l'objet est chargé dans la mémoire. Nous ne l'étendrons pas ici. code plus tard. Développons cela plus tard.

Modèle Singleton paresseux

Nous avons dit que l'inconvénient du mode singleton paresseux mentionné ci-dessus est le gaspillage de mémoire, car il crée des objets lorsque la classe est chargée. Donc, pour résoudre ce type de gaspillage de mémoire, nous avons le "mode paresseux". C'est ainsi que Laomao comprend ce type de modèle singleton. La définition d'une personne paresseuse donne aux gens un sentiment intuitif de paresse et de procrastination. En termes de modèle correspondant, la méthode de création d'un objet dans ce schéma consiste à déterminer d'abord si l'objet a été instancié (jugement vide) avant que le programme n'utilise l'objet. S'il a été instancié, il renverra directement l'objet de. ce type. Dans le cas contraire, l'instanciation sera effectuée en premier.

Regardez l'exemple suivant :

/**
 * 公众号：程序员老猫
 * 懒汉式单例模式
 */
public class LazySingleton {
private LazySingleton() {
}

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

Le problème de mémoire semble avoir été résolu lors de la création d'objets en mode singleton ci-dessus, mais cette méthode de création est-elle vraiment thread-safe ? Écrivons ensuite une démo de test simple :

public class Main {
public static void main(String[] args) {
Thread thread1 = new Thread(()->{
LazySingleton lazySingleton = LazySingleton.getInstance();
System.out.println(lazySingleton.toString());
});
Thread thread2 = new Thread(()->{
LazySingleton lazySingleton = LazySingleton.getInstance();
System.out.println(lazySingleton.toString());
});
thread1.start();
thread2.start();
System.out.println("end");
}
}

Le résultat de l'exécution est le suivant :

end
LazySingleton@3fde6a42
LazySingleton@2648fc3a

À partir du résultat ci-dessus, nous pouvons facilement constater que les objets obtenus dans les deux threads sont différents. Bien sûr, cela a une certaine probabilité. Ainsi, dans ce scénario de requête multithread, des problèmes de sécurité des threads surviennent.

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

加锁后代码如下：

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());
}
}

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!