thread_local+std::thread在MSVC下析构死锁，求分析未定义行为

问题现象 #

• 使用MSVC 19.29.30148编译目标代码时，会在std::jthread析构阶段触发死锁，死锁时机不确定：有时发生在std::cout输出前，有时在输出后。
• 该问题仅在MSVC环境复现，其他编译器（如GCC、Clang）及平台运行正常，且静态、动态运行时均能稳定复现，疑似与thread_local存储特性相关。

目标代码 #

#include <thread>
#include <memory>
#include <iostream>

int main(void)
{
    std::thread t2(
        [&] {
            thread_local std::jthread asd([] {
                    std::cout << "ASD" << std::endl;
                    });
        });
    if (t2.joinable()) { t2.join(); }
}

问题分析 #

代码逻辑拆解 #

1. 主线程创建线程t2，t2的lambda内部定义了一个thread_local的std::jthread对象asd。
2. thread_local变量的生命周期绑定到线程：线程首次进入变量作用域时初始化，线程退出时自动销毁。
3. std::jthread的核心特性是析构时会自动join内部关联的线程，确保线程执行完成后才销毁自身。

死锁根源 #

MSVC的线程本地存储（TLS）销毁机制存在实现层面的锁竞争：

• 当t2线程执行完毕准备退出时，MSVC运行时会持有一个用于管理TLS变量销毁的内部锁，然后开始销毁thread_local的asd对象。
• asd的析构函数会尝试join其内部线程，这个操作需要获取线程同步相关的锁（如线程状态锁）。
• 此时出现锁持有顺序反转：TLS销毁锁先被持有，再尝试获取线程同步锁；而某些场景下线程同步锁可能先被其他逻辑持有，进而触发循环等待，导致死锁。

这属于C++标准定义的未定义行为——因为标准仅规定了thread_local变量的生命周期边界，并未对其销毁过程中的同步细节做强制约束，不同编译器的实现差异可能引发此类平台特定问题。

解决方案 #

方案1：移除thread_local修饰 #

将asd的生命周期限制在lambda作用域内，避免TLS销毁流程介入：

#include <thread>
#include <memory>
#include <iostream>

int main(void)
{
    std::thread t2(
        [&] {
            std::jthread asd([] {
                    std::cout << "ASD" << std::endl;
                    });
        });
    if (t2.joinable()) { t2.join(); }
}

方案2：主动控制jthread的同步时机 #

在t2线程退出前，主动完成asd内部线程的同步，避免析构时触发锁竞争：

#include <thread>
#include <memory>
#include <iostream>

int main(void)
{
    std::thread t2(
        [&] {
            thread_local std::jthread asd([] {
                    std::cout << "ASD" << std::endl;
                    });
            // 主动请求停止并等待内部线程完成
            asd.request_stop();
            asd.join();
        });
    if (t2.joinable()) { t2.join(); }
}

内容的提问来源于stack exchange，提问作者Ibraim Ganiev