其他分享
首页 > 其他分享> > [设计模式]单例模式

[设计模式]单例模式

作者:互联网

 

单例模式

本章笔记的内容主要参考《设计模式之美》

核心问题

<aside> ❓ 1.为什么要使用单例? 2.单例存在的问题? 3.单例与静态类的区别? 4.替代方案?

</aside>

为什么要使用单例模式

/在很多场景中,我们需要一些可以共享的对象,来统一操作一些资源。若此时,产生了多个实例,则这些原本应该共享的资源,会产生冲突或覆盖的现象。

举个例子,比如日志记录类。一般来说,日志纪录类会像固定的文件中输出日志结果,此时若使用多个实例进行这一操作,对于文件内容的write操作可能会出现覆盖的现象。当然,这种情况下可以使用类级的锁来保证正确性,但相比而言,单例是一种更节约资源的做法。另外,在业务系统中,涉及到如配置、唯一ID生成器这样的需求,一般也会使用单例模式。实际上,在Spring中管理的Bean对象都是基于单例模式的。

几种实现单例模式的方式

1.饿汉模式

public class IdGenerator {
	private AtomicLong id = new AtomicLong(0);
	private static final IdGenerator instance = new IdGenerator();
	private IdGenerator() {}
	public static IdGenerator getInstance() {
		return instance;
	}
	public long getId() {
		return id.incrementAndGet();
	}
}

2.懒汉模式

基础版本

public class IdGenerator {
	private AtomicLong id = new AtomicLong(0);
	private static IdGenerator instance;
	private IdGenerator() {}
	public static synchronized IdGenerator getInstance() {
		if (instance == null) {
		instance = new IdGenerator();
		}
		return instance;
	}
	public long getId() {
		return id.incrementAndGet();
	}
}

基础版本中使用了对方法加锁的方式,会极大的影响性能,不支持高并发。

双重检测

public class IdGenerator {
	private AtomicLong id = new AtomicLong(0);
	private static IdGenerator instance;
	private IdGenerator() {}
	public static synchronized IdGenerator getInstance() {
		if (instance == null) {
		instance = new IdGenerator();
		}
		return instance;
	}
	public long getId() {
		return id.incrementAndGet();
	}
}

实际上大多数的实现中,还会给单例类上声明volatile关键字,来避免new动作非原子性导致的问题。具体的可以参考:

The "Double-Checked Locking is Broken" Declaration

实际上这个问题在高版本的JDK中已经做了相应的原子化处理,即使不使用volatile,也能保证正确性。

静态内部类

public class IdGenerator {
	private AtomicLong id = new AtomicLong(0);
	private IdGenerator() {}
	private static class SingletonHolder{
		private static final IdGenerator instance = new IdGenerator();
	}
	public static IdGenerator getInstance() {
		return SingletonHolder.instance;
	}
	public long getId() {
		return id.incrementAndGet();
	}
}

使用了一种简单的方式,达到了懒加载和线程安全的目的。线程安全由JVM在初始化静态内部类时保证。

枚举

还可以使用枚举的方式来实现单例,在此不再赘述。

单例存在的问题

由于单例隐藏了初始化的细节,因此在初始化时,往往使用了硬编码的方式,这其实是一种反模式。在后续维护中,若业务需求发生了变化,相应的逻辑变更会相对困难。这里引用一个《设计模式之美》中的例子:

在系统设计初期,我们觉得系统中只应该有一个数据库连接池,这样能方便我们控制对数据 库连接资源的消耗。所以,我们把数据库连接池类设计成了单例类。但之后我们发现,系统 中有些 SQL 语句运行得非常慢。这些 SQL 语句在执行的时候,长时间占用数据库连接资 源,导致其他 SQL 请求无法响应。为了解决这个问题,我们希望将慢 SQL 与其他 SQL 隔 离开来执行。为了实现这样的目的,我们可以在系统中创建两个数据库连接池,慢 SQL 独 享一个数据库连接池,其他 SQL 独享另外一个数据库连接池,这样就能避免慢 SQL 影响到 其他 SQL 的执行。

另外,单例模式的可测试性不高这也是因为代码中存在较多的硬编码,导致一些输入难以mock测试

单例的语义

在讨论单例模式时,我们会强调其唯一性。但在不同的前提条件下,唯一性的语义是不同的,在默认的语境中,单例模式指的是在同一个进程中,一个类仅有一个对象。当然这个前提条件可能会因为业务落地的实际场景发生变化。

线程中的唯一性

我们如何实现一个类在一个线程中的唯一性?实际上可以直接使用Java中的ThreadLocal类帮助我们实现,或者我们也可以自己在类中定义一个静态的ConcurrentHashMap,并使用线程id为Key,不同的实例为Value进行实现。

分布式环境下的唯一性

那么,在分布式多节点的环境下,如何保证实例的唯一性呢?通常的做法是,使用分布式文件系统,创建一个多节点共享的文件(该实例的本质是唯一的文件)。我们在创建、修改、读取实例时,我们总是从文件中反序列化得到实例,然后进行操作,最后将实例重新序列化回文件。这样就可以在不同的节点上,保证实例的唯一性。

参考文献

1.《设计模式之美》
2.双重检测
3.Reality Check, Douglas C. Schmidt, C++ Report, SIGS, Vol. 8, No. 3, March 1996.

标签:IdGenerator,private,instance,模式,单例,SQL,设计模式,public
来源: https://www.cnblogs.com/xy1997/p/16634509.html