采取一定的办法保证在整个软件系统中,确保对于某个类只能存在一个实例。
单例模式有如下三个特点:
①、单例类只能有一个实例
②、单例类必须自己创建自己的实例
③、单例类必须提供外界获取这个实例的方法
2、单例类的设计思想(Singleton)
①、必须将构造器私有化,外界不能创建这个类的实例。
public class Singleton {
private Singleton(){}
}
②、单例类必须自己创建自己的实例,不能允许在类的外部修改内部创建的实例。
比如将这个实例用 private 声明。为了外界能访问到这个实例,我们还必须提供 getInstance 方法得到这个实例。因为外界不能new这个类,所以我们必须用static来修饰字段和方法。
private static Singleton singleton = new Singleton();
public static Singleton getInstance(){
return singleton;
}
③、是否支持延迟加载?
有些情况下,创建某个实例耗时长,占用资源多,用的时候也少,我们会考虑在用到的时候才会去创建,这就是延迟加载(懒加载)。
但有些情况,按照 fail-fast 的设计原则(有问题及早暴露),比如某个实例占用资源很多,如果延迟加载,会在程序运行一段时间后OOM,如果在程序启动的时候就创建这个实例(饿汉式),我们就可以立即去修复,不会导致程序运行之后的系统奔溃。
所以,是否支持延迟加载需要结合实际情况考虑。
④、保证线程安全
这个是一定要考虑的,如果你写的单例类存在线程安全问题,那就是伪单例了。
3、单例类的几种实现方式
3.1 单例模式之饿汉模式
public class Singleton {
private Singleton(){}
private static Singleton singleton = new Singleton();
public static Singleton getInstance(){
return singleton;
}
}
测试:
public static void main(String[] args) {
Singleton s1 = Singleton.getInstance();
Singleton s2 = Singleton.getInstance();
System.out.println(s1.equals(s2));
}
这种模式在类加载的时候实例singleton就已经创建并初始化好了,所以是线程安全的。
缺点:
1、不过这种模式不支持延迟加载;
2、有可能这个实例化过程很长,那么就会加大类装载的时间;
3、有可能这个实例现阶段根本用不到,那么创建了这个实例,也会浪费内存。
但是还是我们前面说的,是否支持延迟加载,需要结合实际情况考虑。
3.2 单例模式之懒汉模式(线程不安全)
public class Singleton {
private Singleton(){}
private static Singleton singleton = null;
public static Singleton getInstance(){
if(singleton == null){
singleton = new Singleton();
}
return singleton;
}
}
这种方法达到了 lazy-loading 的效果,即我们在第一次需要得到这个单例的时候,才会去创建它的实例,以后再需要就可以不用创建,直接获取了。但是这种设计在多线程的情况下是不安全的。
我们可以创建两个线程来看看这种情况:
public class ThreadSingleton extends Thread{
@Override
public void run() {
try {
System.out.println(Singleton.getInstance());
} catch (Exception e) {
e.printStackTrace();
}
}
public static void main(String[] args) {
ThreadSingleton s1 = new ThreadSingleton();
s1.start();
ThreadSingleton s2 = new ThreadSingleton();
s2.start();
}
}
很明显:最后输出结果的两个实例是不同的。
这便是线程安全问题。
那么怎么解决这个问题呢?
参考这篇博客:Java多线程同步:http://www.cnblogs.com/ysocean/p/6883729.html
3.3 单例模式之懒汉模式(线程安全)
这里我们采用同步代码块来达到线程安全
public class Singleton {
private Singleton(){}
private static Singleton singleton = null;
public static Singleton getInstance() throws Exception{
synchronized (Singleton.class) {
if(singleton == null){
singleton = new Singleton();
}
}
return singleton;
}
}
我们给 getInstance() 方法创建实例时加了一把锁 synchronzed,这样会导致这个方法的并发为1,相当于串行操作,如果这个单例在实际项目中会频繁被调用,那就会频繁加锁,释放锁,会有性能瓶颈,不推荐此种方式。
3.4 单例模式之懒汉模式(线程安全)–双重校验锁
分析:上面的例子我们可以看到,synchronized 其实将方法内部的所有语句都已经包括了,每一个进来的线程都要单独进入同步代码块,判断实例是否存在,这就造成了性能的浪费。那么我们可以想到,其实在第一次已经创建了实例的情况下,后面再获取实例的时候,可不可以不进入这个同步代码块?
public class Singleton {
private Singleton(){}
private static Singleton singleton = null;
public static Singleton getInstance() throws Exception{
if(singleton == null){
synchronized (Singleton.class) {
if(singleton == null){
singleton = new Singleton();
}
}
}
return singleton;
}
}
以上的真的完美解决了单例模式吗?其实并没有,请看下面:
3.5 单例模式之最终版
我们知道编译就是将源代码翻译成机械码的过程,而Java虚拟机的目标代码不是本地机器码,而是虚拟机代码。编译原理里面有个过程是编译优化,就是指在不改变原来语义的情况下,通过调整语句的顺序,来让程序运行的更快,这个过程称为 reorder。
JVM 只是一个标准,它并没有规定有关编译器优化的内容,也就是说,JVM可以自由的实现编译器优化。
那么我们来再来考虑一下,创建一个变量需要哪些步骤?
①、申请一块内存,调用构造方法进行初始化
②、分配一个指针指向该内存
而这两步谁先谁后呢?
也就是存在这样一种情况:
1.先开辟一块内存,
2.然后分配一个指针指向该内存,
3.最后调用构造方法进行初始化。
那么针对单例模式的设计,就会存在这样一个问题:线程A开始创建Singleton的实例,此时线程B已经调用了 getInstance的()方法,首先判断 instance 是否为 null。而我们上面说的那种模型, A 已经把 instance 指向了那块内存,只是还没来得及调用构造方法进行初始化,因此 B 检测到 instance 不为 null,于是直接把 instance 返回了。那么问题出现了:尽管 instance 不为 null,但是 A 并没有构造完成,就像一套房子已经给了你钥匙,但是里面还没有装修,你并不能住进去。
解决方案:使用 volatile 关键字修饰 instance
我们知道在当前的Java内存模型下,线程可以把变量保存在本地内存(比如机器的寄存器)中,而不是直接在主存中进行读写。这就可能造成一个线程在主存中修改了一个变量的值,而另外一个线程还继续使用它在寄存器中的变量值的拷贝,造成数据的不一致。
volatile修饰的成员变量在每次被线程访问时,都强迫从共享内存中重读该成员变量的值。
而且,当成员变量发生变化时,强迫线程将变化值回写到共享内存。
这样在任何时刻,两个不同的线程总是看到某个成员变量的同一个值。
public class Singleton {
private static volatile Singleton singleton = null;
private Singleton(){}
public static Singleton getInstance() throws Exception{
if(singleton == null){
synchronized (Singleton.class) {
if(singleton == null){
singleton = new Singleton();
}
}
}
return singleton;
}
}
到此我们完美的解决了单例模式的问题。但是 volatile 关键字是 JDK1.5 才有的,也就是 JDK1.5 之前是不能这样用的
上面我们说要加关键字 volatile ,禁止指令重排,防止单例对象new 出来后,并且赋值给 singleton,但是还没来得及初始化这个问题。
现在高版本的 Java(JDK9) 已经在 JDK 内部实现中解决了这个问题,把对象的 new 操作和初始化操作设计为原子操作。
相关参考链接:
https://shipilev.net/blog/2014/safe-public-construction
https://chriswhocodes.com/vm-options-explorer.html
3.7 单例模式之枚举类
public enum Singleton{
INSTANCE;
private Singleton(){}
}
通过Java枚举类的自身特性,保证实例创建的线程安全和唯一性。
3.8 单例模式之静态内部类
public class InnerSingleton {
private InnerSingleton() {}
static class Inner {
static InnerSingleton instance = new InnerSingleton();
}
public static InnerSingleton getInstance() {
return Inner.instance;
}
public static void main(String[] args) {
System.out.println(InnerSingleton.getInstance() == InnerSingleton.getInstance());
System.out.println(InnerSingleton.getInstance().equals(InnerSingleton.getInstance()));
}
}
4、单例模式的应用
单例模式在实际项目中有啥用呢?
还是根据其核心概念,某个数据在系统中只能存在一份,就可以设计为单例。
1、windows系统的回收站,我们能在任何盘符删除数据,但是最后都是到了回收站中
2、网站的计数器,不采用单例模式,很难实现同步;
3、数据库连接池,可以节省打开或关闭数据库连接所引起的效率损耗,用单例模式来维护,可以大大降低这种损耗。当然对于海量数据系统,会存在多个数据库连接池,比如一个能够快速执行SQL的连接池,还有一个是慢SQL,如果都放在一个池里面,会导致慢SQL执行的时候,长时间占用数据库连接资源,导致其他SQL请求无法响应。
4、系统的配置信息类,通常只存在一个。