发布于 由admin

C++中的延迟初始化（Lazy Initialization）：实现线程安全且高效的单例模式

C++中的延迟初始化（Lazy Initialization）：实现线程安全且高效的单例模式

大家好，今天我们要深入探讨C++中一个非常重要的设计模式实现技巧：延迟初始化（Lazy Initialization），以及如何利用它来构建线程安全且高效的单例模式。单例模式是一种创建型设计模式，它保证一个类只有一个实例，并提供一个全局访问点。在多线程环境下，实现一个线程安全且高效的单例模式并非易事，而延迟初始化正是解决这个问题的关键技术之一。

什么是延迟初始化？

延迟初始化，顾名思义，指的是将对象的初始化推迟到真正需要使用它的时候再进行。与预先初始化（Eager Initialization）相比，延迟初始化具有以下优点：

  • 性能优化： 如果对象在程序运行过程中可能不会被用到，那么延迟初始化可以避免不必要的资源消耗。
  • 依赖关系处理： 如果对象的初始化依赖于其他对象，而这些对象在程序启动时可能尚未准备好，那么延迟初始化可以确保在所有依赖都满足后再进行初始化。
  • 启动速度优化： 延迟初始化可以缩短程序的启动时间，因为不需要在启动时初始化所有对象。

单例模式的常见实现方式

在深入延迟初始化之前，我们先回顾一下单例模式的几种常见实现方式，以及它们各自的优缺点：

1. 饿汉式（Eager Initialization）：

class Singleton {
private:
    static Singleton instance; // 在类加载时就创建实例
    Singleton() {} // 私有构造函数，防止外部创建实例

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

    // 其他成员函数
};

Singleton Singleton::instance; // 静态成员变量的定义
  • 优点： 实现简单，线程安全。
  • 缺点： 无论是否需要使用该单例，都会在程序启动时创建实例，造成资源浪费。

2. 懒汉式（Lazy Initialization – 简单版本）：

class Singleton {
private:
    static Singleton* instance;
    Singleton() {}

public:
    static Singleton* getInstance() {
        if (instance == nullptr) {
            instance = new Singleton();
        }
        return instance;
    }

    // 其他成员函数
};

Singleton* Singleton::instance = nullptr;
  • 优点： 只有在需要时才创建实例，节省资源。
  • 缺点： 在多线程环境下，存在线程安全问题。多个线程可能同时进入 if (instance == nullptr) 条件判断，导致创建多个实例。

3. 懒汉式（Lazy Initialization – 加锁版本）：

#include <mutex>

class Singleton {
private:
    static Singleton* instance;
    static std::mutex mutex;
    Singleton() {}

public:
    static Singleton* getInstance() {
        std::lock_guard<std::mutex> lock(mutex);
        if (instance == nullptr) {
            instance = new Singleton();
        }
        return instance;
    }

    // 其他成员函数
};

Singleton* Singleton::instance = nullptr;
std::mutex Singleton::mutex;
  • 优点： 线程安全，只有在需要时才创建实例。
  • 缺点： 每次调用 getInstance() 都会进行加锁操作，即使实例已经创建，也会存在性能损耗。

通过上面的例子可以看出，简单的懒汉式实现存在线程安全问题，而加锁的懒汉式实现虽然线程安全，但性能不高。因此，我们需要一种更高效、更安全的单例模式实现方式。

Double-Checked Locking (DCL)

Double-Checked Locking (DCL) 是一种尝试在保证线程安全的同时，减少锁的开销的技术。它在加锁之前和之后都进行一次 instance == nullptr 的检查，以避免不必要的加锁操作。

#include <mutex>

class Singleton {
private:
    static Singleton* instance;
    static std::mutex mutex;
    Singleton() {}

public:
    static Singleton* getInstance() {
        if (instance == nullptr) { // 第一次检查
            std::lock_guard<std::mutex> lock(mutex);
            if (instance == nullptr) { // 第二次检查
                instance = new Singleton();
            }
        }
        return instance;
    }

    // 其他成员函数
};

Singleton* Singleton::instance = nullptr;
std::mutex Singleton::mutex;

DCL 的思路是：

  1. 第一次检查 instance == nullptr： 如果 instance 已经创建，则直接返回，避免加锁。
  2. 加锁： 如果 instance 为空，则获取锁，保证只有一个线程可以创建实例。
  3. 第二次检查 instance == nullptr： 在获取锁之后，再次检查 instance 是否为空。这是因为可能在当前线程获取锁之前，已经有其他线程创建了实例。
  4. 创建实例： 如果 instance 仍然为空，则创建实例。

