面试官真是搞笑!让实现线程安全的单例,又不让使用synchronized!
共 3778字,需浏览 8分钟
·
2020-05-12 23:22
单例模式,是Java中比较常见的一个设计模式,也是我在面试时经常会问到的一个问题。
经过我的初步统计,基本上有60%左右的人可以说出2-4种单例的实现方式,有40%左右的人可以说出5-6种单例的实现方式,只有20%左右的人能够说出7种单例的实现。
而只有不到1%的人能够说出7种以上的单例实现。
其实,作为面试官,我大多数情况下之所以问单例模式,是因为这个题目可以问到很多知识点。
比如线程安全、类加载机制、synchronized的原理、volatile的原理、指令重排与内存屏障、枚举的实现、反射与单例模式、序列化如何破坏单例、CAS、CAS的ABA问题、Threadlocal等知识。
一般情况下,只需要从单例开始问起,大概就可以完成一场面试的整个流程,把我想问的东西都问完,可以比较全面的了解一个面试者的水平。
以下,是一次面试现场的还原,从单例模式开始:
Q:你知道怎么不使用synchronized和lock实现一个线程安全的单例吗?A:我知道,可以使用"静态内部类"实现。
静态内部类实现单例模式:
public class Singleton { private static class SingletonHolder { private static final Singleton INSTANCE = new Singleton(); } private Singleton (){} public static final Singleton getInstance() { return SingletonHolder.INSTANCE; } }
Q:除了静态内部类还会其他的方式吗?A:还有就是两种饿汉模式。
饿汉实现单例模式:
public class Singleton {
private static Singleton instance = new Singleton();
private Singleton (){}
public static Singleton getInstance() {
return instance;
}
}
饿汉变种实现单例模式:
public class Singleton {
private Singleton instance = null;
static {
instance = new Singleton();
}
private Singleton (){}
public static Singleton getInstance() {
return this.instance;
}
}
Q:那你上面提到的几种都是线程安全的吗?A:是线程安全的Q:那是如何做到线程安全的呢?A:应该是因为我使用了static,然后类加载的时候就线程安全了吧?Q:其实你说的并不完全对,因为以上几种虽然没有直接使用synchronized,但是也是间接用到了。(这里面根据回答情况会朝两个不同的方向展开:1、类加载机制、模块化等;2、继续深入问单例模式)
类加载过程的线程安全性保证
以上的静态内部类、饿汉等模式均是通过定义静态的成员变量,以保证单例对象可以在类初始化的过程中被实例化。
这其实是利用了ClassLoader的线程安全机制。ClassLoader的loadClass方法在加载类的时候使用了synchronized关键字。
所以, 除非被重写,这个方法默认在整个装载过程中都是线程安全的。所以在类加载过程中对象的创建也是线程安全的。
Q:那还回到刚开始的问题,你知道怎么不使用synchronized和lock实现一个线程安全的单例吗?(并不是故意穷追不舍,而是希望能可以引发面试者的更多思考)A:额、、、那枚举吧,枚举也可以实现单例。
枚举实现单例模式:
public enum Singleton {
INSTANCE;
public void whateverMethod() {
}
}
Q:那你知道枚举单例的原理吗?如何保证线程安全的呢?
枚举其实底层是依赖Enum类实现的,这个类的成员变量都是static类型的,并且在静态代码块中实例化的,和饿汉有点像, 所以他天然是线程安全的。
Q:所以,枚举其实也是借助了synchronized的,那你知道哪种方式可以完全不使用synchronized的吗?A:en....我想想Q:(过了一会他好像没有思路)你知道CAS吗?使用CAS可以实现单例吗?(面试中,如果面试者对于锁比较了解的话,那我大多数情况下都会继续朝两个方向深入问:1、锁的实现原理;2、非锁,如CAS、ThreadLocal等)A:哦,我知道,CAS是一项乐观锁技术,当多个线程尝试使用CAS同时更新一个变量时,只有其中一个线程能更新成功。
借助CAS(AtomicReference)实现单例模式:
Q:使用CAS实现的单例有没有什么优缺点呀?A:用CAS的好处在于不需要使用传统的锁机制来保证线程安全,CAS是一种基于忙等待的算法,依赖底层硬件的实现,相对于锁它没有线程切换和阻塞的额外消耗,可以支持较大的并行度。Q:你说的好像是优点?那缺点呢?public class Singleton {
private static final AtomicReference
INSTANCE = new AtomicReference ();
private Singleton() {}
public static Singleton getInstance() {
for (;;) {
Singleton singleton = INSTANCE.get();
if (null != singleton) {
return singleton;
}
singleton = new Singleton();
if (INSTANCE.compareAndSet(null, singleton)) {
return singleton;
}
}
}
}
CAS实现的单例的缺点
CAS的一个重要缺点在于如果忙等待一直执行不成功(一直在死循环中),会对CPU造成较大的执行开销。
另外,代码中,如果N个线程同时执行到 singleton = new Singleton();的时候,会有大量对象被创建,可能导致内存溢出。
Q:好的,除了使用CAS以外,你还知道有什么办法可以不使用synchronized实现单例吗?A:这回真的不太知道了。Q:(那我再提醒他一下吧)可以考虑下ThreadLocal,看看能不能实现?(面试者没有思路的时候,我几乎都会先做一下提醒,实在没有思路再换下一个问题)A:ThreadLocal?这也可以吗?Q:你先说下你理解的ThreadLocal是什么吧(通过他的回答,貌似对这个思路有些疑惑,不着急。先问一个简单的问题,让面试者放松一下,找找自信,然后再继续问)ThreadLoacal
ThreadLocal会为每一个线程提供一个独立的变量副本,从而隔离了多个线程对数据的访问冲突。对于多线程资源共享的问题,同步机制(synchronized)采用了“以时间换空间”的方式,而ThreadLocal采用了“以空间换时间”的方式。
同步机制仅提供一份变量,让不同的线程排队访问,而ThreadLocal为每一个线程都提供了一份变量,因此可以同时访问而互不影响。
Q:那理论上是不是可以使用ThreadLocal来实现单例呢?A:应该也是可行的。使用ThreadLocal实现单例模式:
public class Singleton {
private static final ThreadLocal
singleton = new ThreadLocal
() { @Override
protected Singleton initialValue() {
return new Singleton();
}
};
public static Singleton getInstance() {
return singleton.get();
}
private Singleton() {}
}
Q:嗯嗯,好的,那有关单例模式的实现的问题我就问的差不多了。(ThreadLocal这种写法主要是考察面试者对于ThreadLocal的理解,以及是否可以把知识活学活用,但是实际上,这种所谓的"单例",其实失去了单例的意义...)(但是说实话,能回答到这一题的人很少,大多数面试者基本上在前面几道题就已经没有思路了,大多数情况下根本不会问到这个问题就要改方向了)A:(心中窃喜)嗯嗯,学习到很多,感谢Q:那...你知道如何破坏单例吗?(单例问题,必问的一个。通过这个引申到序列化和反射的相关知识)A:(额....)
长按关注,还原真实面试现场