懒汉模式相对饿汉模式来说大大减少了内存空间的消耗,但是存在线程安全问题。
public class LazySimpleSingleton {
private LazySimpleSingleton(){
}
//静态块,公共内存区域
private static LazySimpleSingleton lazy = null;
public static LazySimpleSingleton getInstance(){
if(lazy == null){
lazy = new LazySimpleSingleton();
}
return lazy;
}
}
public class ExectorThread implements Runnable{
@Override
public void run() {
LazySimpleSingleton singleton = LazySimpleSingleton.getInstance();
// ThreadLocalSingleton singleton = ThreadLocalSingleton.getInstance();
System.out.println(Thread.currentThread().getName() + ":" + singleton);
}
}
public class LazySimpleSingletonTest {
public static void main(String[] args) {
Thread t1 = new Thread(new ExectorThread());
Thread t2 = new Thread(new ExectorThread());
t1.start();
t2.start();
System.out.println("End");
}
}
每个断掉都需要右击断点,并点击Thread
然后开始调试
可以看到这里是有多个线程的
这个时候按F8(调到下一步)
然后不论是Thread-0还是Thread-1都是运行到了如图这里
然后分别选择Thread-0 Thread-1 分别按照以前以后进入,定位到这一行
在Thread-0中通过按F8跳转到return lazy,即已经有了lazy,如下图这个lazy是815
那么之前的Thread-1继续通过F8往下走的时候,也就不会再走if(lazy == null)
里面的内容了,而是直接返回之前创建好的815
然后分别将两个线程按F8至最后。
Thread-0和Thread-1都同时进入到如下这行代码,都还没有进行初始化
Thread-0走完,准备return816
Thread-1也走完,准备return
这个时候发现直接是return了817,给覆盖掉了
虽然,最后还是一样的,但是内部其实已经实例化了两次,只不过后面执行比较慢的线程把前面执行快的线程覆盖了
Thread-0和Thread-1都同时进入到如下这行代码,都还没有进行初始化
然后将Thread-0全部执行完
Thread-1全部执行完
这个时候就是两个不一样的了。
通过上面的三种可能,能够看到如果是同时进入的话,可能最后显示的是两个实例(如上可能三),也可能最后显示的一个实例(如上可能二,淡这只是一个假象),即只要是同时进入的都会创建两个实例。
之后一前一后进入的时候才会是一个实例。
synchronized 关键字
通过多线程断点的方式再次模拟一次
Thread-0还是进入到这里
Thread-1一开始是在这里的
这个时候Thread-1通过F8尝试进入到同步代码块
发现报错了,不支持的线程,不允许访问
仔细看下
Thread-1也因此变成了Monitor状态,Thread-0是Running状态。
只有当Thread-0执行完了之后,Thread-1才会变成Running状态。
那么我们让Thread-0走出同步代码块,发现Thread-1变成Running了
这个时候通过F8,发现已经有值了,所以跳过了lazy = new LazySimpleSingleton();
,直接进行return了之前Thread-0,new好的。
这个时候最后的结果才是没有障眼法的真正的为一个实例。
虽然在JDK1.6之后对synchronized性能优化了许多,但是还是不可避免的存在一定的性能问题。
因为这个synchronized可能会造成整个类的操作被锁住
因为它修饰的方法是被static修饰的
public class LazyDoubleCheckSingleton {
private volatile static LazyDoubleCheckSingleton lazy = null;
private LazyDoubleCheckSingleton(){
}
public static LazyDoubleCheckSingleton getInstance(){
if(lazy == null){
synchronized (LazyDoubleCheckSingleton.class){
if(lazy == null){
lazy = new LazyDoubleCheckSingleton();
//1.分配内存给这个对象
//2.初始化对象
//3.设置lazy指向刚分配的内存地址
//4.初次访问对象
}
}
}
return lazy;
}
}
因为synchronized关键字如果修饰静态方法的话,会将整个类锁住,所以将synchronized放在方法里面。
可是如果这么写的话
if(lazy == null){
synchronized (LazyDoubleCheckSingleton.class){
// if(lazy == null){
lazy = new LazyDoubleCheckSingleton();
//1.分配内存给这个对象
//2.初始化对象
//3.设置lazy指向刚分配的内存地址
//4.初次访问对象
// }
}
}
return lazy;
即没有里面的双重检查,会导致Thread-0在执行lazy = new LazyDoubleCheckSingleton();
的时候,Thread-1无法执行,但是,当Thread-0执行完这句话之后,Thread-1就能够进来同样执行这句话了,所以实际上还是创建了两次实例。
所以至此就很明了了,需要进行双重检测,if(lazy == null){}
总的来说就是为了减小开销、提升效率。
最里面的知道是为了保证实例的唯一性,但是最外层的判断是为什么呢?
那就来假设一下
代码如下
public static LazyDoubleCheckSingleton getInstance(){
synchronized (LazyDoubleCheckSingleton.class){
if(lazy == null){
lazy = new LazyDoubleCheckSingleton();
//1.分配内存给这个对象
//2.初始化对象
//3.设置lazy指向刚分配的内存地址
//4.初次访问对象
}
}
return lazy;
}
这意味着什么?没错里面的判断使得保证了实例的唯一性,但是因为外层没有判断,所以导致里面的synchronized相关代码都是无条件执行的,即每个线程执行到这里都需要获得一个内部锁,锁的获得、释放的开销(包括上下文切换、内存同步等)也就无条件的存在了。相反的加上不为null的判断之后,就能在一定程度上减少所有的线程都经过这里的可能,从而减少开销。
同时能够提升效率,假象线程一已经实例化了对象,此时线程二持有这把锁,线程三只能等待带线程二执行完,而如果有了外层的判断,线程三就不需要等待了直接返回lazy的值。
private volatile static LazyDoubleCheckSingleton lazy = null;
lazy = new LazyDoubleCheckSingleton();
//1.分配内存给这个对象
//2.初始化对象
//3.设置lazy指向刚分配的内存地址
//4.初次访问对象
上面的这行代码,其实在cpu中是执行了下面的四个操作,这里的2和3其实顺序是可能颠倒的,即指令重排问题。为了解决这个问题,需要在lazy前面加上volatile关键字。
package com.gupaoedu.vip.pattern.singleton.lazy;
//懒汉式单例
//这种形式兼顾饿汉式的内存浪费,也兼顾synchronized性能问题
//完美地屏蔽了这两个缺点
//史上最牛B的单例模式的实现方式
public class LazyInnerClassSingleton {
//默认使用LazyInnerClassGeneral的时候,会先初始化内部类
//如果没使用的话,内部类是不加载的
private LazyInnerClassSingleton(){
if(LazyHolder.LAZY != null){
throw new RuntimeException("不允许创建多个实例");
}
}
//每一个关键字都不是多余的
//static 是为了使单例的空间共享
//保证这个方法不会被重写,重载
public static final LazyInnerClassSingleton getInstance(){
//在返回结果以前,一定会先加载内部类
return LazyHolder.LAZY;
}
//默认不加载
private static class LazyHolder{
private static final LazyInnerClassSingleton LAZY = new LazyInnerClassSingleton();
}
}
全程没有使用synchronized关键字
当外面的类LazyInnerClassSingleton 加载的时候,会首先去加载内部类LazyHolder,内部类比外部类要优先加载。
这里注意内部类LazyHolder中的逻辑,默认是不执行的,猛地一看,这个内部类中是饿汉式的,但是只有当getInstance()去调用这个方法的时候才执行private static final LazyInnerClassSingleton LAZY = new LazyInnerClassSingleton();
,巧妙的利用了内部类的特性。
这也是性能最优的一种方式。
如果这里的构造方法是如下代码。
private LazyInnerClassSingleton(){
}
通过反射的方式,就要调用private的构造方法,也是可以的,这样的到的还是两个实例。
所以需要将构造方法改成
private LazyInnerClassSingleton(){
if(LazyHolder.LAZY != null){
throw new RuntimeException("不允许创建多个实例");
}
}
如果偷偷的用构造方法实例化的话,会抛出异常,从而防止了反射攻击。
import java.io.Serializable;
//反序列化时导致单例破坏
public class SeriableSingleton implements Serializable {
//序列化就是说把内存中的状态通过转换成字节码的形式
//从而转换一个IO流,写入到其他地方(可以是磁盘、网络IO)
//内存中状态给永久保存下来了
//反序列化
//讲已经持久化的字节码内容,转换为IO流
//通过IO流的读取,进而将读取的内容转换为Java对象
//在转换过程中会重新创建对象new
public final static SeriableSingleton INSTANCE = new SeriableSingleton();
private SeriableSingleton(){
}
public static SeriableSingleton getInstance(){
return INSTANCE;
}
}
package com.gupaoedu.vip.pattern.singleton.test;
import com.gupaoedu.vip.pattern.singleton.seriable.SeriableSingleton;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
public class SeriableSingletonTest {
public static void main(String[] args) {
SeriableSingleton s1 = null;
SeriableSingleton s2 = SeriableSingleton.getInstance();
FileOutputStream fos = null;
try {
fos = new FileOutputStream("SeriableSingleton.obj");
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(s2);
oos.flush();
oos.close();
FileInputStream fis = new FileInputStream("SeriableSingleton.obj");
ObjectInputStream ois = new ObjectInputStream(fis);
s1 = (SeriableSingleton)ois.readObject();
ois.close();
System.out.println(s1);
System.out.println(s2);
System.out.println(s1 == s2);
} catch (Exception e) {
e.printStackTrace();
}
}
}
上面的s1是先将类写入文件,再从类中读出来。
s2是公国getInstance()方法实例化。
最后的结果是不一样的。
SeriableSingleton 中重写readResolve方法
private Object readResolve(){
return INSTANCE;
}
即SeriableSingleton 完整代码
package com.gupaoedu.vip.pattern.singleton.seriable;
import java.io.Serializable;
//反序列化时导致单例破坏
public class SeriableSingleton implements Serializable {
//序列化就是说把内存中的状态通过转换成字节码的形式
//从而转换一个IO流,写入到其他地方(可以是磁盘、网络IO)
//内存中状态给永久保存下来了
//反序列化
//讲已经持久化的字节码内容,转换为IO流
//通过IO流的读取,进而将读取的内容转换为Java对象
//在转换过程中会重新创建对象new
public final static SeriableSingleton INSTANCE = new SeriableSingleton();
private SeriableSingleton(){
}
public static SeriableSingleton getInstance(){
return INSTANCE;
}
private Object readResolve(){
return INSTANCE;
}
}
为什么重写readResolve方法就可以了?
注意踏实怎么转化成这个类的?
首先通过readObject方法
再点到这个方法里面,往下
读取二进制的对象,点击去,往下
如果构造方法不为null,就初始化,虽然我们的构造方法是private的,但是只要有构造方法,就会初始化。
因为返回true,所以重新创建了对象,所以自然s1和s2是不相等的两个对象。
回到ObjectInputSteam类中的往下(在上面的desc.newInstance下面)
即虽然上面已经newInstance了,但是这里还是会判断是否有ReadResolve方法,如果有的话,就会执行这个ReadResolve方法。
至此,虽然已经new instance了,但是因为我们重写了jdk提供给我们的开放借口,所以真正返回的其实是单例类中的单例
private Object readResolve(){
return INSTANCE;
}
而这个方法在哪里?
通过反射获得名字为ReadResolve的方法。
重写readResolve方法,只不过是覆盖了反序列化出来的对象,还是创建了两次,放生在Jvm层面,相对来说比较安全,之前反序列化出来的对象被gc回收了。
package com.gupaoedu.vip.pattern.singleton.register;
//常量中去使用,常量不就是用来大家都能够共用吗?
//通常在通用API中使用
public enum EnumSingleton {
INSTANCE;
private Object data;
public Object getData() {
return data;
}
public void setData(Object data) {
this.data = data;
}
public static EnumSingleton getInstance(){
return INSTANCE;
}
}
public static void main(String[] args) {
try {
EnumSingleton instance1 = null;
EnumSingleton instance2 = EnumSingleton.getInstance();
instance2.setData(new Object());
FileOutputStream fos = new FileOutputStream("EnumSingleton.obj");
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(instance2);
oos.flush();
oos.close();
FileInputStream fis = new FileInputStream("EnumSingleton.obj");
ObjectInputStream ois = new ObjectInputStream(fis);
instance1 = (EnumSingleton) ois.readObject();
ois.close();
System.out.println(instance1.getData());
System.out.println(instance2.getData());
System.out.println(instance1.getData() == instance2.getData());
}catch (Exception e){
e.printStackTrace();
}
}
介绍:class反编译工具
下载地址:https://varaneckas.com/jad/
安装:解压到任意目录,解压后的到两个文件(jad.exe、Readme.txt)
配置环境变量:在path中添加jad.exe所在的目录(比如当前的jad.exe在F:)那就直接配置F:就好了
比如我的:
配置完之后需要重新启动cmd窗口然后在任意路径输入jad
因为是maven项目,在target文件下找到需要反编译的class文件,并复制路径
然后执行jad + filepath(不要有中文最好,我直接吧class文件拖放到了桌面)
最后生成的jad结尾的文件,这个文件在哪里呢?
如上入执行jad命令的时候,在哪里执行的就会存放咋哪里,如图我实在桌面执行的,所以就会存放在桌面
然后用notepad++等工具打开查看。
可以看到反编译的真实的代码,和我们idea中看到的是不一样的。
是怎么实现单例的?
注意静态代码块中的内容
static
{
INSTANCE = new EnumSingleton("INSTANCE", 0);
$VALUES = (new EnumSingleton[] {
INSTANCE
});
}
是没有无参的构造方法的,而且是在static静态代码块中进行初始化的,即饿汉式的写法,饿汉式的单例是线程安全的,那么回过头开始如何避免序列化破坏单例的?
同样回去继续跟源码
进入readEnum
通过jdk的valueOf方法加入class名字和枚举中的name确定一个值。
那么是通过什么来保证不会被反射攻击的呢?
如上图,通过反射的方法实例化,通过反编译代码,我们知道最终的代码是没有空参的构造方法的,这里模拟一下两个参数,颠倒这个newInstance方法里面
可以看到这里得到当前clazz的modifires(比如public等),如果得到的是enum,即枚举的话,直接就不实例化,直接就会抛出如上的异常,跟我们console中的到的一样。
避免单例模式被反射或者序列化攻击的话,最好通过枚举的方式进行解决,因为在jdk层面已经帮我们做的很好了。
当然通过重写ReadResolve方法的方式也行,但是最好还是通过枚举的方式。
《Effective Java》这本书中也是这么说的。