从一次字符串拼接失败说起

objdump -dj .bss a.out：

a.out:fileformatelf64-x86-64


Disassemblyofsection.bss:

0000000000600aa0:
...

0000000000600aa8:
...

0000000000600ab0:
600ab0:00000000....

0000000000600ab4:
600ab4:00000000....

0000000000600ab8:
600ab8:00000000....

0000000000600abc<_ZL2t3>:
600abc:00000000....

0000000000600ac0<_ZL2t4>:
600ac0:00000000....

0000000000600ac4<_ZL1k>:
600ac4:00000000....

从上述输出可知只有i、l在.data段，其它的在.bss段，还有一个比较有意思的点就是**.bss段的数据都被0进行初始化**，针对这两个问题：

•t1 t2 t3 t4都调用了构造函数(有些是拷贝有些是默认构造函数)进行了初始化，但因为其类型不是POD，所以其被放在bss段

•编译器默认的编译选项是**-fzero-initialized-in-bss，即对bss段进行0初始化，如果不想进行0初始化，可以使用-fno-zero-initialized-in-bss**

针对上面的输出，i、l在.data段，可称之为常量初始化，而其它变量在.bss段且被0初始化，称之为0初始化。从可执行程序的角度来说，如果一个数据未被初始化，就不需要为其分配空间，所以.data 和.bss 的区别就是 .bss 并不占用可执行文件的大小，仅仅记录需要用多少空间来存储这些未初始化的数据，而不分配实际空间，编译器往往通过memset(bss_str, len, 0)进行初始化，类似于如下这种:

staticvoidzero_fill_bss(void)
externchar__START_BSS[];
externchar__END_BSS[];

memset(__START_BSS,0,(__END_BSS-__START_BSS));
}

看到这，可能大家会有个疑问，.bss段什么时候会进行真正的初始化呢？记得一开始接触全局变量和静态变量的时候，书上就有提到，在可执行程序执行之前(main函数运行之前)，会进行一些初始化操作，.bss就是在这个阶段进行初始化的。也就是说.data和.bss段的数据，在main()函数执行之前就初始化完成，那么，可以得出的结论是这部分数据不存在多线程竞争的问题(main()函数执行前还不存在多线程现象)。

根据标准的定义：

Together, zero-initialization and constant initialization are called static initialization; all other initialization isdynamic initialization.

也就是说要将静态变量活全局变量初始化分类的话，可以分为静态初始化和动态初始化，其中静态初始化已经在上面例子中讲到，就是说编译器在编译的过程中完成(包括常量初始化和0初始化两种)，剩下的就是动态初始化：

Dynamic initialization happens at runtime for variables that can’t be evaluated at compile time2. Here, static variables are initialized every time the executable is run and not just once during compilation

动态初始化，又称为运行时初始化或者懒汉式初始化，是指在程序运行阶段才能完成的初始化，比如动态分配的内存，通过函数参数进行初始化赋值，或者使用函数返回值初始化等等，常见于函数调用方式，如下：

intfun(){
staticinta=0;
returna;
}

intmain(){
intx=fun();
return0;
}

初始化顺序

在上一节中，我们聊到了编译器对静态变量的初始化相关知识点，c++标准规定，在同一个编译单元中，对全局变量或者静态变量的初始化顺序与其定义顺序一致。但是对于不同的编译单元中的静态变量的初始化顺序，标准没有做规定，也就是说假如两个全局静态变量A和B分别存在与两个.cc文件中，那么编译器对于这俩的初始化顺序是不确定的，而正是因为这个原因，才是导致了文章开头示例的输出结果不符合语气的关键。对于这种因为不同编译单元初始化顺序导致的异常，cppreference将其称之为Static Initialization Order Fiasco。

Thestatic initialization order fiascorefers to the ambiguity in the order that objects with static storage duration in different translation unitsare initializedin. If an object in one translation unit relies on an object in another translation unit already being initialized, a crash can occur if the compiler decides to initialize them in the wrong order. For example, the order in which .cpp files are specified on the command line may alter this order. The Construct on First Use Idiom can be used to avoid the static initialization order fiasco and ensure that all objects are initialized in the correct order.

Within a single translation unit, the fiasco does not apply because the objects are initialized from top to bottom.

继续回到文章开头的示例，在程序执行main()函数之前，进行初始化操作，因为没有规定不同编译单元中的初始化顺序，所以先初始化main.cc中的静态变量msg为hello world!(因为此时static_test.cc中的str还未进行初始化)，然后再初始化static_test.cc中的静态变量。接着执行main()函数，进行输出操作...

解决

既然出现了因为不同编译单元中的静态变量初始化导致，那么就需要针对性的解决这个问题，通常有如下几个方案：

•将所有的静态全局变量放在一个编译单元中(如果涉及到依赖的话，需要修改顺序)

•强制编译器在编译阶段进行初始化，通常有constexpr和constinit两种

•Initialization On First Use，即在使用时候，通过函数获取静态对象的方式进行初始化：

//static_test.h
#include

staticstd::stringstr;

//static_test.cc
std::stringGetStr(){
str="test";
reurnstr;
}

//main.cc
#include"static_test.h"
#include

staticstd::stringmsg="hello"+GetStr()+"world!";

intmain(){
std::cout<< msg << std::endl;
 }

•指定初始化优先级(即顺序，以下实现仅限于gcc，msvc未做研究)：

//static_test.h
#include

staticstd::stringstr;

//static_test.cc
std::string__attribute__((init_priority(300)))str="test";

//main.cc
#include"static_test.h"
#include

staticstd::string__attribute__((init_priority(400)))msg="hello"+str+"world";

intmain(){
std::cout<< msg << std::endl;
  }

在上述代码中指定了静态变量str的优先级300，msg的优先级400，那么在执行的时候，会先初始化str，然后初始化msg，这样就会得到预期结果。

结语

静态变量在程序中使用很常见，其引起的静态初始化顺序难题也就随之而来，对于这种初始化顺序导致的异常，通过很难察觉，由于标准没有规定执行标准，因此编译器往往也不会给出报错或者警告。所以，在写代码的时候，应该避免这种情况的发生，当有时候不得不使用静态变量的时候，需要注意是否会导致初始化顺序问题，如果遇到了，则开源参考上一节的解决方式~~

审核编辑：汤梓红