c++如何实现各种设计模式之单例_c++ 静态局部变量实现的线程安全【案例】
C++11起最简可靠的单例实现是函数内static局部变量，天然线程安全、懒加载、自动析构；需删除拷贝/移动操作符；优于std::call_once+指针或全局static变量。
单例模式在 C++11 之后用 static 局部变量最简实现
只要编译器支持 C++11（如 GCC 4.8+、Clang 3.3+、MSVC 2015+），static 局部变量的初始化天然线程安全，无需手动加锁或双重检查。这是目前最推荐、最简洁、最可靠的单例写法。
原因在于：C++11 标准明确要求，static 局部变量的首次初始化必须是原子的，编译器会自动生成保护逻辑（如 GCC 用 __cxa_guard_acquire 等机制）。
- 不依赖
std::call_once或std::mutex，无额外依赖和性能开销 - 自动满足“懒加载”（首次调用
instance()时才构造） - 析构由运行时在程序退出时自动管理，顺序符合静态对象规则
- 禁止拷贝/移动：需显式删除
copy constructor、assignment operator和move相关函数
class Logger {
public:
static Logger& instance() {
static Logger inst; // ✅ C++11 起线程安全
return inst;
}
void log(const std::string& msg) { /* ... */ 
}private:
Logger() = default;
~Logger() = default;
Logger(const Logger&) = delete;
Logger& operator=(const Logger&) = delete;
Logger(Logger&&) = delete;
Logger& operator=(Logger&&) = delete;
};
为什么不用 std::call_once + static 指针？
这种写法（也叫“Meyers 单例”的变体）虽然可行，但多此一举，且容易出错：
}-
std::call_once增加了不必要的函数调用开销和状态管理（std::once_flag） - 手动
new出的对象不会自动析构，必须显式注册atexit或靠std::shared_ptr管理，否则泄漏 - 若忘记删除拷贝/移动函数，可能意外复制出多个实例
- 相比
static局部变量，代码更长、可读性更低、出错面更大
除非你被迫使用 C++03 编译器（已极少见），否则完全没必要走这条路。
常见误用：把 static 变量声明在类外或全局作用域
以下写法看似简单，实则破坏单例语义或引入线程风险：
-
static Logger g_logger;→ 全局对象，非懒加载；多个翻译单元中可能重复定义（ODR 违反）；初始化顺序不可控 -
static Logger* p_inst = nullptr;→ 首次赋值非原子，多线程下可能多次构造 - 在头文件中定义
inline static Logger inst;（C++17）→ 虽线程安全且懒加载，但不如局部static直观，且部分旧工具链支持不佳
坚持用函数内 static 局部变量，是最小、最可控、标准保证最充分的选择。
注意：静态局部变量的析构时机与生命周期
析构发生在主线程退出、main() 返回之后，且按构造逆序执行。这意味着：
- 其他静态对象的析构函数中调用
Logger::instance()是未定义行为（可能已被析构） - 若单例内部持有对其他静态对象的引用（尤其是跨编译单元），可能出现“静态析构顺序惨案”（Static Initialization Order Fiasco 的反向版本）
- 日志类等基础设施建议避免在析构阶段做复杂操作（如刷盘、网络发送），以防崩溃或死锁
真正健壮的单例不是“写出来就行”，而是得想清楚它活到什么时候、跟谁一起活、谁先死谁后死——这点比线程安全更常被忽略。
