🍓 简介：java系列技术分享(👉持续更新中…🔥)
🍓 初衷:一起学习、一起进步、坚持不懈
🍓 如果文章内容有误与您的想法不一致,欢迎大家在评论区指正🙏
🍓 希望这篇文章对你有所帮助,欢迎点赞 👍 收藏 ⭐留言 📝🍓 更多文章请点击
文章目录
- 一、未加锁的单例
- 二、加锁单例
- 三、双重检查锁
- 四、JVM的指令重排
- 五、总结
一、未加锁的单例
懒汉模式实现
public class Singleton {
private static Singleton instance;
private Singleton() {
}
public Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
这是一个最简单的单例模式，在单线程下运转良好。但在多线程下会出现明显的问题，可能会创建多个实例。
可以看到，当两个线程同时执行时，是有可能会创建多个实例的，这很明显不符合单例的要求。
二、加锁单例
public class Singleton {
private static Singleton instance;
private Singleton() {
}
public synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
与第一个示例唯一的区别是在方法上添加了synchronized关键字。这时，当多个线程进入该方法时，需要先获得锁才能进行执行。
-
通过在方法上添加synchronized关键字，看似完美的解决了多线程的问题，但却带了
性能问题。 -
我们知道使用锁会导致额外的性能开销，对于上面的单例模式，只有第一次创建时需要锁（防止创建多个实例），但
查询时是不需要锁的。 -
如果针对方法进行加锁，
每次查询也要承担加锁的性能损耗。
三、双重检查锁
public class Singleton {
private static Singleton instance;
private Singleton() {
}
public Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
-
缩小锁的范围；
-
锁之前先判断一下是不是null，如果不为null，说明已经实例化了，直接返回，没必要进行创建；
-
如果为null，进行加锁，然后再次判断是否为null。
为什么要再次判断？因为一个线程判断为null之后，另外一个线程可能已经创建了对象，所以在锁定之后，需要再次核实一下，真的为null，则进行对象创建。
改进之后，既保证了线程的安全性，又避免了锁导致的性能损失。问题到此结束了吗？并没有，继续往下看
四、JVM的指令重排
在JVM当中，编译器为了性能问题，会进行指令重排。
在上述代码中new Singleton()并不是原子操作，有可能会被编译器进行重排操作。
当线程A执行完步骤赋值操作，但还未执行对象初始化。此时，线程B进来了，在第一层判断时发现Instance已经有值了（实际上还未初始化），直接返回对应的值。那么，程序在使用这个未初始化的值时，便会出现错误。
针对此问题，可在instance上添加volatile关键字，使得instance在读、写操作前后都会插入内存屏障，避免重排序。
最终，单例模式实现如下：
public class Singleton {
private static volatile Singleton instance;
private Singleton() {
}
public Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
五、总结
- 未加锁单例模式使用，
会创建多个对象； - 方法上加锁，导致
性能下降； - 代码内局部加锁，双重判断，
既满足线程安全，又满足性能需求； - 单例模式特例：创建对象分多步，会出现指令重排现象，采用volatile进行避免指令重排；