DCL的问题：

虽然DCL看起来很完美，但是它在C++11之前的版本中存在一个非常严重的问题：指令重排（Instruction Reordering）。

编译器和CPU为了优化性能，可能会对指令的执行顺序进行调整。在创建 instance = new Singleton(); 这条语句时，它实际上可以分解为以下三个步骤：

  1. 分配内存空间。
  2. 在分配的内存空间上创建 Singleton 对象。
  3. 将 instance 指针指向分配的内存空间。

由于指令重排，这三个步骤的执行顺序可能变为 1 -> 3 -> 2。假设线程A执行了步骤1和3，但尚未执行步骤2。此时，instance 指针已经指向了分配的内存空间，但该内存空间尚未完成 Singleton 对象的初始化。如果此时线程B进入 getInstance() 函数，并且通过了第一次 instance == nullptr 的检查，那么线程B将获得一个指向未完全初始化的 Singleton 对象的指针，从而导致程序崩溃。

解决DCL指令重排问题：

C++11 引入了 std::atomic 和 std::memory_order 来解决指令重排问题。我们可以使用 std::atomic 来保证对 instance 指针的原子操作，并使用 std::memory_order_acquire 和 std::memory_order_release 来保证内存的可见性。

#include <iostream>
#include <atomic>
#include <mutex>

class Singleton {
private:
    static std::atomic<Singleton*> instance;
    static std::mutex mutex;
    Singleton() {
        std::cout << "Singleton constructor called." << std::endl; // 仅仅为了演示，实际情况不建议在构造函数里打印
    }

public:
    static Singleton* getInstance() {
        Singleton* tmp = instance.load(std::memory_order_acquire); // Load with acquire memory order
        if (tmp == nullptr) {
            std::lock_guard<std::mutex> lock(mutex);
            tmp = instance.load(std::memory_order_relaxed);  // Relaxed load inside the lock
            if (tmp == nullptr) {
                tmp = new Singleton();
                instance.store(tmp, std::memory_order_release); // Store with release memory order
            }
        }
        return tmp;
    }

    void doSomething() {
        std::cout << "Singleton is doing something." << std::endl;
    }

    // 防止拷贝和赋值
    Singleton(const Singleton&) = delete;
    Singleton& operator=(const Singleton&) = delete;
};

std::atomic<Singleton*> Singleton::instance(nullptr);
std::mutex Singleton::mutex;

int main() {
    Singleton* s1 = Singleton::getInstance();
    Singleton* s2 = Singleton::getInstance();

    s1->doSomething();
    s2->doSomething();

    return 0;
}

在这个修正后的 DCL 实现中：

  • std::atomic<Singleton*> instance;： 将 instance 声明为 std::atomic，保证对 instance 的原子操作。
  • instance.load(std::memory_order_acquire);： 使用 memory_order_acquire 加载 instance。这保证了在读取 instance 之前，所有之前的写操作都已经完成。
  • instance.store(tmp, std::memory_order_release);： 使用 memory_order_release 存储 instance。这保证了在写入 instance 之后，所有之后的读操作都可以看到写入的值。
  • 锁内的load使用memory_order_relaxed，因为此时已经持有锁，不存在并发问题，使用relaxed可以避免不必要的同步开销。

为什么需要load操作？

虽然instance是std::atomic类型，直接读取和赋值在某些简单情况下可能也能工作，但显式地使用load和store操作配合memory_order可以更清晰地表达内存同步的意图，并且在不同的编译器和平台上提供更强的保证，确保代码的正确性和可移植性。

需要说明的是，即使使用 std::atomic 和 std::memory_order 解决了指令重排问题，DCL 的性能仍然可能不如其他更简单的实现方式。因此，在实际开发中，我们通常会选择其他更简单、更高效的单例模式实现方式。

Meyers’ Singleton (C++11 及更高版本)

在 C++11 及更高版本中，有一种非常简单、高效且线程安全的单例模式实现方式，称为 Meyers’ Singleton。这种方式利用了 C++11 的静态局部变量初始化线程安全的特性。

class Singleton {
private:
    Singleton() {}

public:
    static Singleton& getInstance() {
        static Singleton instance; // 静态局部变量，只初始化一次，且线程安全
        return instance;
    }

    void doSomething() {
        std::cout << "Singleton is doing something." << std::endl;
    }

