1. 单例模式应用场景
单例模式(Singleton Pattern)是指确保一个类在任何情况下都绝对只有一个实例,并提供一个全局访问点。单例模式是创建型模式。单例模式在现实生活中应用也非常广泛。 例如,国家主席、公司 CEO、部门经理等。在 J2EE 标准中,ServletContext、 ServletContextConfig 等;在 Spring 框架应用中 ApplicationContext;数据库的连接池也都是单例形式。
2. 饿汉式单例
饿汉式单例是在类加载的时候就立即初始化,并且创建单例对象。绝对线程安全,在线程还没出现以前就是实例化了,不可能存在访问安全问题。 饿汉式适用在单例对象较少的情况
- 优点:没有加任何的锁、执行效率比较高,在用户体验上来说,比懒汉式更好。
- 缺点:类加载的时候就初始化,不管用与不用都占着空间,浪费了内存。
package com.gupaoedu.vip.pattern.singleton.hungry;
/**
* 饿汉式单例模式三要素
* 1.构造方法私有
* 2.静态的获取单例的方法
* 3.实例在类加载还未被初始化的时候就创建了 private static final
* 写在静态块里面也可以
* 缺点:不管用不用,都实例化,会浪费内存空间===>改进:懒汉式单例
*/
public class HungrySingleton {
// private static final HungrySingleton hungrySingleton= new HungrySingleton();
private static final HungrySingleton hungrySingleton;
static {
hungrySingleton= new HungrySingleton();
}
private HungrySingleton(){}
public static HungrySingleton getInstance(){
return hungrySingleton;
}
}
3. 懒汉式单例
懒汉式单例的特点是:在外部需要使用的时候才进行实例化,代码如下:
package com.gupaoedu.vip.pattern.singleton.lazy;
/**
* 1.构造方法私有化
* 2.提供全局访问点
*/
public class LazySimpleSingleton {
private static LazySimpleSingleton lazy;
private LazySimpleSingleton(){}
public static LazySimpleSingleton getInstance(){
if(null == lazy) { //在这里加断点调试
lazy = new LazySimpleSingleton();
}
return lazy;
}
}
测试:
package com.gupaoedu.vip.pattern.singleton.lazy;
public class LazySimpleSingletonTest {
public static void main(String[] args) {
new Thread(new ExexutorThread()).start();
new Thread(new ExexutorThread()).start();
}
}
class ExexutorThread implements Runnable {
@Override
public void run() {
LazySimpleSingleton simpleSingleton = LazySimpleSingleton.getInstance();
System.out.println(Thread.currentThread().getName() + ":" + simpleSingleton);
}
}
很显然,单例被破坏了,具体破坏过程,可以参考IDEA环境下的多线程调试方式 一文
那么怎么去避免单例被破坏呢?其实很简单,加锁即可:
package com.gupaoedu.vip.pattern.singleton.lazy;
/**
* 1.构造方法私有化
* 2.提供全局访问点
*/
public class LazySimpleSingleton {
private static LazySimpleSingleton lazy;
private LazySimpleSingleton(){}
/* public static LazySimpleSingleton getInstance(){
if(null == lazy) { //在这里加断点调试
lazy = new LazySimpleSingleton();
}
return lazy;
}*/
public synchronized static LazySimpleSingleton getInstance() {
if (null == lazy) { //在这里加断点调试
lazy = new LazySimpleSingleton();
}
return lazy;
}
}
这时候再来调试,当其中一个线程执行并调用 getInstance()方法时,另一 个线程在调用 getInstance()方法,线程的状态由 RUNNING 变成了 MONITOR,出现阻 塞。直到第一个线程执行完,第二个线程才恢复 RUNNING 状态继续调用 getInstance() 方法。如下图所示:
线程安全的问题便解决了。但是,用 synchronized对getInstance() 加锁,在线程数量比较多情况下,如果 CPU 分配压力上升,会导致大批 量线程出现阻塞,从而导致程序运行性能大幅下降。那么,有没有一种更好的方式,既 兼顾线程安全又提升程序性能呢, 就是双重检查锁的单例模式了
4. 双重检查锁单例模式
package com.gupaoedu.vip.pattern.singleton.lazy;
public class LazyDoubleCheckSingleton {
//加上volatile关键字,保证线程可见性
private /*volatile*/ static LazyDoubleCheckSingleton lazy;
private LazyDoubleCheckSingleton(){}
//synchronized是一种类锁,在这里把加锁放到if里面去
public static LazyDoubleCheckSingleton getInstance(){
if(null == lazy) { //在这里加断点调试
synchronized(LazyDoubleCheckSingleton.class){
if(null == lazy) { //这里如果不加判断,第二个线程还是会有可能再new一次对象
lazy = new LazyDoubleCheckSingleton();
}
}
}
return lazy;
}
}
测试类:
package com.gupaoedu.vip.pattern.singleton.lazy;
public class LazyDoubleCheckSimpleSingletonTest {
public static void main(String[] args) {
Thread t1 = new Thread(new ExecutorThreadDoubleCheck());
Thread t2 = new Thread(new ExecutorThreadDoubleCheck());
t1.start();
t2.start();
System.out.println("Executor end"); //此处加断点
}
}
class ExecutorThreadDoubleCheck implements Runnable {
@Override
public void run() {
LazyDoubleCheckSingleton singleton = LazyDoubleCheckSingleton.getInstance(); //在这里 加断点
System.out.println(Thread.currentThread().getName() + singleton);
}
}
为什么双重加锁检查单例,要判断两次呢,我们把synchronized 锁住的代码块中的if判断去掉,debug调试2个线程,结果发现,还是会生成两个实例。为什么呢?如果没又里面一层的判断,会存在这样一种情况,第一个线程判断lazy为null,还未获得锁时,第二个线程也进入到外层的if判断,如果恰好此时第一个线程获得锁,那么第二个线程将等待,第一个线程执行完,产生一个实例,将锁释放,第二个线程获得锁将程序执行完并返回第二个实例,结果就是如下,产生了两个实例,单例依旧被破坏,因此内层的第二次判空不可缺少!
4.1.反射破坏双重检查锁单例
虽然双重检查锁单例模式一定程度上兼顾了线程安全和程序性能,但是依旧能被暴力反射破坏单例,运行下面的代码:
package com.gupaoedu.vip.pattern.singleton.lazy;
import java.lang.reflect.Constructor;
public class LazyDoubleCheckSingletonReflectTest {
public static void main(String[] args) throws Exception {
Class<LazyDoubleCheckSingleton> clazz = LazyDoubleCheckSingleton.class;
Constructor<LazyDoubleCheckSingleton> c = clazz.getDeclaredConstructor(null);
c.setAccessible(true); //强制访问
LazyDoubleCheckSingleton o1 = c.newInstance();
LazyDoubleCheckSingleton o2 = LazyDoubleCheckSingleton.getInstance();
System.out.println(o1);
System.out.println(o2);
System.out.println(o1 == o2); //结果为false ,说明单例被破坏,实例化了两次
}
}
可以看到,反射获取的实例跟getInstance()方法获取的不是同一个实例,说明反射确实能够破坏单例。
5. 静态内部类单例
用到 synchronized 关键字,总归是要上锁,对程序性能还是存在一定影响的。我们可以从类初始化角度来考虑,看下面代码,采用静态内部类的方式,这种形式兼顾饿汉式的内存浪费,也兼顾 synchronized 性能问题。内部类一定是要在方 法调用之前初始化,巧妙地避免了线程安全问题。
package com.gupaoedu.vip.pattern.singleton.lazy;
public class LazyInnerClassSingleton {
/**
* 即便使用了静态内部类,调用者仍可以通过反射机制以及序列化和反序列化来暴力 破坏单例,这里需要加判断来阻止
*/
private LazyInnerClassSingleton(){ }
/**
* 利用内部类的特性,JVM底层 的执行逻辑,避免了线程安全问题
* LazyHolder里面的逻辑需要等到外部方法调用时才执行,
* @return
*/
public static final LazyInnerClassSingleton getInstance(){
return LazyHolder.LAZY;
}
private static class LazyHolder{
private static final LazyInnerClassSingleton LAZY = new LazyInnerClassSingleton();
}
}
5.1 反射破坏内部类单例
通过暴力反射,静态内部类单例也是可以被破坏的,因为它的构造方法除了加上 private 以外没有做任何处 理。如果我们使用反射来调用其构造方法,然后,再调用 getInstance()方法,就会得到两个不同的实例。如下代码,执行返回false, 说明两个对象不是同一个实例。
package com.gupaoedu.vip.pattern.singleton.lazy;
import java.lang.reflect.Constructor;
public class LazyInnerClassSingletonReflectTest {
public static void main(String[] args) throws Exception {
Class<LazyInnerClassSingleton> clazz = LazyInnerClassSingleton.class;
Constructor<LazyInnerClassSingleton> c = clazz.getDeclaredConstructor(null);
c.setAccessible(true); //强制访问
LazyInnerClassSingleton o1 = c.newInstance();
LazyInnerClassSingleton o2 = c.newInstance();
// LazyInnerClassSingleton o2 = LazyInnerClassSingleton.getInstance();
System.out.println(o1 == o2); //结果为false ,,说明单例被破坏,实例化了两次
}
}
解决办法:在其构造方法中做一些限制,一旦出现重复创建,则直接抛出异常:
private LazyInnerClassSingleton(){
if (LazyHolder.LAZY != null){
throw new RuntimeException("不允构建多个实例!");
}
}
测试结果如下:
5.2 序列化破坏单例
当我们将一个单例对象创建好,有时候需要将对象序列化然后写入到磁盘,下次使用时 再从磁盘中读取到对象,反序列化转化为内存对象。反序列化后的对象会重新分配内存, 即重新创建。那如果序列化的目标的对象为单例对象,就破坏了单例。写一个饿汉式单例,然后测试序列化破坏单例:
package com.gupaoedu.vip.pattern.singleton.seriable;
import java.io.Serializable;
public class SerializableSingleton implements Serializable {
private static final SerializableSingleton INSTANCE = new SerializableSingleton();//饿汉式单例
private SerializableSingleton(){ }
public static SerializableSingleton getInstance(){
return INSTANCE;
}
}
测试类:
package com.gupaoedu.vip.pattern.singleton.seriable;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
public class SerializableSingletonTest {
public static void main(String[] args) {
SerializableSingleton s1 = null;
SerializableSingleton s2 = SerializableSingleton.getInstance();
FileOutputStream fos = null;
try {
fos = new FileOutputStream("SerializableSingleton1.obj")
;
ObjectOutputStream oos = new ObjectOutputStream(fos);
//序列化,写入磁盘
oos.writeObject(s2);
oos.flush();
oos.close();
FileInputStream fis = new FileInputStream("SerializableSingleton1.obj");
ObjectInputStream ois = new ObjectInputStream(fis);
//反序列化,从磁盘读取并转换为Java对象
s1 = (SerializableSingleton)ois.readObject();
System.out.println(s1);
System.out.println(s2);
System.out.println(s1 == s2);
} catch (Exception e){
e.printStackTrace();
}
}
}
结果说明,序列化也是会破坏单例的:
解决办法:重写readResolve()方法
package com.gupaoedu.vip.pattern.singleton.seriable;
import java.io.Serializable;
public class SerializableSingleton implements Serializable {
private static final SerializableSingleton INSTANCE = new SerializableSingleton();//饿汉式单例
private SerializableSingleton(){ }
public static SerializableSingleton getInstance(){
return INSTANCE;
}
//重写readResolve()方法只不过是覆盖了反序列号出来的对象,还是创建了2次,发生在JVM层面,之前反序列化出来的对象会被GC
private Object readResolve(){
return INSTANCE;
}
}
结果如下:
分析。从ois.readObject();入手
private Object readObject0(boolean unshared) throws IOException {
boolean oldMode = bin.getBlockDataMode();
if (oldMode) {
int remain = bin.currentBlockRemaining();
if (remain > 0) {
throw new OptionalDataException(remain);
} else if (defaultDataEnd) {
/*
* Fix for 4360508: stream is currently at the end of a field
* value block written via default serialization; since there
* is no terminating TC_ENDBLOCKDATA tag, simulate
* end-of-custom-data behavior explicitly.
*/
throw new OptionalDataException(true);
}
bin.setBlockDataMode(false);
}
byte tc;
while ((tc = bin.peekByte()) == TC_RESET) {
bin.readByte();
handleReset();
}
depth++;
totalObjectRefs++;
try {
switch (tc) {
case TC_NULL:
return readNull();
case TC_REFERENCE:
return readHandle(unshared);
case TC_CLASS:
return readClass(unshared);
case TC_CLASSDESC:
case TC_PROXYCLASSDESC:
return readClassDesc(unshared);
case TC_STRING:
case TC_LONGSTRING:
return checkResolve(readString(unshared));
case TC_ARRAY:
return checkResolve(readArray(unshared));
case TC_ENUM:
return checkResolve(readEnum(unshared));
case TC_OBJECT:
return checkResolve(readOrdinaryObject(unshared));
case TC_EXCEPTION:
IOException ex = readFatalException();
throw new WriteAbortedException("writing aborted", ex);
case TC_BLOCKDATA:
case TC_BLOCKDATALONG:
if (oldMode) {
bin.setBlockDataMode(true);
bin.peek(); // force header read
throw new OptionalDataException(
bin.currentBlockRemaining());
} else {
throw new StreamCorruptedException(
"unexpected block data");
}
case TC_ENDBLOCKDATA:
if (oldMode) {
throw new OptionalDataException(true);
} else {
throw new StreamCorruptedException(
"unexpected end of block data");
}
default:
throw new StreamCorruptedException(
String.format("invalid type code: %02X", tc));
}
} finally {
depth--;
bin.setBlockDataMode(oldMode);
}
上面代码中有一个分支
显然是有构造方法的,不管这个构造方法是私有还是公有,都会初始化
判断如果有readResolve方法,就调用该方法,那么可以在readResolve方法里面直接返回我们之前创建好的实例即可
这样设计是JDK考虑到单例被破坏的情况,是一种亡羊补牢的方式,重写readResolve()方法只不过是覆盖了反序列号出来的对象,实际上还是创建了2次,但是发生在JVM层面,相对来说比较安全,之前反序列化出来的对象会被GC。