C++ Static变量跨平台、多线程安全性分析

本人从事网路安全工作12年，曾在2个大厂工作过，安全服务、售后服务、售前、攻防比赛、安全讲师、销售经理等职位都做过，对这个行业了解比较全面。

最近遍览了各种网络安全类的文章，内容参差不齐，其中不伐有大佬倾力教学，也有各种不良机构浑水摸鱼，在收到几条私信，发现大家对一套完整的系统的网络安全从学习路线到学习资料，甚至是工具有着不小的需求。

最后，我将这部分内容融会贯通成了一套282G的网络安全资料包，所有类目条理清晰，知识点层层递进，需要的小伙伴可以点击下方小卡片领取哦！下面就开始进入正题，如何从一个萌新一步一步进入网络安全行业。

需要体系化学习资料的朋友，可以加我V获取：vip204888 （备注网络安全）

学习路线图

其中最为瞩目也是最为基础的就是网络安全学习路线图，这里我给大家分享一份打磨了3个月，已经更新到4.0版本的网络安全学习路线图。

相比起繁琐的文字，还是生动的视频教程更加适合零基础的同学们学习，这里也是整理了一份与上述学习路线一一对应的网络安全视频教程。

网络安全工具箱

当然，当你入门之后，仅仅是视频教程已经不能满足你的需求了，你肯定需要学习各种工具的使用以及大量的实战项目，这里也分享一份我自己整理的网络安全入门工具以及使用教程和实战。

项目实战

最后就是项目实战，这里带来的是SRC资料&HW资料，毕竟实战是检验真理的唯一标准嘛~

面试题

归根结底，我们的最终目的都是为了就业，所以这份结合了多位朋友的亲身经验打磨的面试题合集你绝对不能错过！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以点击这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

-fno-threadsafe-statics

Do not emit the extra code to use the routines specified in the C++ ABI for thread-safe initialization of local statics. You can use this option to reduce code size slightly in code that doesn’t need to be thread-safe.

• CLANG

本机apple 的clang编译器版本为12.0.5，由于Apple未明确支持多线程析构构造版本，只写了一个Yes， 所以还不清楚什么版本支持。后续会看到实际看到的效果，属于部分支持。

Apple clang version 12.0.5 (clang-1205.0.22.11)

Target: x86_64-apple-darwin20.3.0

Thread model: posix

▐  构造检测程序

编写测试程序的最终版本如下，此版本是经过了反复调整，力求增大复现问题的概率。

#include

#include

#include<unistd.h>

#define TAG “MY_TEST”

#define MY_DEBUG printf // add your platform timestamp threadid

class Machine

{

public:

Machine(int year_) : year(year_) {

MY_DEBUG(“before construct Machine:%p, thread:%d, year:%d”, this, year_, year);

MY_DEBUG(“after construct Machine:%p, thread:%d, year:%d”, this, year_, year);

}

~Machine() {

MY_DEBUG(“before destruct, year:%d”, year);

year = -1;

MY_DEBUG(“after destruct, set -1”); // -1 as invalid static data.

}

int GetData() const {

return year;

}

int year;

};

static const Machine golbalMachine(100); // 100 as global static valid data

const Machine &GetMachine(int index)

{

const static Machine machine(index);

MY_DEBUG(“return object for thread: %d. machine:%p, year:%d, globalMachine:%p, globalYear:%d”, index, &machine, machine.GetData(), &golbalMachine, golbalMachine.GetData());

return machine;

}

void CheckStaticVariable() {

std::thread t1(GetMachine, 1);

std::thread t2(GetMachine, 2);

std::thread t3(GetMachine, 3);

MY_DEBUG(“t1 detach”);

t1.detach();

MY_DEBUG(“t2 detach”);

t2.detach();

MY_DEBUG(“t3 detach”);

t3.detach();

// MY_DEBUG(“t1 join”);

// t1.join();

// MY_DEBUG(“t2 join”);

// t2.join();

// MY_DEBUG(“t3 join”);

// t3.join();

}

int main() {

MY_DEBUG(“start main\n”);

CheckStaticVariable();

exit(0); // in order to auto complete ios app main thread.

return 0;

}

linux 平台实测

