一、单例模式介绍
单例模式是23种设计模式中使用较多的一种,主要用来生成类的唯一实例。通过构造器私有使得外界无法通过构造器实例化Singleton类,要取得实例只能通过getInstance()方法。
常见的单例模式有几个实现方式,主要为懒汉式、饿汉式、静态内部类、枚举类、双重加锁检查等。以下是几种不同实现方式的简要样例,及使用场景对比
懒汉式
线程安全,调用效率不高,但是能延时加载
public class SingletonLazy {
//类初始化时,不初始化这个对象(延时加载,真正用的时候再创建)
private static SingletonLazy instance;
//构造器私有化
private SingletonLazy(){}
//方法同步,调用效率低
public static synchronized SingletonLazy getInstance(){
if(instance==null){
instance=new SingletonLazy();
}
return instance;
}
}
饿汉式
线程安全,调用效率高,但是不能延时加载
public class SingletonHunger{
private static SingletonLazy instance = new SingletonLazy();
private SingletonLazy(){}
private SingletonLazy getInstance(){
return this.instance;
}
}
静态内部类
线程安全,调用效率高,可以延时加载
public class SingletonInner {
private static class SingletonClassInstance{
private static final SingletonInner instance=new SingletonInner();
}
private SingletonInner(){}
public static SingletonInner getInstance(){
return SingletonClassInstance.instance;
}
}
枚举类
线程安全,调用效率高,不能延时加载,可以天然的防止反射和反序列化调用
public enum SingletonEnum {
//枚举元素本身就是单例
INSTANCE;
//添加自己需要的操作
public void singletonOperation(){
}
}
双重检查
线程安全的,延迟加载
但是必须注意instance必须用volatile来禁止指令重排序,防止JVM优化导致多线程下getInstance()获取未初始化完的空对象(JDK1.5后)
public class SingletonDCL {
//JDK1.5后,volatile用来禁止指令重排序
//防止因为JVM指令优化从而导致多线程下,线程B在getInstance()获得空对象
private volatile static SingletonDCL singletonDCLInstance;
private SingletonDCL() {
}
public static SingletonDCL getInstance() {
if (singletonDCLInstance == null) {
synchronized (SingletonDCL.class) {
if (singletonDCLInstance == null) {
singletonDCLInstance = new SingletonDCL();
}
}
}
return singletonDCLInstance;
}
}
二、实际工程实践
vCN-EM-Monitor网元粒度监控中,创建了两个线程池TaskDeleteThreadPool和DealMonitorDataThreadPool
先看TaskDeleteThreadPool
import com.google.common.util.concurrent.ThreadFactoryBuilder;
import lombok.extern.slf4j.Slf4j;
import java.util.concurrent.*;
/***
* 任务删除服务线程池
*/
@Slf4j
public class TaskDeleteThreadPool {
private static final int CORE_POOL_SIZE = 5;
private static final int MAXIMUN_POOL_SIZE = 5;
private static final long KEEP_ALIVE_TIME = 120L;
private static final int MAX_QUEUE_SIZE = 1000;
private static ThreadPoolExecutor executor;
private static TaskDeleteThreadPool instance = new TaskDeleteThreadPool(); //修改点1
public synchronized static TaskDeleteThreadPool getInstance() { //修改点2
if (instance == null) {
instance = new TaskDeleteThreadPool();
}
return instance;
}
private TaskDeleteThreadPool() {
init();
}
private void init() {
ThreadFactory namedThreadFactory = new ThreadFactoryBuilder().setNameFormat("MonitorDeleteTask-pool-%d").build();
executor = new ThreadPoolExecutor(CORE_POOL_SIZE, MAXIMUN_POOL_SIZE, KEEP_ALIVE_TIME, TimeUnit.SECONDS,
new LinkedBlockingQueue<Runnable>(MAX_QUEUE_SIZE), namedThreadFactory);
}
public void add(TaskDeleteService taskDeleteService) {
try {
executor.submit(taskDeleteService);
} catch (RejectedExecutionException e) {
log.warn("TaskDeleteThreadPool failed Rejected ={}", e.getMessage());
} catch (Exception e) {
log.warn("TaskDeleteThreadPool failed other Exception ={}", e.getMessage());
}
}
}
点评:
首先看修改点1,明显采用的是饿汉式,即类加载后该线程池实例就已经创建好了。
然后再看修改点2,又明显采用的是懒汉式的加锁检查。
修改建议:
如果明确使用饿汉式,则修改点2处的instance == null可以去除,直接返回this.instance;而且也不需要用synchronized加锁修饰
如果明确使用懒汉式,则修改点1处的new TaskDeleteThreadPool()可以去除,让实例的初始化延迟到getInstance()方法的if(instance == null)中实现(此时需要synchronized加锁)
再看DealMonitorDataThreadPool
import com.google.common.util.concurrent.ThreadFactoryBuilder;
import lombok.extern.slf4j.Slf4j;
import java.util.concurrent.*;
/***
* 网元粒度监控任务线程池
*/
@Slf4j
public class DealMonitorDataThreadPool {
private static final int CORE_POOL_SIZE = 5;
private static final int MAXIMUN_POOL_SIZE = 5;
private static final long KEEP_ALIVE_TIME = 120L;
private static final int MAX_QUEUE_SIZE = 1000;
private static ThreadPoolExecutor executor;
private volatile static DealMonitorDataThreadPool instance = new DealMonitorDataThreadPool(); //修改点1
public static DealMonitorDataThreadPool getInstance() {
if (instance == null) {
synchronized (DealMonitorDataThreadPool.class) {
if (instance == null) {
instance = new DealMonitorDataThreadPool();
}
}
}
return instance;
}
private DealMonitorDataThreadPool() {
init();
}
private void init() {
ThreadFactory namedThreadFactory = new ThreadFactoryBuilder().setNameFormat("MonitorDealData-pool-%d").build();
executor = new ThreadPoolExecutor(CORE_POOL_SIZE, MAXIMUN_POOL_SIZE, KEEP_ALIVE_TIME, TimeUnit.SECONDS,
new LinkedBlockingQueue<Runnable>(MAX_QUEUE_SIZE), namedThreadFactory);
}
public void add(DealMonitorDataService dealMonitorDataService) {
try {
executor.submit(dealMonitorDataService);
} catch (RejectedExecutionException e) {
log.warn("MonitorDealDataThreadPool failed Rejected ={}", e.getMessage());
} catch (Exception e) {
log.warn("MonitorDealDataThreadPool failed other Exception ={}", e.getMessage());
}
}
}
点评:
以上类主要用于创建单例的线程池,其中主要采用 双重检查机制 来保证线程池的单实例。
但是针对修改点1, private volatile static DealMonitorDataThreadPool instance = new DealMonitorDataThreadPool();
以上写法采用的是饿汉式,在类加载后该线程池实例就已经创建好了。那就没有必要通过 双重检查 来保证实例的唯一性。
修改建议:
修改为 private volatile static DealMonitorDataThreadPool instance; //延迟加载
getInstance()双重检查保留
三、总结
1、使用双重检查来延迟创建单例对象,对象必须用volatile关键字修饰,原因如下:
一般来讲,当初始化一个对象的时候,JVM的指令应该如下:
a. 内存分配
b. 初始化
c. 返回对象引用
这种方式产生的对象是一个完整的对象,可以正常使用。但是JAVA的无序写入可能会造成指令重排序,出现如下顺序:
a. 内存分配、
b. 返回对象引用
c. 初始化的顺序
这种情况下线程A执行到(//创建实例)就是singleton已经不是null,而是指向了堆上的一个对象,但是该对象却还没有完成初始化动作。当后续的线程B发现singleton不是null而直接使用的时候,就会出现意料之外空指针异常等问题。使用volatile能够禁止指令重排序(也保证可见性),防止出现此类线程安全问题。
2、单例模式虽然简单,但是实际工程实践中的使用频率非常高。在没有吃透原理前,就直接“生搬硬套地拷贝”到工程代码中,就会产生上述的问题。虽然以上这些“别扭的写法”似乎也并不会导致“线程安全”问题,但在实际运行中依然可能影响运行效率。在复杂系统中,任何一点的“效率瓶颈”都有可能被放大,最后产生未知的性能缺陷,在有追求的程序员眼里,这些是不被允许的。
Stay foolish, stay hungry。