后端面试常见问题|单例模式推荐实现

工作中发现很多同学的单例模式写法不尽相同,高下立判,这也是后端面试的常见问题(至少鱼皮手写过不止一次)。
单例模式又分为懒汉式和饿汉式,这里分享下两种方式的传统实现及优化后的推荐实现(本来想叫“最佳实现”,但网上实现方式太多,比如乐观锁、枚举类等等,就不给自己留坑了)。

懒汉式单例:

特点:当需要使用对象的时候才进行实例化,需要考虑线程安全问题(防止并发访问时生成多个实例),因此需加锁,用时间换空间。

传统实现

class Singleton{
    // 私有构造函数
    private Singleton() {}

    private static Singleton obj;

    // 加锁保证obj只实例化一次,时间换空间
    public static synchronized Singleton getInstance(){
        if (obj == null) {
            obj = new Singleton();
        }
        return obj;
    }
}

优化实现

传统实现方式中,每次获取实例都要被synchronized关键字串行化(即使已经生成了实例)。
而我们加锁的目的是为了防止生成多个实例,因此只需对生成实例的代码加锁,生成实例后,可支持并发访问,提高了性能。
代码如下:
class Singleton {
    // 私有构造函数
    private Singleton() {}
    // 最后解释volatile关键字
    private volatile static Singleton obj;

    public static Singleton getInstance(){
        // 已有实例则直接返回,不走锁
        if (obj == null) {
            // 仅在没生成实例时加锁控制,使并发访问串行化
            synchronized (Singleton.class) {
                // 多个线程会按序执行到此处,需要再次检查是否已实例化
                if (obj == null) {
                    obj = new Singleton();
                }
            }
        }
        return obj;
    }
}
由于检查了两次对象是否已实例化,该方法又称“双检锁”,能够同时保证性能及线程安全。

饿汉式单例:

特点:类加载时便实例化对象,拿空间换时间

传统实现

class Singleton{
    // 私有构造函数
    private Singleton() {}
    // 类加载时就实例化对象
    private static Singleton obj = new Singleton();
    
    public static Singleton getInstance(){
        return obj;
    }
}

优化实现

传统实现方式中,由于类加载时就实例化对象,因此当我们调用静态方法时,也会进行实例化,从而导致空间的浪费。
由于静态内部类中的对象不会默认加载,直到调用了该内部类的方法,因此可用静态内部类封装静态实例变量。
代码如下:
class Singleton{
    // 私有构造函数
    private Singleton() {}

    // 静态内部类
    private static class SingletonHolder {
        private static Singleton instance = new Singleton();
    }
    public static Singleton getInstance(){
        return SingletonHolder.instance;
    }
}
推荐这种实现,利用static保证线程安全,利用静态内部类节约了空间,实现lazy-loading。

补充下对懒汉式单例volatile关键字的解释(感谢评论指出的错误):实例的声明有一个voliate关键字,不添加可能出现getInstance为null的情况。
因为new对象不是原子操作,会被编译成如下三条指令:
1. 给实例分配内存
2. 初始化实例的构造
3. 将实际对象指向分配的内存空间(此时实例已经不为空)
正常的思路是123一定按序执行。
但事实时java会进行指令重排序(出自百度:JVM根据处理器的特性,充分利用多级缓存,多核等进行适当的指令重排序,使程序在保证业务运行的同时,充分利用CPU的执行特点,最大的发挥机器的性能)。即jvm执行上面三条指令的时,可能按照132执行。如此当13执行完,2还未执行,如果另外一个线程调用getInstance(),会在第一次判空时返回false(3已执行,对象不为空)然后直接返回实例。但此时2还没执行,实例并未完全初始化,会出现错误(引用逃逸)。注意:final字段不能保证初始化过程中的可见性,也无法禁止指令重排序!
voliate关键字可以禁止指令重排序,保证123顺序执行,能够解决问题。

最后补一张spring容器的单例实现,用局部变量避免指令重排序来提高性能(一种避免指令重排序的方法):

Spring还有一种单例的登记式注册表实现,有兴趣的同学自行搜索即可,不做展开。
#Java#
全部评论
以前我面试喜欢故意不写禁用指令重排序,就等面试官问"你这样会不会还有什么问题"然后再说的,奈何很多面试官就直接过了😂
1 回复 分享
发布于 2020-01-10 09:51
提醒一下,你的双检锁有问题,要加volatile 才能正在意义上的线程安全
点赞 回复 分享
发布于 2020-01-10 09:14
老哥,饿汉优化里说的空间浪费是咋回事😭
点赞 回复 分享
发布于 2020-01-10 09:07

相关推荐

05-29 19:11
已编辑
北方民族大学 Java
😭😭😭😭本人26届双非本,后端选手。从25年秋招开始,一直到春招5月份,一共面了12次字节。可以说后面能继续投递面上字节大概率是因为前面一直累计的面评还不错,但是最终的结果往往不尽如人意,黄梁一梦。timeline:如标题,总共面了12次字节,4个不同的岗位。第一次:抖音生活服务测开二面完排序挂第二次:TikTok国际化电商测开三面完排序挂第三次:飞书后端安全团队三面完挂第四次:飞书后端偏基架团队三面完过,HR面完之后询问综合排序不推进。我知道像BAT这样的公司,双非本想拿到一张入场券有多难,也知道每次挂在排序/三面/HR面,那种差一步上岸又被打回原点的落差感有多磨人。可是最后一次字节的这个岗位,已经是5月中旬才开始面得了,春招末期的岗位,我本以为真的缺人,三面过的那天,我真的以为就差一步hr面就稳了,但是,最终的结果很遗憾,综合排序综合排序,不推进了。如果是技术能力的问题,我想也不会每一轮技术面给我通过。思来想去。难道真的就是因为我们双非有案底,所以最后的一切又算什么呢。付出这么多的时间精力,还是抵不过双非学历太差吗?既然如此一开始直接卡掉简历不用给面试不就行了嘛,每一轮面试都给我们生的希望,最后的最后又回到了那个必输的起点。12次字节,说不遗憾是假的,也无数次怀疑过自己:是不是我算法刷得还不够?是不是项目亮点讲得不够好?是不是学历就是一道跨不过去的坎?但回头看,这一年的秋招到春招,从面对面试官紧张到说话卡壳,到后来的从容面对,再到如今甚至能和面试官探讨AI&大模型技术的一些方案思路,我已经比去年的自己强太多了。可能字节于我,真的是一场盛大的单恋,拼尽全力奔赴,却还是没能收到想要的回应。前路漫漫,字节的梦碎了,但我的路还在继续,希望下一站,会有属于我的一场徐风。
不愿吃饼的山羊很友好:你的心理素质是真的强大,如果是我碰到这样都会疯了
点赞 评论 收藏
分享
评论
11
61
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务