    // 防止拷贝和赋值
    Singleton(const Singleton&) = delete;
    Singleton& operator=(const Singleton&) = delete;
};
  • 优点： 实现简单，线程安全，高效。
  • 缺点： 无法控制实例的创建时机，实例会在第一次调用 getInstance() 时创建。

Meyers’ Singleton 的原理：

C++11 保证了静态局部变量的初始化是线程安全的。这意味着，在多线程环境下，只有一个线程可以初始化 instance 变量，其他线程会被阻塞，直到初始化完成。因此，Meyers’ Singleton 既实现了延迟初始化，又保证了线程安全，而且不需要显式地使用锁。

为什么 Meyers’ Singleton 比 DCL 更优秀？

  • 更简单： Meyers’ Singleton 的代码更简洁，更容易理解和维护。
  • 更高效： Meyers’ Singleton 不需要显式地使用锁，避免了锁的开销。
  • 更安全： Meyers’ Singleton 利用了 C++11 的语言特性，避免了指令重排等问题。

call_once (C++11 及更高版本)

C++11 还提供了 std::call_once 函数，可以用来保证某个函数只被调用一次，这也可以用来实现线程安全的延迟初始化。

#include <iostream>
#include <mutex>
#include <memory>

class Singleton {
private:
    Singleton() {
        std::cout << "Singleton constructor called." << std::endl;
    }
    static std::unique_ptr<Singleton> instance;
    static std::once_flag onceFlag;

public:
    static Singleton* getInstance() {
        std::call_once(onceFlag, []() {
            instance.reset(new Singleton());
        });
        return instance.get();
    }

    void doSomething() {
        std::cout << "Singleton is doing something." << std::endl;
    }

    // 防止拷贝和赋值
    Singleton(const Singleton&) = delete;
    Singleton& operator=(const Singleton&) = delete;
};

std::unique_ptr<Singleton> Singleton::instance;
std::once_flag Singleton::onceFlag;

int main() {
    Singleton* s1 = Singleton::getInstance();
    Singleton* s2 = Singleton::getInstance();

    s1->doSomething();
    s2->doSomething();

    return 0;
}

在这个实现中：

  • std::unique_ptr<Singleton> instance;： 使用 std::unique_ptr 来管理 Singleton 对象的生命周期，保证在程序结束时可以正确地释放内存。
  • std::once_flag onceFlag;： 使用 std::once_flag 来保证初始化函数只被调用一次。
  • std::call_once(onceFlag, []() { instance.reset(new Singleton()); });： 使用 std::call_once 来调用初始化函数。std::call_once 保证了初始化函数只会被调用一次，即使在多线程环境下。

call_once 的优势：

  • 线程安全： std::call_once 保证了初始化函数只会被调用一次，即使在多线程环境下。
  • 延迟初始化： 只有在第一次调用 getInstance() 时才会创建实例。
  • 异常安全： 如果初始化函数抛出异常，std::call_once 会保证异常只会被抛出一次，并且后续的调用会继续尝试初始化。

性能对比

为了更直观地了解不同单例模式实现方式的性能差异，我们可以进行简单的性能测试。以下是一个简单的性能测试示例：

#include <iostream>
#include <thread>
#include <chrono>
#include <vector>
#include <atomic>
#include <mutex>

// Meyers' Singleton
class MeyersSingleton {
private:
    MeyersSingleton() {}
public:
    static MeyersSingleton& getInstance() {
        static MeyersSingleton instance;
        return instance;
    }
    void doSomething() {}
    MeyersSingleton(const MeyersSingleton&) = delete;
    MeyersSingleton& operator=(const MeyersSingleton&) = delete;
};

// call_once Singleton
class CallOnceSingleton {
private:
    CallOnceSingleton() {}
    static std::unique_ptr<CallOnceSingleton> instance;
    static std::once_flag onceFlag;
public:
    static CallOnceSingleton* getInstance() {
        std::call_once(onceFlag, []() {
            instance.reset(new CallOnceSingleton());
        });
        return instance.get();
    }
    void doSomething() {}
    CallOnceSingleton(const CallOnceSingleton&) = delete;
    CallOnceSingleton& operator=(const CallOnceSingleton&) = delete;
};

