单例模式-全局音效管理器，为什么只能有一个？

设计模式 · 创建型 · 第 08 篇

标签：设计模式、单例模式、游戏开发、金融系统、Spring

朋友的公司出过一件哭笑不得的事。

他们做的手游上线前夜，测试同学发现一个诡异的 bug：进副本的时候，背景音乐偶尔会"鬼畜"——同一首曲子叠着放两遍，错开半秒，像在KTV里开了原唱又开了伴唱。更要命的是，玩家在设置里把音量拉到 0，切个场景回来，音乐又自己响了。

查了一晚上，原因简单到让人想拍桌子：代码里 new AudioManager() 出现了七次。七个音效管理器，七个音量设置，你管你的，我放我的。

音乐这东西，一个游戏里只能有一个"总控"。其实不只是音乐——这背后藏着一个你可能用过无数次、却未必真正搞懂的模式：单例模式。

天无二日：有些东西，天生只能有一个

模式到底在解决什么问题

单例模式要解决的事情，用一句话说就是：保证一个类在整个程序运行期间，有且仅有一个实例，并且大家都能方便地拿到它。

听起来平淡无奇，但你想想生活里的事：一个国家不能同时有两枚传国玉玺，否则各地官员听谁的？《礼记》里讲"天无二日，土无二王"，古人很早就明白，最高权威必须是唯一的，多了就要出乱子。程序里也一样：音效管理器多一个，音乐就叠着放；发号器多一个，订单号就重号。这些对象天生带着"唯一"的属性，你让代码随便 new，就是在给系统埋雷。

所以单例模式干的其实就两件事：

1. 把 new 的门关死——构造函数私有化，外面谁也别想 new；
2. 留一扇唯一的窗——提供一个全局访问点，所有人都从这儿拿同一个实例。

先从最笨的写法说起

咱们别一上来就上最优解。先看看直觉会怎么写，再看看直觉会怎么栽跟头。

最容易想到的版本，叫"懒汉式"——用到的时候才创建：