在Ubuntu机器上用GCC和CLANG两种编译器运行测试。

Description: Ubuntu 20.04.2 LTS

Release: 20.04

g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0

clang version 10.0.1

Target: x86_64-unknown-linux-gnu

Thread model: posix

▐  实测

• GCC

使用GCC编译器，编译运行上述程序, 在shell中持续循环运行多次，静态变量析构都发生在线程执行完成之后。得到如下结果。GetMachine函数得到的全局、局部静态变量数值都是大于0的有效值，并非-1.

使用fno-threadsafe-statics制造不安全场景, 大规模循环执行后，复现了子线程读取到错误数据的case，此局部静态变量已经析构。由于实验的是简单数据类型, 并没有crash。如果是访问析构后的复杂对象，则可能crash。 而且从多线程发生重复竞争构造同一个静态对象，重复析构同一个静态对象。

同时发现，在大量循环后，全局静态变量始终在子线程访问结束后才析构，与gcc 编译器的说明是对应的，也就是说这个特性一直打开，不受fno-threadsafe-statics影响，此选项只影响局部静态变量。

• CLANG

使用 clang编译器，编译运行上述程序, 在shell中持续循环运行多次，静态变量析构都发生在线程执行完成之后。多线程安全。

使用fno-threadsafe-statics制造不安全场景, 大规模循环执行后，可复现了子线程读取到错误数据的case，此局部静态变量已经析构。

▐  汇编分析

为了进一步查看区别和原因，使用GCC编译器编出汇编代码继续分析，使用fno-threadsafe-statics选项得到不安全的汇编代码，对应下图左侧，右侧为静态变量多线程安全代码。将符号demangle后分析差异。

g++ -std=c++11 -pthread -S static_thread.cpp -o static_thread_gcc_x64.S

g++ -std=c++11 -pthread -fno-threadsafe-statics -S static_thread.cpp -o static_thread_gcc_x64_unsafe.S

threadstatic# c++filt _ZGVZ10GetMachineiE7machine

guard variable for GetMachine(int)::machine

threadstatic# c++filt _ZZ10GetMachineiE7machine

GetMachine(int)::machine

threadstatic# c++filt _ZN7MachineC1Ei

Machine::Machine(int)

/threadstatic# c++filt _ZN7MachineD1Ev

Machine::~Machine()

_ZZ10GetMachineiE7machine为 GetMachine(int)::machine 函数调用， _ZN7MachineC1Ei 为Machine类的构造函数。线程安全版本在调用GetMachine时先通过__cxa_guard_acquire获取了guard锁，call _ZN7MachineC1Ei 调用Machine类构造局部静态对象之后，再用__ __cxa_guard_abort 和 __cxa_guard_release 释放锁。最后把析构函数_ZN7MachineD1Ev用__cxa_atexit 注册到程序退出函数表中。

从gcc说明文档也可以看到这个信息：

// The actual code emitted by GCC to call a local static variable’s constructor looks something like this:

static guard;

if (!guard.first_byte)

{

if (__cxa_guard_acquire (&guard))

{

bool flag = false;

try

{

// Do initialization.

__cxa_guard_release (&guard);

flag = true;

// Register variable for destruction at end of program.

}

catch

{

if (!flag)

{

__cxa_guard_abort (&guard);

}

}

}

}

在实测部分，大量循环后，全局静态变量始终在子线程访问结束后才析构，说这个特性一直打开，不受fno-threadsafe-statics影响，所以汇编代码无法对比出差异，受时间限制暂未去找实现的原理。

Apple 平台实测

▐  Apple IOS

Clang 12.0.5

保持xcode工程的 Statics are Thread-Safe 选项打开。设定optimization level为-O0，无优化。

手动在iphone XS上运行测试代码，出现下图问题，子线程访问到-1数据时，主线程在调用_exit函数退出，触发_cxa_atexit中注册过的静态变量析构函数。由于实验的是简单数据类型, 并没有crash。如果是访问析构后的复杂对象，则可能crash，正好对应线上crash的场景。

// 线上crash堆栈

Thread 0:

1 libsystem_c.dylib 0x0000000197db7064 __cxa_finalize_ranges :416 (in libsystem_c.dylib)

