Mod singleton, tak perlu rumit sangat kan?

Lajur corak reka bentuk Laomao telah dikeluarkan secara rahsia. Tidak sanggup menjadi budak kasar? Masih tidak ingat corak reka bentuk yang telah anda baca beberapa kali? Kemudian jangan lupa, bersaing dengan kucing lama, dan fahami intipati corak reka bentuk melalui cerita tempat kerja yang menarik. Apa tunggu lagi Cepat masuk kereta

Bandingkan perisian sistem dengan sungai dan tasik, prinsip reka bentuk ialah mentaliti seni mempertahankan diri pengaturcara OO, dan corak reka bentuk adalah pergerakan. Ia tidak mencukupi untuk mempunyai kemahiran mental sahaja, anda perlu menggabungkannya dengan gerakan. Hanya apabila kemahiran mental dan pergerakan saling melengkapi antara satu sama lain kita boleh berhadapan dengan musuh yang kuat (seperti "sistem penipuan"), menjadi fleksibel dan tidak dapat dikalahkan.

Cerita

Proses perniagaan dan proses kod yang sebelum ini diisih oleh anak kucing pada dasarnya telah diselesaikan [kaedah pengisihan sistem & kaedah pengisihan kod]. Dari sisi kod, kami juga mengetahui sebab mengapa sistem itu kembung [melanggar prinsip reka bentuk]. Mao Mao beransur-ansur berada di landasan yang betul, dan dia memutuskan untuk memulakan dengan beberapa senario perniagaan mudah dan mula mengoptimumkan kod sistem. Jadi apakah jenis kod perniagaan yang akan mempunyai kesan paling sedikit selepas ditukar? Maomao melihatnya dan memutuskan untuk memulakan dengan kumpulan benang yang dicipta secara rawak Dia merancang untuk menggunakan mod tunggal untuk membina semula.

Dalam sistem yang diambil alih oleh Mao Mao, kumpulan benang biasanya dibuat dengan melaksanakan secara langsung fungsi berbilang benang dalam kelas tertentu mengikut keperluan. Oleh itu, kesan mencipta kumpulan benang akan ditemui dalam banyak kelas perkhidmatan perkhidmatan.

Tulis di hadapan

Untuk menyelesaikan masalah anak kucing di atas, kami bercadang untuk menggunakan mod tunggal untuk mencipta pelaksana kolam benang kongsi, dan menggabungkannya dengan mod kilang untuk pengurusan klasifikasi mengikut jenis perniagaan.

Seterusnya, mari mulakan dengan mod tunggal.

Ringkasan

Takrifan corak kes tunggal

Singleton ialah corak reka bentuk yang bertujuan untuk memastikan bahawa hanya terdapat satu contoh kelas tertentu dalam sistem dan menyediakan titik capaian global untuk akses luaran. Mod ini nampaknya mengawal bilangan kejadian kelas tertentu dalam sistem, menjimatkan sumber sistem dan memudahkan akses. Melalui mod tunggal, anda boleh mengurus kejadian objek dalam sistem dengan berkesan, mengelak daripada mencipta jenis objek yang sama beberapa kali dan meningkatkan prestasi sistem dan penggunaan sumber. Terdapat banyak cara untuk melaksanakan corak tunggal, termasuk gaya lelaki malas, gaya lelaki lapar, kunci semak dua kali, dsb. Dalam pembangunan perisian, corak tunggal sering digunakan dalam senario yang memerlukan contoh unik, seperti maklumat konfigurasi, pengelogan, kumpulan benang, dsb. Melalui mod tunggal, seni bina sistem boleh dipermudahkan, tahap gandingan boleh dikurangkan, dan kebolehselenggaraan dan skalabiliti kod boleh dipertingkatkan.

Rajah ringkas mod tunggal

Corak singleton gaya Cina yang lapar

Apakah itu bujang Cina yang lapar? Untuk memudahkan ingatan, kucing tua itu memahami perkara ini. Jadi imej corak tunggal gaya Lapar ialah apabila kelas dibuat, anda tidak sabar untuk mencipta objek tunggal Corak tunggal ini benar-benar selamat untuk benang, kerana corak ini telah mencipta objek tunggal sebelum benang dijana contoh.

Lihat contoh, seperti berikut:

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

private static final HungrySingleton HUNGRY_SINGLETON = new HungrySingleton();

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

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

Mari kita lihat kebaikan dan keburukan kes di atas:

• Kelebihan: Keselamatan benang, permulaan selesai apabila kelas dimuatkan dan pemerolehan objek lebih cepat.
• Kelemahan: Memandangkan penciptaan objek selesai apabila kelas dimuatkan, kadangkala objek itu sudah wujud tanpa memanggilnya, yang akan menyebabkan pembaziran memori.

Pembangunan perkakasan dan pelayan semasa adalah lebih pantas daripada pembangunan perisian Selain itu, perkhidmatan mikro dan penggunaan kluster telah banyak mengurangkan ambang dan kos pengembangan mendatar Oleh itu, Laomao merasakan bahawa memori semasa sebenarnya tidak bernilai adalah tidak benar untuk mengatakan betapa seriusnya kekurangan model singleton secara peribadi, saya merasakan bahawa tidak ada masalah untuk menggunakan model ini dalam proses pembangunan sebenar.

Malah, dalam rangka kerja musim bunga yang kami gunakan setiap hari, bekas IOC itu sendiri adalah mod tunggal gaya Cina Apabila musim bunga bermula, objek itu dimuatkan ke dalam ingatan Kami tidak akan mengembangkannya di sini kod kemudian.

Corak Singleton Malas

Kami mengatakan bahawa kelemahan mod singleton lelaki malas yang disebutkan di atas adalah pembaziran memori, kerana ia mencipta objek apabila kelas dimuatkan Jadi untuk menyelesaikan pembaziran memori seperti ini, kami mempunyai "mod lelaki malas". Beginilah cara Laomao memahami corak singleton jenis ini. Takrifan orang yang malas memberikan orang perasaan malas dan penangguhan yang intuitif. Dari segi model yang sepadan, kaedah mencipta objek dalam skema ini adalah dengan terlebih dahulu menentukan sama ada objek itu telah dijadikan instantiated (penghakiman kosong) sebelum program menggunakan objek Jika ia telah instantiated, ia akan terus mengembalikan objek jenis ini. Jika tidak, instantiasi akan dijalankan terlebih dahulu.

Lihat contoh, seperti berikut:

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

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

Masalah ingatan nampaknya telah diselesaikan apabila mencipta objek dalam mod tunggal di atas, tetapi adakah kaedah penciptaan ini benar-benar selamat untuk benang? Mari tulis demo ujian ringkas seterusnya:

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

Output pelaksanaan adalah seperti berikut:

end
LazySingleton@3fde6a42
LazySingleton@2648fc3a

Daripada output di atas, kita boleh dengan mudah mendapati bahawa objek yang diperolehi dalam dua utas adalah berbeza, ini mempunyai kebarangkalian tertentu. Jadi dalam senario permintaan berbilang benang ini, isu keselamatan benang timbul.

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

加锁后代码如下：

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

Atas ialah kandungan terperinci Mod singleton, tak perlu rumit sangat kan?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!