publicclassAudioManager {privatestatic AudioManager instance;privateAudioManager() {}  // 门关死publicstatic AudioManager getInstance() {if (instance == null) {            instance = newAudioManager();        }return instance;    }publicvoidplayBgm(String name) { /* 播放背景音乐 */ }publicvoidsetVolume(int v) { /* 设置音量 */ }}

单线程下，这代码没问题。但游戏是多线程的世界：加载线程和资源回调线程可能同时跑到 if (instance == null) 这一行，俩人一看都是 null，好，一人 new 一个。得，又变成两个音效管理器了，鬼畜音乐重出江湖。

那加个锁总行了吧？行，但新的问题来了。

publicstaticsynchronized AudioManager getInstance() {if (instance == null) {        instance = newAudioManager();    }return instance;}

锁是加上了，安全是安全了，可你想想：实例创建完之后，后面几十万次 getInstance() 调用，每次都要排队抢锁——就为了拿一个早就创建好的东西。这就像小区大门只开一条缝，每天早晚高峰所有人排队刷卡，其实门里早就没施工了。游戏里音效调用极其频繁，这么干纯属给自己添堵。

老程序员的选择：双重检查锁

那怎么既安全又不用每次排队？老程序员们折腾出了一个经典写法——双重检查锁（DCL）：

publicclassAudioManager {privatestaticvolatile AudioManager instance;privateAudioManager() {}publicstatic AudioManager getInstance() {if (instance == null) {                    // 第一次检查：不抢锁，纯看一眼synchronized (AudioManager.class) {    // 只有没创建时才排队if (instance == null) {            // 第二次检查：排队期间可能别人建好了                    instance = newAudioManager();                }            }        }return instance;    }}

妙处在哪？实例建好之前，线程排队、检查两次，保证只创建一次；实例建好之后，第一个 if 直接通过，谁也不用抢锁。排队只发生在"施工期间"，竣工之后大门敞开。

但注意那个小小的 volatile，删了它会出大事。这事值得多说两句，因为 new AudioManager() 这一行，在底层其实是三步：分配内存 → 初始化对象 → 把引用指向内存地址。JVM 为了优化，可能把后两步换个顺序——引用先指过去了，对象还没初始化完。这时候另一个线程一看"引用不为 null"，拿着一个半成品对象就去放音乐了，后果不堪设想。volatile 的作用就是告诉 JVM：这几步不许乱序。

更省心的两招

DCL 已经很稳了，但写起来有点啰嗦。还有两个更优雅的选择。

静态内部类——利用 JVM 加载类的天然线程安全性，懒加载和线程安全全白送：

publicclassAudioManager {privateAudioManager() {}privatestaticclassHolder {privatestaticfinalAudioManagerINSTANCE=newAudioManager();    }publicstatic AudioManager getInstance() {return Holder.INSTANCE;  // 第一次用到才加载 Holder 类    }}

枚举单例——《Effective Java》作者 Joshua Bloch 力荐的写法，简洁到离谱：

publicenumAudioManager {    INSTANCE;publicvoidplayBgm(String name) { /* ... */ }}

就这三行，线程安全、防反射、防序列化，全都搞定了。为什么枚举这么硬气？咱们留到后面"坑"的部分细说。

游戏实战：那个叠着放音乐的夜晚

回到开头那个 bug。我们来看看正规的音效管理器应该怎么设计，以及为什么"唯一"对它如此重要。

一个音效管理器，手里攥着的是全局状态：当前背景音是哪首、主音量是多少、音效池里有哪些通道在播放。这些状态必须是全局一份的，否则：

• 玩家在设置界面把音量调到 0，改的是 A 实例；战斗场景里放技能的，是 B 实例——B 的音量还是 80，技能音效照样炸耳朵；
• 进副本时 C 实例开始放副本 BGM，可主城的 D 实例没人通知它停——两首曲子就这么叠上了。

用单例重构之后，逻辑就顺了：

publicenumAudioManager {    INSTANCE;private String currentBgm;privateintvolume=80;publicvoidplayBgm(String name) {if (name.equals(currentBgm)) return;  // 同一首不重复播放        stopBgm();                             // 先停旧的// 加载并播放新 BGM...        currentBgm = name;    }publicvoidsetVolume(int v) {this.volume = v;// 全局生效：所有通道统一调整    }}

现在不管是设置界面、战斗系统还是场景切换，拿到的都是同一个 AudioManager.INSTANCE。音量改一次，全局生效；切 BGM 时旧的必然被停掉。那天晚上叠着放的音乐，本质上就是"唯一性"没守住。

顺带一提，Unity 里 C# 的写法思路完全一样：要么静态类，要么挂在场景里只存活一份的 MonoBehaviour 单例。语言不同，道理是通的。

金融实战：订单号重号，是要出生产事故的

游戏里的单例出问题，是体验事故；金融系统里的单例出问题，那可是真金白银的事故。

我见过最典型的例子是订单号发号器。证券交易、支付系统里，每一笔订单都要有全局唯一的单号——对账靠它、监管报送靠它、出了问题排查还靠它。早期有个系统图省事，每个服务实例各自维护一个本地发号器，单机测试怎么跑都正常。一上生产，两台机器并发发号，重号了。

重号的后果是什么？清算系统看到两个相同单号，不知道是同一笔还是两笔，对账直接卡住；客服查一笔交易，系统里蹦出来两条记录。那天整个团队加班到凌晨，人工核对了几千笔单子。

为什么发号器必须单例？因为发号逻辑里有共享状态——当前序号、当前日期段。只有一份状态，才能保证"下一个号"永远和"上一个号"衔接：

publicenumOrderIdGenerator {    INSTANCE;privatefinalAtomicLongsequence=newAtomicLong(0);privateStringcurrentDate= today();publicsynchronized String nextId() {Stringtoday= today();if (!today.equals(currentDate)) {   // 跨天了，序号归零            currentDate = today;            sequence.set(0);        }longseq= sequence.incrementAndGet();return currentDate + String.format("%010d", seq);// 形如 202609280000000042    }}

只有一个发号器，序号这一个变量才管得住；要是有两个，各自的序号都从 1 开始数，重号是必然的。

当然你会问：现在的系统都是分布式的，单机单例不够用了怎么办？问得好——这正是单例模式的边界。跨机器的唯一性，得靠 Redis 发号、数据库号段、雪花算法这些"分布式单例"思路。但思想的根是一样的：全局唯一的序号，必须有一个全局唯一的权威来源。从单机单例到分布式发号，变的只是"这个权威放在哪"，不变的是"权威只能有一个"。

金融系统里另一个典型的单例是交易时钟。全系统对"现在几点"必须只有一个答案——否则撮合系统认为是 14:59:59 还能下单，清算系统认为是 15:00:01 已经闭市，一笔单子两边说法打架，又是事故。

源码实战：Spring 容器里的单例

单例模式你可能嫌它简单，但有个东西你天天在用——Spring 的 Bean，默认就是单例。

你写一个 @Service，启动时 Spring 创建一次，之后不管注入到哪里，拿到的都是同一个对象。这事你我都知道，但你想过没有：Spring 是怎么保证"只有一个"的？几百个 Bean 的单例，它总得有个地方存着吧？咱们翻开源码看一眼。

答案藏在一个名字特别直白的类里：DefaultSingletonBeanRegistry。里面有个更直白的字段：

privatefinal Map<String, Object> singletonObjects = newConcurrentHashMap<>(256);

看，所谓的"单例池"，就是一个并发 HashMap。key 是 Bean 的名字，value 就是那个唯一的实例。Spring 保证单例的全部秘密，就在 getSingleton() 这个方法里。我把关键逻辑抽出来，咱们像聊天一样过一遍：

public Object getSingleton(String beanName) {// 先去池子里看一眼，有就直接返回——绝大多数请求到这儿就结束了ObjectsingletonObject=this.singletonObjects.get(beanName);if (singletonObject == null) {// 池子里没有，说明要创建了，这才开始上锁synchronized (this.singletonObjects) {// 加锁后再看一次——排队期间可能别的线程已经建好放进去了            singletonObject = this.singletonObjects.get(beanName);if (singletonObject == null) {// ...真的创建 Bean（调用构造函数、填充属性、AOP 代理等）// 创建完，放进池子this.singletonObjects.put(beanName, singletonObject);            }        }    }return singletonObject;}

你发现没有？这就是双重检查锁的思路：先无锁看一眼，没有再排队，排队之后再检查一次。区别在于 Spring 要管理成百上千个 Bean，所以用 Map 存，用 ConcurrentHashMap 保证"看一眼"这一步的并发安全。咱们前面手写 DCL 时纠结的那些事——什么时候抢锁、为什么要检查两次——框架作者面对的考量一模一样。

这就是读源码有意思的地方：你以为是高深的框架魔法，翻开来一看，是自己前两天刚学过的设计模式。

这里有几个坑

我在单例上栽过的跟头，挑几个说给你听。

第一个坑：单例不等于线程安全。 这是最常见的误解。Spring 的 Bean 是单例，意思是"只有一个实例"，可没说"这个实例被一百个线程同时访问不会出事"。你在单例 Bean 里放一个可变的成员变量，多线程下照样乱套。单例解决的是"数量唯一"，线程安全得你自己管——要么无状态，要么用 AtomicLong、ConcurrentHashMap 这类并发工具。

第二个坑：单例会被"偷家"。 普通的单例类，别人能用反射把私有构造函数撬开 setAccessible(true)，偷偷 new 出第二个实例；实现了 Serializable 的话，反序列化也会造出新对象。枚举单例为什么硬气？因为 JVM 层面就保证了枚举实例唯一，反射创建枚举会直接抛异常，序列化也有特殊保护。这就是为什么 Bloch 说枚举是实现单例的最佳方式——不是它写法短，是它把后门锁死了。

第三个坑：别把单例当全局变量垃圾桶。 有些项目里，凡是不知道放哪的东西都往单例里塞，最后单例变成一个巨大的全局状态堆，谁都能改，谁改坏了全系统遭殃。单例应该只装那些天然全局唯一的东西：配置、发号器、时钟、连接池。业务状态往单例里放，多半是想偷懒。

第四个坑：类加载器的盲区。 同一个类被不同的 ClassLoader 加载，就是两个不同的类，各自的单例互不相认。做插件化、热部署的系统踩过这个坑的不少——明明是单例，内存里却躺着两个实例。

这道题和咱们文章的联系

Spring 的 singletonObjects 池子，和游戏里的 AudioManager、金融里的 OrderIdGenerator，干的是同一件事：为"全局唯一"这个需求，提供一个受控的、唯一的访问入口。区别只在规模——管一个音效管理器用枚举三行搞定，管几百个 Bean 就得上并发 Map 加双重检查。模式是思想，不是死代码，看懂这一点，你以后在源码里再遇见它，就像在街上认出了老朋友。

生活里的影子

想想医院的挂号系统。全院的号源只有一个总池子，你在窗口挂、在 App 挂、在自助机挂，抢的是同一批号。要是每个渠道各维护一份号源，同一个专家号在窗口卖出去一次、在 App 又卖出去一次——那场面，和叠着放的背景音乐一模一样混乱。唯一的权威来源，永远是秩序的起点。

总结

传国玉玺只有一枚，不是古人舍不得多刻，是权威必须唯一。单例模式的全部智慧，就是把这份"唯一"用代码焊死：门只留一扇，钥匙只有一把。

觉得有收获？转发给你的技术伙伴，说不定能帮他避开今晚的线上事故。

你的项目里用过单例吗？是手写 DCL，还是直接交给 Spring？有没有踩过单例的坑？评论区聊聊。