单例模式：嵌入式系统里的“独生子”设计

各位工程师朋友，咱们今天聊聊单例模式。说实话，这个模式在嵌入式系统里太常见了。我做了这么多年嵌入式开发，几乎每个项目都会用到它。

单例模式，说白了就是保证一个类只有一个实例。你想想看，有些资源在系统里只能有一份——比如硬件抽象层、系统时钟、内存管理器。要是搞出两个实例来操作同一个硬件，那不乱套了？

为什么嵌入式系统需要单例？

我举个例子你就明白了。假设你管理一个系统时钟，所有模块都要通过它来获取时间戳。如果每个模块都new一个时钟对象，那每个对象维护的时间可能都不一样。这就像你家里挂了三个钟，每个时间都不一样，你信哪个？

嵌入式系统里，单例模式主要用在这么几个地方：

  • 硬件抽象层（HAL）：每个外设驱动只能有一个实例，避免重复初始化
  • 系统时钟管理：全局唯一的时间源
  • 内存池管理：统一分配和回收内存
  • 日志系统：所有模块往同一个日志通道写数据
  • 配置管理器：系统参数只有一份拷贝

核心要点：单例模式解决的是“全局唯一访问点”的问题。在资源受限的嵌入式系统里，这能省下不少内存和CPU开销。

两种实现方式：饿汉式 vs 懒汉式

实现单例模式，主要有两条路。我根据自己的项目经验，给你分析一下各自的优劣。

饿汉式：提前准备好

饿汉式，就是程序启动时就创建好实例。像这样：

// 饿汉式单例 - 系统时钟管理器
typedef struct {
    uint32_t tick_count;
    void (*init)(void);
    uint32_t (*get_tick)(void);
} SystemClock_t;

static SystemClock_t s_clock_instance = {
    .tick_count = 0,
    .init = clock_init,
    .get_tick = clock_get_tick
};

SystemClock_t* SystemClock_GetInstance(void) {
    return &s_clock_instance;
}

这种做法，说白了就是“早产儿”。程序一跑起来，实例就躺在那里了。好处是简单、快，调用时不用判断是否为空。坏处是——如果这个实例初始化很耗时，或者占内存很大，那系统启动就会变慢。

我记得有一次做车载项目，系统里有个GPS模块的驱动用了饿汉式。结果启动时初始化GPS花了将近2秒，客户说“你这系统怎么开机这么慢？”后来我改成懒汉式，只在第一次调用GPS功能时才初始化，启动时间降到了0.3秒。

懒汉式：用的时候再创建

懒汉式，就是“懒人模式”——不到万不得已不干活。第一次调用时才创建实例。

// 懒汉式单例 - 内存池管理器
typedef struct {
    uint8_t* pool_start;
    uint32_t pool_size;
    uint32_t used_size;
} MemoryPool_t;

static MemoryPool_t* s_pool_instance = NULL;

MemoryPool_t* MemoryPool_GetInstance(void) {
    if (s_pool_instance == NULL) {
        // 第一次调用时才分配内存
        s_pool_instance = (MemoryPool_t*)malloc(sizeof(MemoryPool_t));
        if (s_pool_instance != NULL) {
            s_pool_instance->pool_start = NULL;
            s_pool_instance->pool_size = 0;
            s_pool_instance->used_size = 0;
        }
    }
    return s_pool_instance;
}

懒汉式的优势很明显：节省启动时间，节省内存（如果这个功能一直没用，实例就不会创建）。但问题也来了——线程安全。

注意：懒汉式在多线程环境下，如果两个线程同时第一次调用GetInstance，可能会创建两个实例！这在嵌入式RTOS系统里是个大坑。

线程安全问题：嵌入式工程师的噩梦

说到线程安全，我得多说几句。嵌入式系统现在越来越复杂，动不动就跑个FreeRTOS、uCOS之类的RTOS。多线程环境下，单例模式的实现必须小心。

为什么会出问题？你想想看：

  1. 线程A调用GetInstance，发现s_pool_instance == NULL
  2. 线程A正准备malloc，时间片到了，切换到线程B
  3. 线程B也调用GetInstance，发现s_pool_instance还是NULL
  4. 线程B创建了一个实例，然后切回线程A
  5. 线程A继续执行，又创建了一个实例

这下好了，两个线程各拿一个实例，内存池管理就乱套了。

怎么解决？我常用的方法有这几种：

方法 适用场景 优缺点
互斥锁保护 RTOS环境 简单可靠，但加锁有性能开销
双重检查锁定 性能敏感场景 需要内存屏障，实现复杂
饿汉式（推荐） 资源不紧张时 天生线程安全，最简单
静态局部变量 C++环境 C++11保证线程安全，C语言不行

我个人习惯，在嵌入式系统里优先用饿汉式。为什么？因为嵌入式系统启动时资源相对充裕，而且饿汉式不需要考虑线程安全问题。你想想看，系统时钟、硬件抽象层这些，本来就是系统启动就要用的，饿汉式正合适。

我的建议：如果实例初始化开销不大（比如只是设置几个寄存器、分配一小块内存），直接用饿汉式。省心、安全、性能好。

如果实在要用懒汉式，那就得加锁。在FreeRTOS里可以这样写：

// 线程安全的懒汉式单例
static SemaphoreHandle_t s_mutex = NULL;
static MemoryPool_t* s_pool_instance = NULL;

MemoryPool_t* MemoryPool_GetInstance(void) {
    MemoryPool_t* instance = NULL;
    
    // 第一次检查，不加锁
    if (s_pool_instance == NULL) {
        // 加锁
        xSemaphoreTake(s_mutex, portMAX_DELAY);
        
        // 第二次检查，加锁后
        if (s_pool_instance == NULL) {
            s_pool_instance = (MemoryPool_t*)malloc(sizeof(MemoryPool_t));
            // 初始化...
        }
        
        // 解锁
        xSemaphoreGive(s_mutex);
    }
    
    return s_pool_instance;
}

这就是经典的“双重检查锁定”模式。第一次检查避免不必要的加锁，第二次检查确保线程安全。

避坑指南

我曾经踩过一个坑，分享给你：

有次做物联网网关项目，用了懒汉式单例管理WiFi模块。WiFi模块初始化需要连接路由器，耗时3-5秒。结果在系统启动后，多个任务同时调用WiFi发送数据，都触发了第一次初始化。虽然加了锁，但初始化过程中WiFi模块的状态机被多个任务同时操作，直接死机了。

后来怎么解决的？我把WiFi模块改成了饿汉式，在系统启动阶段就完成初始化。虽然启动慢了3秒，但运行稳定多了。有时候，简单粗暴反而更可靠。

总结一下我的经验：

  • 能用饿汉式，就别用懒汉式
  • 如果必须用懒汉式，一定要考虑线程安全
  • 嵌入式系统里，稳定性比性能更重要
  • 单例模式不是万能的，别滥用。只有真正需要全局唯一的资源才用

好了，单例模式就聊到这儿。下一章咱们聊聊观察者模式，在嵌入式事件驱动系统里特别有用。到时候我会分享一个我在智能家居项目里用观察者模式处理传感器数据的案例，保证让你有收获。

← 上一章 📖 返回目录 下一章 →