Die Designmuster-Kolumne von Laomao wurde heimlich veröffentlicht. Nicht bereit, ein grober Junge zu sein? Können Sie sich immer noch nicht an das Designmuster erinnern, das Sie schon mehrmals gelesen haben? Dann vergessen Sie es nicht, bleiben Sie auf dem Laufenden und verstehen Sie die Essenz von Designmustern durch interessante Geschichten am Arbeitsplatz. Worauf wartest du? Beeilen Sie sich und steigen Sie ins Auto
Vergleichen Sie Systemsoftware mit einem Fluss und See: Designprinzipien sind die Kampfkunstmentalität von OO-Programmierern und Designmuster sind Bewegungen. Es reicht nicht aus, nur über mentale Fähigkeiten zu verfügen, man muss sie mit Bewegungen kombinieren. Nur wenn sich mentale Fähigkeiten und Bewegungen ergänzen, können wir mit mächtigen Feinden (wie dem „Betrugssystem“) umgehen, flexibel und unbesiegbar sein.
Der Geschäftsprozess und der Codeprozess, die zuvor vom Kätzchen sortiert wurden, wurden grundsätzlich aussortiert [Systemsortiermethode und Codesortiermethode]. Auf der Codeseite haben wir auch den Grund herausgefunden, warum das System aufgebläht war [Verstoß gegen Designprinzipien]. Mao Mao kam nach und nach auf den richtigen Weg und beschloss, mit einigen einfachen Geschäftsszenarien zu beginnen und mit der Optimierung des Systemcodes zu beginnen. Welche Art von Geschäftskodex wird also nach einer Änderung die geringsten Auswirkungen haben? Mao Mao sah es sich an und beschloss, mit dem zufällig erstellten Thread-Pool zu beginnen. Er plante, ihn im Singleton-Modus zu rekonstruieren.
In dem System, das Mao Mao übernimmt, wird der Thread-Pool normalerweise durch die direkte Implementierung von Multithreading-Funktionen in bestimmten Klassen nach Bedarf erstellt. Daher finden sich in vielen Serviceklassen Spuren der Erstellung von Thread-Pools.
Um das oben genannte Kitten-Problem zu lösen, planen wir, den Singleton-Modus zu verwenden, um einen gemeinsamen Thread-Pool-Executor zu erstellen, und ihn mit dem Factory-Modus für die Klassifizierungsverwaltung nach Geschäftstypen zu kombinieren.
Als nächstes beginnen wir mit dem Singleton-Modus.
Zusammenfassung
Singleton ist ein Entwurfsmuster, das sicherstellen soll, dass es nur eine Instanz einer bestimmten Klasse im System gibt und einen globalen Zugangspunkt für den externen Zugriff bietet. Dieser Modus scheint die Anzahl der Instanzen einer bestimmten Klasse im System zu steuern, Systemressourcen zu sparen und den Zugriff zu erleichtern. Durch den Singleton-Modus können Sie Objektinstanzen im System effektiv verwalten, die mehrfache Erstellung desselben Objekttyps vermeiden und die Systemleistung und Ressourcennutzung verbessern. Es gibt viele Möglichkeiten, das Singleton-Muster zu implementieren, einschließlich des Lazy-Man-Stils, des Hungrig-Man-Stils, der Double-Check-Sperre usw. In der Softwareentwicklung wird das Singleton-Muster häufig in Szenarien verwendet, die eine eindeutige Instanz erfordern, z. B. Konfigurationsinformationen, Protokollierung, Thread-Pools usw. Durch den Singleton-Modus kann die Systemarchitektur vereinfacht, der Kopplungsgrad reduziert und die Wartbarkeit und Skalierbarkeit des Codes verbessert werden.
Einfaches Diagramm des Singleton-Modus
Was ist ein hungriger chinesischer Singleton? Um das Gedächtnis zu erleichtern, versteht die alte Katze dies. Das Bild eines hungrigen Mannes ist das eines hungrigen Menschen, wenn es Futter gibt. Das Bild des Singleton-Musters im Hungry-Stil ist, dass Sie es kaum erwarten können, ein Singleton-Objekt zu erstellen, wenn die Klasse erstellt wird. Dieses Singleton-Muster ist absolut Thread-sicher, da dieses Muster das Singleton-Objekt bereits vor einem Thread erstellt hat Beispiel erstellt.
Sehen Sie sich das Beispiel wie folgt an:
/**
* 公众号：程序员老猫
* 饿汉单例模式
*/
public class HungrySingleton {
private static final HungrySingleton HUNGRY_SINGLETON = new HungrySingleton();
//构造函数私有化，保证不被new方式多次创建新对象
private HungrySingleton() {
}
public static HungrySingleton getInstance(){
return HUNGRY_SINGLETON;
}
}Werfen wir einen Blick auf die Vor- und Nachteile der oben genannten Fälle:
Die aktuelle Entwicklung von Hardware und Servern ist schneller als die Entwicklung von Software. Darüber hinaus haben Microservices und Cluster-Bereitstellung die Schwelle und die Kosten für die horizontale Erweiterung erheblich gesenkt. Daher ist Laomao der Ansicht, dass der aktuelle Speicher tatsächlich wertlos ist Es ist nicht wahr, wie schwerwiegend die Mängel des Singleton-Modells sind. Ich persönlich bin der Meinung, dass die Verwendung dieses Modells im tatsächlichen Entwicklungsprozess kein Problem darstellt.
Tatsächlich ist der IOC-Container im Frühlings-Framework, das wir täglich verwenden, ein Singleton-Modus im chinesischen Stil. Wenn der Frühling beginnt, werden wir ihn hier nicht erweitern Code später. Lassen Sie uns später darauf eingehen.
Wir sagten, dass der Nachteil des oben erwähnten Lazy-Man-Singleton-Modus die Speicherverschwendung ist, da beim Laden der Klasse Objekte erstellt werden. Um diese Art der Speicherverschwendung zu lösen, haben wir den „Lazy-Man-Modus“ verwendet. So versteht Laomao diese Art von Singleton-Muster. Die Definition einer faulen Person vermittelt den Menschen das intuitive Gefühl von Faulheit und Aufschub. In Bezug auf das entsprechende Modell besteht die Methode zum Erstellen eines Objekts in diesem Schema darin, zu bestimmen, ob das Objekt instanziiert wurde (Beurteilung null), bevor das Programm das Objekt verwendet. Wenn es instanziiert wurde, gibt es das Objekt direkt zurück Andernfalls wird zuerst die Instanziierung durchgeführt.
Sehen Sie sich das Beispiel wie folgt an:
/**
* 公众号：程序员老猫
* 懒汉式单例模式
*/
public class LazySingleton {
private LazySingleton() {
}
private static LazySingleton lazySingleton = null;
public static LazySingleton getInstance() {
if (lazySingleton == null) {
lazySingleton =new LazySingleton();
}
return lazySingleton;
}
}Das Speicherproblem scheint beim Erstellen von Objekten im oben genannten Singleton-Modus gelöst worden zu sein, aber ist diese Erstellungsmethode wirklich Thread-sicher? Schreiben wir als nächstes eine einfache Testdemo:
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");
}
}Die Ausführungsausgabe lautet wie folgt:
end LazySingleton@3fde6a42 LazySingleton@2648fc3a
Anhand der obigen Ausgabe können wir leicht feststellen, dass die in den beiden Threads erhaltenen Objekte unterschiedlich sind. Dies hat natürlich eine gewisse Wahrscheinlichkeit. In diesem Multithread-Anforderungsszenario treten also Thread-Sicherheitsprobleme auf.
聊到共享变量访问线程安全性的问题，我们往往就想到了锁，所以，咱们在原有的代码块上加上锁对其优化试试，我们首先想到的是给方法代码块加上锁。
加锁后代码如下：
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层来看并不是一个原子性的行为，这里其实发生了三件事：
在此期间存在着指令重排序的优化，第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());
}
}Das obige ist der detaillierte Inhalt vonEin Singleton-Modus, das muss doch nicht so kompliziert sein, oder?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