// Double-Checked Locking Singleton (使用 atomic 和 memory_order)
class DCLSingleton {
private:
    DCLSingleton() {}
    static std::atomic<DCLSingleton*> instance;
    static std::mutex mutex;
public:
    static DCLSingleton* getInstance() {
        DCLSingleton* tmp = instance.load(std::memory_order_acquire);
        if (tmp == nullptr) {
            std::lock_guard<std::mutex> lock(mutex);
            tmp = instance.load(std::memory_order_relaxed);
            if (tmp == nullptr) {
                tmp = new DCLSingleton();
                instance.store(tmp, std::memory_order_release);
            }
        }
        return tmp;
    }
    void doSomething() {}
    DCLSingleton(const DCLSingleton&) = delete;
    DCLSingleton& operator=(const DCLSingleton&) = delete;
};

std::atomic<DCLSingleton*> DCLSingleton::instance(nullptr);
std::mutex DCLSingleton::mutex;
std::unique_ptr<CallOnceSingleton> CallOnceSingleton::instance;
std::once_flag CallOnceSingleton::onceFlag;

template <typename SingletonType>
void testSingleton(const std::string& name, int num_threads, int iterations) {
    auto start = std::chrono::high_resolution_clock::now();

    std::vector<std::thread> threads;
    for (int i = 0; i < num_threads; ++i) {
        threads.emplace_back([iterations]() {
            for (int j = 0; j < iterations; ++j) {
                SingletonType::getInstance().doSomething();
            }
        });
    }

    for (auto& thread : threads) {
        thread.join();
    }

    auto end = std::chrono::high_resolution_clock::now();
    auto duration = std::chrono::duration_cast<std::chrono::milliseconds>(end - start);

    std::cout << name << ": " << duration.count() << " ms" << std::endl;
}

int main() {
    int num_threads = 8;
    int iterations = 1000000;

    testSingleton<MeyersSingleton>("Meyers' Singleton", num_threads, iterations);
    testSingleton<CallOnceSingleton>("call_once Singleton", num_threads, iterations);
    testSingleton<DCLSingleton>("DCL Singleton", num_threads, iterations);

    return 0;
}

这个测试程序创建多个线程，每个线程都多次调用 getInstance() 方法。通过测量不同单例模式实现方式的运行时间，可以对它们的性能进行比较。

注意： 性能测试结果会受到硬件环境、编译器优化等因素的影响。因此，在实际开发中，应该根据具体的应用场景进行性能测试，选择最适合的实现方式。

如何选择合适的单例模式实现方式？

实现方式 优点 缺点 适用场景
饿汉式 实现简单，线程安全。 无论是否需要使用该单例，都会在程序启动时创建实例，造成资源浪费。 单例对象在程序启动时必须创建，且资源消耗可以忽略不计。
懒汉式（简单版本） 只有在需要时才创建实例，节省资源。 在多线程环境下，存在线程安全问题。 不适用于多线程环境。
懒汉式（加锁版本） 线程安全，只有在需要时才创建实例。 每次调用 getInstance() 都会进行加锁操作，即使实例已经创建，也会存在性能损耗。 对性能要求不高，且必须保证线程安全。
DCL (C++11及更高版本) 线程安全，延迟初始化，理论上性能较好。 代码复杂，容易出错，性能可能不如其他更简单的实现方式。 不推荐使用，除非对性能有极致要求，并且有充分的测试。
Meyers’ Singleton 实现简单，线程安全，高效。 无法控制实例的创建时机，实例会在第一次调用 getInstance() 时创建。 C++11及更高版本，对实例创建时机没有特殊要求，追求简单高效。
call_once 线程安全，延迟初始化，异常安全。 代码相对复杂。 需要保证异常安全，或者对实例创建时机有更精确的控制。

总而言之，在 C++11 及更高版本中，Meyers’ Singleton 通常是首选的单例模式实现方式，因为它既简单、高效，又线程安全。如果需要更精确地控制实例的创建时机，或者需要保证异常安全，可以使用 std::call_once。而 DCL 由于其复杂性和潜在的性能问题，一般不推荐使用。

总结：单例模式，安全高效至关重要

今天我们深入探讨了C++中延迟初始化在单例模式实现中的应用。从最初的饿汉式、懒汉式，到存在线程安全问题的DCL，再到C++11及更高版本中简单高效的Meyers’ Singleton和call_once，我们看到了语言特性对设计模式实现的影响。选择合适的单例模式实现方式，需要根据具体的应用场景，综合考虑线程安全、性能、代码简洁性等因素。在C++11及更高版本中，Meyers’ Singleton通常是最佳选择。

更多IT精英技术系列讲座，到智猿学院

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注