c++11如何实现单例模式？
好的，咱们来聊聊 C++11 里怎么把单例模式玩明白。这玩意儿看着简单，但要弄得既安全又高效，还得考虑不少细节。咱们就抛开那些花里胡哨的“AI风”描述，实打实地把这事儿掰开了揉碎了说。
单例模式，说白了就是保证一个类在整个程序的生命周期里，只有一个实例存在，并且提供一个全局的访问点。想象一下，你有个配置管理器，或者一个日志记录器，你肯定不希望它们被创建好几个，那样会导致状态混乱，或者资源被重复占用。
C++11 之前的单例模式，以及它们遇到的问题
在 C++11 之前，实现单例模式通常有几种方式，每种都有各自的痛点：
1. 全局静态变量/函数内的静态变量 (Magic Static)：这是最常见的一种。
```c++
// 错误示范，或说是不够健壮的示范
class Singleton {
private:
Singleton() {} // 私有构造函数
Singleton(const Singleton&) = delete; // 禁止拷贝
Singleton& operator=(const Singleton&) = delete; // 禁止赋值
static Singleton instance; // 裸指针
public:
static Singleton getInstance() {
if (instance == nullptr) {
instance = new Singleton();
}
return instance;
}
// ... 其他成员 ...
~Singleton() {} // 析构函数通常也要处理
};
Singleton Singleton::instance = nullptr;
```
问题出在哪？
线程安全问题 (DoubleChecked Locking)：如果多个线程同时调用 `getInstance()`，并且 `instance` 是 `nullptr`，那么它们都可能通过 `if (instance == nullptr)` 的检查，然后都去 `new Singleton()`。即使你后来加了锁，比如 `std::mutex` 来保护 `new` 操作，实现一个可靠的“双重检查锁定”（DoubleChecked Locking）在 C++ 标准层面上是相当困难的，容易出错。
内存泄漏问题 (管理裸指针)：上面的代码里，你 `new` 了一个 `Singleton` 对象，但谁来 `delete` 它？你需要在程序退出时手动 `delete instance`。如果忘记了，或者程序异常退出，就会内存泄漏。要是你写一个全局的析构函数来处理 `delete`，又会遇到另一个问题：静态对象的析构顺序是未定义的。如果你的单例对象依赖于其他全局对象，而其他对象先被析构了，那么你的单例析构时可能会访问一个已经被销毁的对象，引发崩溃。
2. Registering with a Factory/Manager：稍微好一点，但仍然需要手动管理。
```c++
class Singleton {
private:
Singleton() {}
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
static Singleton singleInstance;
static std::mutex mutex;
public:
static Singleton& getInstance() {
std::lock_guard lock(mutex); // 加锁
if (singleInstance == nullptr) {
singleInstance = new Singleton();
}
return singleInstance;
}
// ...
~Singleton() {}
};
Singleton Singleton::singleInstance = nullptr;
std::mutex Singleton::mutex;
```
这里虽然用锁解决了线程安全问题（至少大部分情况下），但内存管理（`new` 和 `delete`）的问题依然存在。而且，每次访问都需要加锁，性能上会有损耗。
C++11 的绝招：函数内的静态变量 (Magic Static) 的进化
C++11 标准在语言层面解决了函数内静态变量的初始化问题，使其局部静态变量的初始化是线程安全的。这简直是为单例模式量身定做的！
让我们看看 C++11 推荐的单例模式实现方式：
```c++
include
include // 只是为了演示多线程访问，实际单例不需要这个头文件
class Singleton {
public:
// 1. 禁止拷贝构造函数和拷贝赋值运算符
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
// 2. 提供一个公共的静态方法来获取实例
static Singleton& getInstance() {
// 这是 C++11 的魔法所在：函数内的静态变量初始化是线程安全的。
// 当第一次调用 getInstance() 时，singletonInstance 会被初始化。
// 如果有多个线程同时尝试初始化，编译器和运行时会确保只初始化一次。
static Singleton singletonInstance;
return singletonInstance;
}
// 3. 演示其他成员函数
void showMessage() {
std::cout << "Hello from Singleton instance! My address is: " << this << std::endl;
}
private:
// 4. 私有构造函数，阻止外部直接创建对象
Singleton() {
std::cout << "Singleton constructor called. Instance created at: " << this << std::endl;
}
// 5. 私有析构函数 (可选，但推荐使用)
// 注意：当静态变量被销毁时，它会被自动调用。
// 如果你的析构函数有副作用（比如释放资源），这里需要谨慎处理。
// 对于简单的单例，析构函数可能什么都不做。
~Singleton() {
std::cout << "Singleton destructor called. Instance at: " << this << std::endl;
}
};
// 示例：模拟多个线程访问单例
void thread_function() {
std::cout << "Thread " << std::this_thread::get_id() << " calling getInstance()..." << std::endl;
Singleton& s = Singleton::getInstance();
s.showMessage();
}
int main() {
std::cout << "Main thread starting." << std::endl;
// 第一次获取实例，会调用构造函数
Singleton& s1 = Singleton::getInstance();
s1.showMessage();
// 第二次获取实例，不会再次调用构造函数
Singleton& s2 = Singleton::getInstance();
s2.showMessage();
std::cout << "s1 and s2 point to the same instance: " << (&s1 == &s2) << std::endl;
// 模拟多线程访问
std::thread t1(thread_function);
std::thread t2(thread_function);
t1.join();
t2.join();
std::cout << "Main thread finished." << std::endl;
// 程序退出时，静态对象 singletonInstance 会被自动销毁，
// 并且其析构函数会被调用。
return 0;
}
```
分析一下这段代码，它有什么优点，又需要注意什么：
优点（为什么 C++11 的方式更好）
1. 线程安全（初始化时）：这是最大的亮点。C++11 标准规定，一个函数内部的局部静态变量的初始化是线程安全的。这意味着，当你的程序第一次调用 `Singleton::getInstance()` 时，无论有多少个线程同时进行，编译器和运行时环境都会保证 `singletonInstance` 这个静态局部变量只会被初始化一次。你不再需要手动添加 `std::mutex` 来保护初始化过程。
2. 内存管理自动化：`static Singleton singletonInstance;` 这行代码声明了一个静态局部变量。当程序退出时，这个静态局部变量会被自动销毁，并且它的析构函数也会被自动调用。这彻底解决了之前裸指针管理带来的内存泄漏和析构顺序问题。你不需要手动 `delete`，也不需要担心静态对象的析构顺序混乱。
3. 简洁和易读：相比于手动加锁和管理裸指针的代码，这种方式非常简洁，逻辑也更清晰。一眼就能看出这是单例模式的实现。
4. 懒汉式初始化：单例对象只有在第一次被请求时才会被创建。如果你的单例对象比较“重”（比如需要加载大量配置），这种懒汉式初始化可以避免在程序启动时就消耗大量资源，只有在真正需要的时候才创建。
需要注意的细节
1. 析构函数：
虽然 C++11 解决了析构的自动调用问题，但如果你的单例类的析构函数需要执行一些关键操作（比如关闭数据库连接、保存最终日志等），你需要特别注意析构顺序。
如果你的单例依赖于其他全局或静态变量，而这些变量的析构顺序在你控制之外，并且在你的单例析构之前就被销毁了，那么你的单例析构函数可能会访问到已经不存在的对象，导致运行时错误。
解决析构顺序问题的一个常见策略是：不要让你的单例依赖于其他全局/静态变量。如果必须依赖，可以考虑使用一个全局的管理器类，将所有需要管理的单例对象注册到它里面，然后由这个管理器类统一管理它们的生命周期和析构顺序。
在 C++11 之后，有一个更优雅的解决方案来管理静态对象的初始化和销毁顺序：使用嵌套类或在一个类内部定义静态成员。比如，你可以把 `Singleton` 的创建逻辑放到一个专门的“工厂”类里，这个工厂类也是一个单例。但通常情况下，上面的函数内静态变量的方法已经足够好。
2. 构造函数的参数：
上面的示例中，`Singleton()` 是一个无参构造函数。如果你的单例需要在创建时接受参数，事情就变得复杂一些。
解决方案：
通过 `getInstance` 传递参数：但这样会使 `getInstance` 的签名改变，并且如果第一次调用和后续调用传递的参数不同，如何处理是个问题。通常我们会要求第一次调用传递必要的参数。
```c++
// 简化示例，实际需要更严谨的处理
class Singleton {
public:
static Singleton& getInstance(const std::string& config) {
static Singleton singletonInstance(config); // 传递参数给构造函数
return singletonInstance;
}
// ...
private:
Singleton(const std::string& cfg) : config_(cfg) {
std::cout << "Singleton constructor with config: " << config_ << std::endl;
}
std::string config_;
};
```
这种方式的问题在于，你无法强制用户在第一次调用 `getInstance` 时提供参数，或者他们可能会在后续调用中提供不同的参数。而且，你需要确保所有调用者都知道需要传递的参数。
使用一个配置类：将所有配置信息封装在一个单独的配置类（或者结构体）中，这个配置类本身也可以是单例，或者由外部在程序启动时创建并初始化好。然后，你的单例在创建时（通过 `getInstance` 传递配置类的实例或其引用）来使用这些配置。
3. 避免全局状态的滥用：
虽然单例模式很有用，但过度使用会导致代码的耦合度增高，难以测试和维护。每一个单例对象都相当于一个全局变量，如果你的程序充斥着各种单例，你很难追踪某个状态的变化是由哪个部分引起的。
在设计时，先考虑一下是否真的需要一个全局唯一的实例，或者是否有更合适的替代方案（比如依赖注入、工厂模式等）。
为什么不要再用双重检查锁定 (DCLP) 了？
在 C++11 之前，为了实现线程安全的懒汉式单例，一种流行但复杂的模式是双重检查锁定。它看起来是这样的：
```c++
// C++11 之前的 DCLP 示范 (通常被认为是有问题的)
include
class SingletonDCLP {
private:
SingletonDCLP() {}
SingletonDCLP(const SingletonDCLP&) = delete;
SingletonDCLP& operator=(const SingletonDCLP&) = delete;
static SingletonDCLP instance;
static std::mutex mutex_;
public:
static SingletonDCLP getInstance() {
if (instance == nullptr) { // 第一次检查，不加锁
std::lock_guard lock(mutex_); // 加锁
if (instance == nullptr) { // 第二次检查，加锁后再次检查
instance = new SingletonDCLP();
}
}
return instance;
}
~SingletonDCLP() {
// 还需要手动 delete 并且处理析构顺序
}
};
SingletonDCLP SingletonDCLP::instance = nullptr;
std::mutex SingletonDCLP::mutex_;
```
为什么它在 C++11 之前就有问题？
1. 内存模型问题：即使加了锁，现代编译器和处理器为了性能，可能会对写操作（如 `new SingletonDCLP()`）进行重排序。也就是说，`instance = new SingletonDCLP();` 这句话的三个步骤——分配内存、调用构造函数、将内存地址赋给 `instance`——可能不是严格按照这个顺序执行的。如果在赋值给 `instance` 之后，构造函数还没完成，另一个线程进来检查 `instance` 时发现它不再是 `nullptr`，就直接返回了一个未完全构造好的对象，这会导致未定义行为。
2. 锁的性能开销：每次调用 `getInstance` 都要进行两次检查，并且在创建实例之前都需要加锁，这在多线程环境下会有性能损耗。
C++11 如何解决这个问题？
C++11 通过标准化的内存模型和原子操作，使得局部静态变量的初始化成为可能，并且保证了其线程安全。它实际上是语言层面内置的、高效的 DCLP 实现。所以，在你使用 C++11 或更高版本时，根本不需要自己去实现一个复杂的 DCLP，直接用函数内的静态变量就搞定了。
总结一下
在 C++11 及之后，实现线程安全的单例模式最优雅、最简洁、也最推荐的方式就是利用函数内局部静态变量。它集成了线程安全初始化和自动内存管理，让你从许多 C++11 之前的陷阱中解脱出来。
关键在于：
私有化构造函数和拷贝操作：防止外部随意创建和复制。
提供一个公共的静态 `getInstance` 方法：这是唯一的访问入口。
在 `getInstance` 方法内部声明一个静态局部变量：`static Singleton instance;` 这是核心。
返回该静态变量的引用。
记住，虽然 C++11 简化了单例的实现，但设计时的审慎仍然是必不可少的。考虑清楚为什么需要单例，以及它的生命周期和潜在的依赖关系，才能写出健壮的代码。
单例模式，说白了就是保证一个类在整个程序的生命周期里，只有一个实例存在，并且提供一个全局的访问点。想象一下，你有个配置管理器，或者一个日志记录器，你肯定不希望它们被创建好几个，那样会导致状态混乱，或者资源被重复占用。
C++11 之前的单例模式，以及它们遇到的问题
在 C++11 之前，实现单例模式通常有几种方式，每种都有各自的痛点：
1. 全局静态变量/函数内的静态变量 (Magic Static)：这是最常见的一种。
```c++
// 错误示范，或说是不够健壮的示范
class Singleton {
private:
Singleton() {} // 私有构造函数
Singleton(const Singleton&) = delete; // 禁止拷贝
Singleton& operator=(const Singleton&) = delete; // 禁止赋值
static Singleton instance; // 裸指针
public:
static Singleton getInstance() {
if (instance == nullptr) {
instance = new Singleton();
}
return instance;
}
// ... 其他成员 ...
~Singleton() {} // 析构函数通常也要处理
};
Singleton Singleton::instance = nullptr;
```
问题出在哪？
线程安全问题 (DoubleChecked Locking)：如果多个线程同时调用 `getInstance()`，并且 `instance` 是 `nullptr`，那么它们都可能通过 `if (instance == nullptr)` 的检查，然后都去 `new Singleton()`。即使你后来加了锁，比如 `std::mutex` 来保护 `new` 操作，实现一个可靠的“双重检查锁定”（DoubleChecked Locking）在 C++ 标准层面上是相当困难的，容易出错。
内存泄漏问题 (管理裸指针)：上面的代码里，你 `new` 了一个 `Singleton` 对象，但谁来 `delete` 它？你需要在程序退出时手动 `delete instance`。如果忘记了，或者程序异常退出，就会内存泄漏。要是你写一个全局的析构函数来处理 `delete`，又会遇到另一个问题：静态对象的析构顺序是未定义的。如果你的单例对象依赖于其他全局对象，而其他对象先被析构了，那么你的单例析构时可能会访问一个已经被销毁的对象，引发崩溃。
2. Registering with a Factory/Manager：稍微好一点，但仍然需要手动管理。
```c++
class Singleton {
private:
Singleton() {}
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
static Singleton singleInstance;
static std::mutex mutex;
public:
static Singleton& getInstance() {
std::lock_guard
if (singleInstance == nullptr) {
singleInstance = new Singleton();
}
return singleInstance;
}
// ...
~Singleton() {}
};
Singleton Singleton::singleInstance = nullptr;
std::mutex Singleton::mutex;
```
这里虽然用锁解决了线程安全问题（至少大部分情况下），但内存管理（`new` 和 `delete`）的问题依然存在。而且，每次访问都需要加锁，性能上会有损耗。
C++11 的绝招：函数内的静态变量 (Magic Static) 的进化
C++11 标准在语言层面解决了函数内静态变量的初始化问题，使其局部静态变量的初始化是线程安全的。这简直是为单例模式量身定做的！
让我们看看 C++11 推荐的单例模式实现方式：
```c++
include
include
class Singleton {
public:
// 1. 禁止拷贝构造函数和拷贝赋值运算符
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
// 2. 提供一个公共的静态方法来获取实例
static Singleton& getInstance() {
// 这是 C++11 的魔法所在：函数内的静态变量初始化是线程安全的。
// 当第一次调用 getInstance() 时，singletonInstance 会被初始化。
// 如果有多个线程同时尝试初始化，编译器和运行时会确保只初始化一次。
static Singleton singletonInstance;
return singletonInstance;
}
// 3. 演示其他成员函数
void showMessage() {
std::cout << "Hello from Singleton instance! My address is: " << this << std::endl;
}
private:
// 4. 私有构造函数，阻止外部直接创建对象
Singleton() {
std::cout << "Singleton constructor called. Instance created at: " << this << std::endl;
}
// 5. 私有析构函数 (可选，但推荐使用)
// 注意：当静态变量被销毁时，它会被自动调用。
// 如果你的析构函数有副作用（比如释放资源），这里需要谨慎处理。
// 对于简单的单例，析构函数可能什么都不做。
~Singleton() {
std::cout << "Singleton destructor called. Instance at: " << this << std::endl;
}
};
// 示例：模拟多个线程访问单例
void thread_function() {
std::cout << "Thread " << std::this_thread::get_id() << " calling getInstance()..." << std::endl;
Singleton& s = Singleton::getInstance();
s.showMessage();
}
int main() {
std::cout << "Main thread starting." << std::endl;
// 第一次获取实例，会调用构造函数
Singleton& s1 = Singleton::getInstance();
s1.showMessage();
// 第二次获取实例，不会再次调用构造函数
Singleton& s2 = Singleton::getInstance();
s2.showMessage();
std::cout << "s1 and s2 point to the same instance: " << (&s1 == &s2) << std::endl;
// 模拟多线程访问
std::thread t1(thread_function);
std::thread t2(thread_function);
t1.join();
t2.join();
std::cout << "Main thread finished." << std::endl;
// 程序退出时，静态对象 singletonInstance 会被自动销毁，
// 并且其析构函数会被调用。
return 0;
}
```
分析一下这段代码，它有什么优点，又需要注意什么：
优点（为什么 C++11 的方式更好）
1. 线程安全（初始化时）：这是最大的亮点。C++11 标准规定，一个函数内部的局部静态变量的初始化是线程安全的。这意味着，当你的程序第一次调用 `Singleton::getInstance()` 时，无论有多少个线程同时进行，编译器和运行时环境都会保证 `singletonInstance` 这个静态局部变量只会被初始化一次。你不再需要手动添加 `std::mutex` 来保护初始化过程。
2. 内存管理自动化：`static Singleton singletonInstance;` 这行代码声明了一个静态局部变量。当程序退出时，这个静态局部变量会被自动销毁，并且它的析构函数也会被自动调用。这彻底解决了之前裸指针管理带来的内存泄漏和析构顺序问题。你不需要手动 `delete`，也不需要担心静态对象的析构顺序混乱。
3. 简洁和易读：相比于手动加锁和管理裸指针的代码，这种方式非常简洁，逻辑也更清晰。一眼就能看出这是单例模式的实现。
4. 懒汉式初始化：单例对象只有在第一次被请求时才会被创建。如果你的单例对象比较“重”（比如需要加载大量配置），这种懒汉式初始化可以避免在程序启动时就消耗大量资源，只有在真正需要的时候才创建。
需要注意的细节
1. 析构函数：
虽然 C++11 解决了析构的自动调用问题，但如果你的单例类的析构函数需要执行一些关键操作（比如关闭数据库连接、保存最终日志等），你需要特别注意析构顺序。
如果你的单例依赖于其他全局或静态变量，而这些变量的析构顺序在你控制之外，并且在你的单例析构之前就被销毁了，那么你的单例析构函数可能会访问到已经不存在的对象，导致运行时错误。
解决析构顺序问题的一个常见策略是：不要让你的单例依赖于其他全局/静态变量。如果必须依赖，可以考虑使用一个全局的管理器类，将所有需要管理的单例对象注册到它里面，然后由这个管理器类统一管理它们的生命周期和析构顺序。
在 C++11 之后，有一个更优雅的解决方案来管理静态对象的初始化和销毁顺序：使用嵌套类或在一个类内部定义静态成员。比如，你可以把 `Singleton` 的创建逻辑放到一个专门的“工厂”类里，这个工厂类也是一个单例。但通常情况下，上面的函数内静态变量的方法已经足够好。
2. 构造函数的参数：
上面的示例中，`Singleton()` 是一个无参构造函数。如果你的单例需要在创建时接受参数，事情就变得复杂一些。
解决方案：
通过 `getInstance` 传递参数：但这样会使 `getInstance` 的签名改变，并且如果第一次调用和后续调用传递的参数不同，如何处理是个问题。通常我们会要求第一次调用传递必要的参数。
```c++
// 简化示例，实际需要更严谨的处理
class Singleton {
public:
static Singleton& getInstance(const std::string& config) {
static Singleton singletonInstance(config); // 传递参数给构造函数
return singletonInstance;
}
// ...
private:
Singleton(const std::string& cfg) : config_(cfg) {
std::cout << "Singleton constructor with config: " << config_ << std::endl;
}
std::string config_;
};
```
这种方式的问题在于，你无法强制用户在第一次调用 `getInstance` 时提供参数，或者他们可能会在后续调用中提供不同的参数。而且，你需要确保所有调用者都知道需要传递的参数。
使用一个配置类：将所有配置信息封装在一个单独的配置类（或者结构体）中，这个配置类本身也可以是单例，或者由外部在程序启动时创建并初始化好。然后，你的单例在创建时（通过 `getInstance` 传递配置类的实例或其引用）来使用这些配置。
3. 避免全局状态的滥用：
虽然单例模式很有用，但过度使用会导致代码的耦合度增高，难以测试和维护。每一个单例对象都相当于一个全局变量，如果你的程序充斥着各种单例，你很难追踪某个状态的变化是由哪个部分引起的。
在设计时，先考虑一下是否真的需要一个全局唯一的实例，或者是否有更合适的替代方案（比如依赖注入、工厂模式等）。
为什么不要再用双重检查锁定 (DCLP) 了？
在 C++11 之前，为了实现线程安全的懒汉式单例，一种流行但复杂的模式是双重检查锁定。它看起来是这样的：
```c++
// C++11 之前的 DCLP 示范 (通常被认为是有问题的)
include
class SingletonDCLP {
private:
SingletonDCLP() {}
SingletonDCLP(const SingletonDCLP&) = delete;
SingletonDCLP& operator=(const SingletonDCLP&) = delete;
static SingletonDCLP instance;
static std::mutex mutex_;
public:
static SingletonDCLP getInstance() {
if (instance == nullptr) { // 第一次检查，不加锁
std::lock_guard
if (instance == nullptr) { // 第二次检查，加锁后再次检查
instance = new SingletonDCLP();
}
}
return instance;
}
~SingletonDCLP() {
// 还需要手动 delete 并且处理析构顺序
}
};
SingletonDCLP SingletonDCLP::instance = nullptr;
std::mutex SingletonDCLP::mutex_;
```
为什么它在 C++11 之前就有问题？
1. 内存模型问题：即使加了锁，现代编译器和处理器为了性能，可能会对写操作（如 `new SingletonDCLP()`）进行重排序。也就是说，`instance = new SingletonDCLP();` 这句话的三个步骤——分配内存、调用构造函数、将内存地址赋给 `instance`——可能不是严格按照这个顺序执行的。如果在赋值给 `instance` 之后，构造函数还没完成，另一个线程进来检查 `instance` 时发现它不再是 `nullptr`，就直接返回了一个未完全构造好的对象，这会导致未定义行为。
2. 锁的性能开销：每次调用 `getInstance` 都要进行两次检查，并且在创建实例之前都需要加锁，这在多线程环境下会有性能损耗。
C++11 如何解决这个问题？
C++11 通过标准化的内存模型和原子操作，使得局部静态变量的初始化成为可能，并且保证了其线程安全。它实际上是语言层面内置的、高效的 DCLP 实现。所以，在你使用 C++11 或更高版本时，根本不需要自己去实现一个复杂的 DCLP，直接用函数内的静态变量就搞定了。
总结一下
在 C++11 及之后，实现线程安全的单例模式最优雅、最简洁、也最推荐的方式就是利用函数内局部静态变量。它集成了线程安全初始化和自动内存管理，让你从许多 C++11 之前的陷阱中解脱出来。
关键在于：
私有化构造函数和拷贝操作：防止外部随意创建和复制。
提供一个公共的静态 `getInstance` 方法：这是唯一的访问入口。
在 `getInstance` 方法内部声明一个静态局部变量：`static Singleton instance;` 这是核心。
返回该静态变量的引用。
记住，虽然 C++11 简化了单例的实现，但设计时的审慎仍然是必不可少的。考虑清楚为什么需要单例，以及它的生命周期和潜在的依赖关系，才能写出健壮的代码。
网友意见
对于简单的、不需要反复释放重建的单例，C++11之后正确方式如 @Alives 高赞答案。我来解释一下另一个常用方法有什么问题：
// header file class MyClass { public: static MyClass instance; } // impl file MyClass MyClass::instance; 最大的问题是：函数内static变量的构造顺序可预测，第一次访问时创建，程序退出（或DLL卸载时）以创建的反顺序销毁。而如果写成全局变量（或类内static成员），其构造顺序不定，只能保证以“某种顺序”在main函数之前完成构造，以反顺序销毁。这样一来，如果存在复杂的交互，可能会访问到未被构造的空对象。
类似的话题
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有