如何强制模板化只读单例函数的对象提前构造以规避线程竞争？

我代码库里有个被大量调用的简单模板函数：

// 返回指定类型默认构造对象的只读引用
template <typename T> const T & GetDefaultObjectForType()
{
   static const T _defaultObject{};
   return _defaultObject;
}

这个函数在模板代码里很实用，能让模板代码直接访问模板参数类型的默认构造对象，无需手动构造。

但多线程调用时，helgrind提示存在竞态条件。原因是g++对该函数的底层实现大致如下（伪代码）：

template <typename T> const T & GetDefaultObjectForType()
{
   static char _defaultObject[sizeof(T)];
   static std::atomic<bool> _isConstructed = false;
   if (_isConstructed == false)
   {
      _isConstructed = true;
      new (_defaultObject) T();  // 按需构造对象！
   }
   return reinterpret_cast<const T &>(_defaultObject);
}

helgrind检测到线程A调用时写入对象（构造过程），线程B调用后立即读取，判定为竞态条件。

我不确定这是真实的问题还是helgrind误报，但想知道：有没有办法让这个对象在main函数启动前后（所有线程创建前）就构造完成，让所有调用的线程都将其视为真正的只读单例？

手动在main()开头调用GetDefaultObjectForType<EveryTypeIUse>()的方案维护成本太高——用到的类型太多，容易遗漏，还会让main.cpp引入大量原本不需要的头文件。

1. 借助全局模板类触发预初始化 #

创建一个模板预初始化类，在其构造函数中调用目标函数，然后为每个需要提前初始化的类型声明静态全局实例：

template <typename T>
struct PreInitializer {
    PreInitializer() {
        GetDefaultObjectForType<T>(); // 触发对象构造
    }
};

// 示例：针对MyType提前初始化，可放在MyType的头文件中
static PreInitializer<MyType> myTypePreInit;

• 优势：无需修改main.cpp，每个类型的初始化代码可随类型定义放置，降低遗漏概率，也不会让main.cpp引入多余头文件。
• 劣势：每个需要预初始化的类型都要加一行声明，但若类型本身有对应的头文件，这个操作成本很低。

2. 改用全局模板静态对象替代函数内静态变量 #

重构原函数，依赖全局模板类的静态成员，利用C++全局静态变量在main前初始化的特性：

template <typename T>
struct DefaultObjectHolder {
    static const T instance;
};

template <typename T>
const T DefaultObjectHolder<T>::instance{};

template <typename T> const T & GetDefaultObjectForType()
{
   return DefaultObjectHolder<T>::instance;
}

• 原理：C++中，命名空间级别的静态变量会在程序启动阶段（main执行前）完成初始化，每个T对应的instance会在该模板特化首次被引用时（仍在main前）完成构造。
• 注意事项：若T的默认构造依赖其他全局变量的初始化顺序，可能出现静态初始化顺序问题；但对于无依赖的简单构造（如POD类型、独立类），完全适用。
• 优势：彻底消除多线程竞态——对象在所有线程创建前已构造完成，函数仅返回只读引用，无运行时条件判断或构造逻辑。
• 劣势：若T初始化成本高，会增加程序启动时间，但原本的函数也是首次调用时才初始化，只是将时机提前到了启动阶段。

3. 忽略helgrind误报（针对C++11及以上） #

从C11开始，标准明确规定函数内的静态变量初始化是线程安全的：多个线程同时调用时，仅一个线程执行初始化，其他线程会等待初始化完成。g的实现符合标准，helgrind的提示可能是误报。

若确认T的默认构造无线程不安全操作（默认构造通常不会有），可直接忽略该警告，或给helgrind添加规则屏蔽此函数的竞态提示。

• 优势：无需修改代码，成本最低。
• 劣势：若T的构造确实存在线程不安全的共享资源访问，该竞态就是真实问题，不能忽略。

内容的提问来源于stack exchange，提问作者Jeremy Friesner