关于std::mutex平凡可析构性及静态对象析构调用安全的问询

1. std::mutex 是否为平凡可析构类型？ #

答案是否。

平凡可析构类型的核心要求是：析构函数是编译器自动生成的、无自定义逻辑、也不会触发任何非平凡析构操作的默认析构函数。而std::mutex的析构函数需要执行特定的资源清理——比如释放底层的同步原语、清理内核态的锁资源等，因此它的析构函数是非平凡的，std::mutex自然不属于平凡可析构类型。

你可以用C++标准库的类型特性直接验证这一点：

#include <type_traits>
#include <mutex>

static_assert(!std::is_trivially_destructible_v<std::mutex>, "std::mutex is not trivially destructible");

这段代码能正常编译，正好印证了std::mutex不是平凡可析构类型。

2. 在静态存储期对象bar的析构函数中调用foo()是否安全？ #

答案是不安全，可能触发未定义行为。

问题的核心在于C++对静态存储期对象的析构顺序规则：

• 全局/命名空间级的静态对象（比如你的bar），析构顺序是它们初始化顺序的逆序，这个过程发生在程序退出的早期阶段。
• 函数内的局部静态对象（比如foo()里的m），构造发生在函数第一次被调用时，析构顺序则是构造顺序的逆序。关键是：如果局部静态对象的构造发生在全局静态对象构造之后（比如你在main()里调用foo()，此时所有全局对象已完成构造），那么它的析构会早于全局静态对象的析构。

举个具体的风险场景：

1. 程序启动，全局对象bar先完成构造。
2. main()执行，调用foo()，此时foo()里的局部静态mutex m被构造。
3. 程序退出，进入析构阶段：
   • 按照构造逆序，m会先被析构（因为它的构造在bar之后）。
   • 随后执行bar的析构函数，此时调用foo()会尝试对已经被析构的m加锁——操作已销毁的对象属于未定义行为，可能导致崩溃、死锁或其他不可预测的结果。

哪怕你确保foo()在bar构造前被调用（比如在另一个全局对象的构造函数里调用），风险依然存在：如果那个全局对象的析构顺序在bar之前，m的析构还是会早于bar，触发同样的问题。

修复建议 #

如果需要在全局对象的析构中使用同步机制，推荐：

• 将mutex提升为全局/命名空间级的静态对象，确保它的析构顺序晚于所有依赖它的全局对象；
• 或者使用std::call_once结合静态变量来严格控制同步对象的生命周期，避免析构顺序冲突。

内容的提问来源于stack exchange，提问作者Boris Dalstein