首页 > 编程笔记 > C++笔记 阅读：26

C++单例模式详解（附带实例）

单例模式是最常用且为人熟知的设计模式之一。在很多软件系统中，对于特定类型的对象，我们只需要一个实例，例如配置管理器、线程池或者数据库连接池，这样的设计可以减少系统资源的消耗，提高系统的性能。

在 C++ 中，由于全局变量的构造顺序是不确定的，尤其当全局变量之间存在互相依赖时，可能导致程序启动时的问题。单例模式确保一个类只有一个实例存在，并提供全局访问点来获取这个实例，并且该实例的创建是按需进行的，从而有效地避免了因全局变量初始化顺序不确定带来的风险。这不仅解决了潜在的初始化依赖问题，还提供了一种安全和可靠的方式来全局访问特定资源，如配置管理器或数据库连接池。

单例模式的主要目的是控制对象的数量，确保在整个程序的生命周期中只创建一个实例。通过限制实例的数量来减少内存的使用，同时避免在资源管理上出现多个对象之间的冲突。

单例模式的设计原则如下：

现代C++实现单例模式的变化与优化

传统的单例模式实现主要有两种方法：
与之相对，现代 C++ 实践中，Meyers' Singleton 提供了一种更为优雅的解决方案。这种方法使用局部静态变量，其线程安全由自 C++11 起的编译器自动保证，同时实现了延迟加载且不需要显式的锁。这种实现不仅简化了代码，还提高了效率，并且不需要开发者关心对象的生命周期管理。

使用局部静态变量的单例模式实现：
class Singleton {
public:
    // 删除拷贝构造函数和拷贝赋值运算符，防止被复制
    Singleton(const Singleton&) = delete;
    Singleton& operator=(const Singleton&) = delete;

    static Singleton& getInstance() {
        static Singleton instance;
        return instance;
    }

protected:
    Singleton() {} // 构造函数为 protected，防止外部构造
    ~Singleton() {} // 析构函数为 protected，保证只能在类内部被析构
};
尽管局部静态变量在实现单例模式时提供了众多优点，如简单性、自带的线程安全性等，但在某些特定场景下，使用指针来实现单例模式可能更具优势：
总体而言，选择哪种实现方式应基于具体的需求和场景。虽然在大多数情况下，局部静态变量因其简单和内置的线程安全而被推荐，但在需要特殊处理单例生命周期或进行复杂的子类化时，指针的使用可能更合适。

此外，通过结合使用 std::mutex 和 std::call_once，也可以非常便捷地实现线程安全的单例模式，这为使用指针提供了额外的线程安全保障。

单例模式的使用场景和潜在的滥用问题

单例模式由于其提供全局访问点和确保单一实例的特性，在很多场合下非常有用。然而，正因为这些特性，如果不慎滥用，也可能带来一系列问题。因此，了解单例的适用场景并避免滥用非常重要。

单例模式特别适用于以下几种情况：
尽管单例模式有其明确的优势，但在不适当的情况下使用它可能会导致问题：
因此，在决定使用单例模式之前，应仔细考虑是否真的需要一个全局访问点，以及是否有必要限制实例的数量。对于某些情况，使用依赖注入可能是更好的选择，他通过显式地将资源或服务传递给需要它们的对象，以此提高代码的可测试性和模块化。

在考虑使用其他设计技巧来避免单例模式的潜在问题时，有一种常见的方法是创建临时对象。这种方法主要是利用栈对象包含单例对象的引用的特点，在不牺牲单例模式提供全局访问性的前提下，达到解耦的目的。

具体实现方式是定义一个栈对象，该栈对象在构造时获取单例对象的引用，并在其生命周期内进行操作。当栈对象生命周期结束时，它会自动被销毁（通过析构函数），而不会影响单例对象的生命周期。这种技巧的优势在于，既保留了单例提供的全局访问点，又通过局部栈对象管理降低了组件间的直接依赖，提高了代码的模块化。

C++单例模式实例

下面将展示一个使用栈对象来管理单例类对象生命周期的例子。这个例子中，首先定义了一个单例类 DatabaseConnection，负责数据库连接，然后创建一个辅助类 DatabaseConnectionManager，用于通过栈对象管理单例对象的生命周期。

1) 定义单例类