2 libsystem_c.dylib 0x0000000197db73a0 _exit :28 (in libsystem_c.dylib)

3 UIKitCore 0x000000019c2301a4 -[UIApplication _terminateWithStatus:] :508 (in UIKitCore)

复制

而linux平台只有关闭线程安全选项fno-threadsafe-statics后才会出现。正常编译下静态变量构造和析构都是安全的。说明此clang+ios并未实现完整的Dynamic Initialization and Destruction with Concurrency.

IOS MNN crash的根源在于Apple clang编译器和运行时库未实现静态变量析构的多线程安全。

▐  Apple Mac

Apple clang version 12.0.5 (clang-1205.0.22.11)

Target: x86_64-apple-darwin20.3.0

Thread model: posix

在mac下使用Apple clang编译，静态变量线程安全选项默认打开情况下，仍然可以复现此问题, 和ios的情况一致。

clang++ -std=c++11 -pthread static_thread.cpp -o static_thread_clang_mac

android平台实测

▐  NDK Clang

Android (7019983 based on r365631c3) clang version 9.0.9 (https://android.googlesource.com/toolchain/llvm-project a2a1e703c0edb03ba29944e529ccbf457742737b) (based on LLVM 9.0.9svn)

Target: x86_64-apple-darwin20.3.0

Thread model: posix

android NDK r21e的clang版本为9.09， 大于了c++11此特性标注的clang 2.9， 编译测试代码，执行可以看到构造过程仍然保证只构造一次, thread1 线程号15623， GetMachine取到的局部和全局静态变量都是-1，因为局部和全局静态变量析构函数已经早于此线程调用GetMachine执行了。此版本析构过程线程不安全。说明此clang+ndk库并未实现完整的 Dynamic Initialization and Destruction with Concurrency.

我手头的ndk版本不高，哪位同学如果有更高版本，方便的话可编译运行一下此测试程序。

▐  aarch64 GCC

Using built-in specs.

COLLECT_GCC=aarch64-linux-gnu-g++

COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/aarch64-linux-gnu/9/lto-wrapper

Target: aarch64-linux-gnu

Thread model: posix

gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)

由于android NDK r18以后已经不再支持GCC编译器，暂且使用GCC arm交叉编译工具 aarch64-linux-gnu-g++ 尝试运行测试程序。在执行后有不兼容的异常， 反复执行多次，构造函数只执行一次，GetMachine日志显示都能得到正确的结果year:1, globalYear:100， 并未出现析构后的-1数值。虽然不完全肯定，初步可以说明 GCC在安卓上静态变量多线程安全**。**

解决办法

虽然c++11标准有约束，但对析构时的多线程和静态变量的关系不是所有编译器和库完整实现，GCC编译器中做了完整实现，实验过的Apple/Android clang编译器版本只支持构造、不支持析构的多线程安全，微软编译器则在VS2015后支持。

追溯解决：** 如要继续追溯析构时的行为差异，不仅是编译器，需要从apple clang编译器代码与std库的某种共同作用着手，这个涉及到一个全新的领域了，暂无法去继续调查，后续暂且给clang或apple提一个issue。

规避解决1： 对于IOS 中遇到的析构时多线程异常问题，虽然本来静态变量并不多，而且语法规范是线程安全的，由于不同厂商编译器和库实现程度不同，MNN又需要做到IOS android linux windows跨平台，我们的解决办法是避免使用static变量或对象，牺牲一些重复创建对象的开销，也要想方设法改成非静态变量****。 也可以自行加锁，访问、析构前都加锁来避免。

再回到开头的两个经典模式，我们不难发现Meyers Singleton 在gcc编译器下是多线程构造、析构安全的。真是一个表面简单而实际不简单的模式！岁月静好地写代码时有众多大牛思想的结晶在默默守卫。如果要跨平台到IOS上，可要小心了，析构的时候可能发生多线程访问crash。如果自己保证先退出多线程，也是ok的。

