加载失败
原文是一篇比较不同 C++ 单例实现性能的文章，结论倾向于通过类静态成员减少 guard 检查以换取更快的访问速度。评论集中讨论这种微优化的语义和安全代价：C++11 对函数局部静态（Meyers singleton）的线程安全初始化是语言保证，底层由 __cxa_guard_* 等机制实现；而类静态成员会绕开该保证并引入跨 translation unit 的初始化顺序风险（static initialization order fiasco）。评论者普遍建议先用 profiling 验证瓶颈，再在必要时采用 std::call_once、显式 init 或架构调整等更稳妥的方案，而不是牺牲语言保证换取微小性能。
评论指出 C++11 对函数局部静态（block-local static）的线程安全初始化是语言层面的保证，而非实现细节；编译器在生成代码时使用 __cxa_guard_acquire / __cxa_guard_release 等 guard 机制在汇编层面实现这一合同。把单例改成类的静态数据成员就绕开了这个保证，程序员必须自行承担线程安全和初始化的责任。跨 translation unit（编译单元）的静态初始化顺序不确定（static initialization order fiasco），如果在某个全局初始化期间访问另一个尚未初始化的单例，会导致未定义行为；因此函数局部静态的懒初始化（Meyers singleton）被广泛采用以规避此类问题。
多位评论者认为这是典型的提前优化问题，强调“PROFILE BEFORE YOU OPTIMIZE”的原则：先用剖析工具确认是否真有瓶颈。守卫检查在大多数代码中代价很小——初始化后通常只是一条原子检查，但在极端高频场景（例如每秒调用数百万次的日志单例）中，原子检查曾被剖析出约占 3% CPU 的开销。评论建议若单例访问成为性能热点，应优先重构架构或在有证据的情况下优化实现，而不是盲目替换以换取微小指令节省。
评论给出几种更稳妥的替代方案：使用 std::call_once 来显式保证一次性线程安全初始化，或用带显式 init 函数的 struct/静态成员来控制初始化时机和顺序。显式的初始化顺序管理或手动 init 可以避免跨 TU 的不确定性，但会引入更多样板和复杂性。对于控制生命周期、可选实例化和可配置初始化的需求，这些显式方案往往比牺牲语言保证的微优化更可维护。
评论强调真实世界的单例设计通常需要延迟/基于配置的初始化、可选实例化、状态回收和受控销毁等功能，而这些是函数局部静态（懒初始化）天然支持的。把实例变为类静态成员会在启动时无条件初始化，丢失 lazy-init 和基于配置控制实例化的能力，从而在设计上变得僵化。因此在很多项目中，为了可配置性和可维护性，开发者宁可接受微小性能开销也要保留懒加载；若确实遇到访问瓶颈，应优先考虑架构调整而非单点微优化。
function-local static / block-local static（函数局部静态）: C++11 对函数体内的静态变量提供线程安全的首次初始化保证（lazy initialization），在首次调用时构造，通常由编译器生成的 guard 机制实现。
__cxa_guard_acquire / __cxa_guard_release: 编译器/运行时导出的低级 guard API，编译器在生成函数局部静态初始化代码时调用这些函数以实现互斥/一次性初始化，在汇编中可见为守卫检查与同步序列。
static initialization order fiasco（静态初始化顺序问题）: 跨 translation unit（编译单元）的全局或静态对象在程序启动阶段的初始化顺序未定义，如果一个对象在其构造期间访问了另一个尚未初始化的对象，会导致未定义行为（UB）。
std::call_once: C++ 标准库提供的线程安全一次性执行工具，可以显式地保证某个初始化函数只被执行一次，是实现单例或延迟初始化的替代方案。
Meyers singleton: 一种常见的单例实现惯用法，使用函数局部静态变量来实现单例，利用 C++11 的线程安全和懒初始化特性实现简单可靠的单例模式。
translation unit（TU，编译单元）: 源文件及其包含的头文件组成的独立编译单元，不同 TUs 之间的静态/全局对象初始化顺序不受定义，因此会引发初始化顺序相关的问题。