首先，定义单例类 DatabaseConnection，该类包含一个用于获取实例的静态方法，并将构造函数设为私有，以确保只能通过该静态方法创建实例。 
#include <iostream>

class DatabaseConnection {
public:
    static DatabaseConnection& getInstance() {
        static DatabaseConnection instance; // 确保被销毁
        return instance;
    }

    // 拷贝构造函数和赋值运算符已禁用
    DatabaseConnection(const DatabaseConnection&) = delete;
    DatabaseConnection& operator=(const DatabaseConnection&) = delete;

    void connect() {
        // 模拟连接数据库
        std::cout << "Database connected." << std::endl;
    }

    void disconnect() {
        // 模拟断开数据库连接
        std::cout << "Database disconnected." << std::endl;
    }

private:
    DatabaseConnection() {} // 私有构造函数
    ~DatabaseConnection() {} // 私有析构函数
};

2) 定义辅助管理类

定义一个辅助类 DatabaseConnectionManager，该类在构造函数中获取单例实例，并在析构函数中执行清理操作。
class DatabaseConnectionManager {
public:
    DatabaseConnectionManager() {
        // 获取单例并进行连接
        db = &DatabaseConnection::getInstance();
        db->connect();
    }
    ~DatabaseConnectionManager() {
        // 断开连接
        db->disconnect();
    }
private:
    DatabaseConnection* db;
};

3) 使用栈对象管理单例

在函数或者代码块中创建 DatabaseConnectionManager 的对象，这样就可以自动管理数据库连接的生命周期了。
int main() {
    {
        DatabaseConnectionManager dbManager;
        // 这里进行数据库操作
    } // dbManager 在这里出了作用域，自动调用析构函数断开连接
    // 这里数据库已经断开连接，不再可用
    return 0;
}
在这个例子中，DatabaseConnectionManager 的对象在其生命周期结束时自动管理单例 DatabaseConnection 的连接和断开，从而降低了与单例类的耦合。此外，DatabaseConnectionManager 的对象利用 RAII 原则管理资源，使得代码更清晰，也更易于管理。

这种使用栈对象管理单例类生命周期的方法通过一个管理类自动获取和释放资源，借助 C++ 的 RAII 特性减少资源泄漏风险，并降低代码耦合，增强测试性，同时可以精细控制单例的访问时机和方式。但它不改变单例的全局性和静态状态，可能增加代码复杂性和维护难度，尤其在多线程环境中，需要妥善处理同步和竞态条件。此外，还存在生命周期管理风险，尤其在多个管理对象独立操作同一单例时，可能导致使用错误和生命周期问题。

总的来说，这种方法在需要减少对全局状态的依赖和提高模块性的场景中非常有用，但它也引入了额外的复杂性和潜在的线程安全挑战。设计时需要权衡这些因素，确保所采用的策略符合应用的具体需求。

第二种常用的设计技巧是通过命名空间中的全局函数来代替单例模式。这种方法充分利用了命名空间的作用域管理特性，通过全局函数直接提供服务，而不是通过一个全局访问的单一实例。

在这种设计中，相关的功能和数据被封装在一个命名空间中，而非单一的对象。全局函数负责处理所有需要的操作，例如配置数据的加载和访问、日志的记录等。这些函数通过维护静态局部变量来存储状态，从而在保持状态持久化的同时，避免了单例模式中全局对象可能带来的问题。

例如，在一个应用程序中，可以将日志功能封装在一个命名空间中，提供一个全局的记录日志的函数。这样，任何需要记录日志的组件都可以直接调用这个函数，而无须关心日志记录器实例的创建和管理。这样做的好处是降低了代码的复杂性，提高了模块的独立性，使得每个部分更加专注于其职责。

使用命名空间的全局函数替代单例的优势在于：
这种方法适用于那些需要全局访问但不适合单例模式管理的场景，特别是在需要避免复杂依赖和增强模块独立性的大型应用程序中。总的来说，命名空间的全局函数是一个简洁且有效的替代方案，能够提供与单例模式类似的便利性，同时避免了单例模式带来的一些结构上的缺陷。

总之，单例模式是一个强大的工具，但它并不适合所有情况。在使用单例模式时，应慎重考虑其对应用程序架构的影响，并确保其使用方式符合开发的长远目标。通过明确需求并评估各种替代方案，可以有效地利用单例模式的优势，同时避免其潜在的缺陷。

相关文章