Gamma Singleton 构造、析构线程安全吗？它的全局变量是一个指针，简单类型不要调用构造析构。无论哪个编译器和平台。再看构造过程：而多线程调用getInstance时，即使 if判断是原子化的，但m_pInstance = new Singleton() 会多线程竞争创建，并没有实现 the concurrent execution shall wait for completion of the initialization 的特性。所以构造阶段多线程不安全****！析构阶段：静态变量指针m_pInstance 只是会成为释放的内存，多线程读写情况，也有可能变成野指针了！另外开头的示例代码还隐藏一个重要bug, 那就是没有析构对象。所以要自行找到合适的时机，自行加锁、析构Instance。这个单例模式在严格的多线程下问题还不少。

规避解决2： 借助Gamma Singleton，如果保证没有不释放的外部资源，那么我们可以参考gamma singleton构造新的规避方案，不析构释放静态对象，避免多线程不安全，从读者评论里，借鉴到以下非常独特的方法。注意用户一定要保证static对象中不持有一些需要手动释放的资源，例如有的系统连malloc的堆内存都不会析构后自动释放；有的static对象持有的系统设备不会被自动释放；有的则持有跨进程注册的自定义服务不会被自动释放。

// Thread Safe Singleton

// caution: this kind of Singleton should not hold any resource that your OS would not auto-release when program went to an end.

class Singleton {

public:

static Singleton& getInstance() {

static Singleton& instance = *(new Singleton()); // multi-thread safe.

return instance;

}

private:

Singleton();

}

// no global static

总结

通过一系列分析和实验、数据分析，找到了IOS MNN crash的根源在于Apple clang编译器和运行时库对c++11 Dynamic Initialization and Destruction with Concurrency特性的支持问题，未实现静态变量析构的多线程安全。得到了多平台的线程安全性和各个影响因素的关系。

1. 静态变量的多线程访问安全性和c++版本和运行时库、编译器有关，c++11标准standard6.7 [stmt.dcl] 第4节, 3.6.3 Termination [basic.start.term], 要求静态变量构造和析构都要线程安全，实测gcc9.3 (>4.3即可) 已经实现了此特性，称为“Dynamic Initialization and Destruction with Concurrency”。apple clang(12.0.5)编译器只对此特性部分实现，构造阶段实现了，析构阶段未覆盖。需要注意避开。

2. 静态变量的多线程访问安全性和编译选项-fno-threadsafe-statics 有关，此选项在不同编译器中都默认打开，局部静态变量/对象构造安全性默认可以保证；全局静态变量在主线程中构造，早于调用入口函数，不会被多线程构造。

3. 静态变量的多线程访问安全性和多线程启动模式有关，即使在第1点中有问题的编译器上，join模式会等待子线程执行完毕后，主线程才继续向下执行，直到静态变量析构，多线程仍然安全，detach模式，打乱先后顺序，则存在风险。

4. 局部静态变量的多线程访问安全性和调用函数实现形式有关， 如果调用是一个递归函数，则行为未定义。

int foo(int i) {

// judge

static int s = foo(2*i); // recursive call - undefined

return i+1;

}

5. 静态变量的多线程访问安全性和其构造、析构函数有关，如果是异步构造，则编译器的保护还不够，不足以保护其安全，存在多线程竞争风险， 这也是有的规约不建议构造函数内有异步操作的原因之一，一般把异步调用挪到其成员函数中。如果同步构造，则c++11与GCC编译器的Dynamic Initialization and Destruction with Concurrency特性可以保证构造、析构的多线程安全。

默认选项下，静态变量线程安全性关系表汇总如下，前两行是表头表示编译器和c++版本变量，前四列为四种变量。

✿  拓展阅读

作者**|**灵钧

在结束之际，我想重申的是，学习并非如攀登险峻高峰，而是如滴水穿石般的持久累积。尤其当我们步入工作岗位之后，持之以恒的学习变得愈发不易，如同在茫茫大海中独自划舟，稍有松懈便可能被巨浪吞噬。然而，对于我们程序员而言，学习是生存之本，是我们在激烈市场竞争中立于不败之地的关键。一旦停止学习，我们便如同逆水行舟，不进则退，终将被时代的洪流所淘汰。因此，不断汲取新知识，不仅是对自己的提升，更是对自己的一份珍贵投资。让我们不断磨砺自己，与时代共同进步，书写属于我们的辉煌篇章。

需要完整版PDF学习资源

需要体系化学习资料的朋友，可以加我V获取：vip204888 （备注网络安全）

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以点击这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！