Singleton 单利模式的4个分身
“单利模式”的用途?在项目着实没什么用,实在不需要手写一个单利。需要使用工具类的地方,静态类就很好了,且有很多工具类已经是现有的轮子。比如CollectionUtils, TimeUtils, DateTimeUtils, LocalDateTimeUtils....无限多。Hutool这个工具类中也包含了很多日常很有有的工具类,日渐成长,声势越来越旺。 Spring容器倒是管理着很多的单利,但对于日常开发来讲确实无甚感知。
广为流传的singleton有4个分身,分别是懒汉模式(Lazy)、饿汉模式(Hungry)、加重量锁(Synchronized)、双重检查锁(DCL)。其中懒汉模式会有一丢丢问题,其他模式问题不大,区别于性能上的一丢丢差别。还是冷眼看看他们都长什么样吧。(但将冷眼观螃蟹,看它横行到几时?嗯,就是这个冷眼)
hutool文档地址:http://hutool.mydoc.io/
1.Lazy 懒汉模式
一个看上去都不用解释的写法。没有就创建,有就用。先看代码!!!
public class Lazy {
private static Lazy instance = null;
public static Lazy getInstance(){
/**
* 相关的业务逻辑
*/
if(null == instance){
instance = new Lazy();
}
return instance;
}
// 私有构造
}
一丢丢的问题就是出在了并发的时候,移步下图:
按照此图所标顺序执行,则会new出两个对象。两个对象就两个对象吧,也不耽误使用是吧。哦,不不不。如果在创建对象之前执行过业务逻辑,那可就不一定了对吧?举个🌰:我无聊的需要创建对象的时候传入你创建对象的意图,Thread1(我就无聊本身), Thread2(我就不无聊)。此刻就乱了,Thread1说自己无聊,但后来者这发现这不无聊。因为最终的对象已经被Thread2更改了名字。...这个例子也很无聊。
2.Hungry 饿汉模式
又一个看上去都不用解释的写法。一开始我就创建一个,谁来我都用这一个实例。
这里人家就要调优了,说你这个上来二话不说,先给我弄个实例。我不用,你还给我创建一个,多费地方。(Hungry : 真抠!!!能费多点点,况且你不用为什么还要写我出来。)我不管, 你得给我优化。
public class Hungry {
private static Hungry instance = new Hungry();
public static Hungry getInstance(){
/**
* 相关的业务逻辑
*/
return instance;
}
// 私有构造
}
3.Synchronized 使用synchronized
饿汉模式的优化来了,我加锁。嗯?锁这么多啊,那多不好啊。(⊙o⊙)…那还是再优化下下吧。
public class UseSynchronized {
private static UseSynchronize instance = null;
synchronized public static UseSynchronize getInstance(){
/**
* 相关的业务逻辑
*/
if(null == instance){
instance = new UseSynchronize();
}
return instance;
}
// 私有构造
}
4.DCL Double Check Lock
大哥大!我不锁这么多了,我就锁创建的时候,你的业务代码我不会锁了。那你为啥还给我弄个volatile呢?这里有一丢丢的小概率事件需要规避一下,先看代码!
public class DCL {
// 必须要添加volatile
private volatile static DCL instance = null;
public static DCL getInstance(){
/**
* 相关的业务逻辑
*/
if(null == instance){
synchronized (DCL.class){
if(null == instance){
instance = new DCL();
}
}
}
return instance;
}
// 私有构造
}
到底要规避什么问题呢?cpu的乱序执行!避免拿到半初始化的对象。移步下图:
在增加volatile时,会强制cpu顺序执行,不能对顺序进行调整。