静态数据多实例导致共享库段错误的原因探究

核心原因：静态库代码被重复嵌入 #

你把lib_static.a分别链接到liba.so和libb.so时，静态库里的所有目标文件会被完整复制到每个共享库中——包括单例类的实现、类内静态变量的定义。这就导致：

• 同一个单例类在liba.so和libb.so里各有一份独立的实例
• 那些类内的全局静态变量（比如类内声明、翻译单元定义的static const std::string），也会在两个共享库中各占一块独立的内存空间

段错误与Invalid free的本质 #

std::string、std::vector这类标准库容器会在堆上分配内存，析构时会释放这些内存。当程序退出时：

1. 先析构liba.so里的静态变量/单例实例，释放对应的堆内存
2. 接着libb.so里同名的静态变量/单例实例会尝试去析构已经被释放的内存
3. 这直接触发了valgrind检测到的Invalid free()错误，最终导致段错误

和“静态初始化顺序问题（static initialization order fiasco）”无关 #

这个问题和静态初始化顺序问题完全不是一回事：

• 静态初始化顺序问题是不同翻译单元里的全局静态变量初始化顺序不确定，导致代码用到未初始化的变量
• 你的问题是同一个实体存在多份独立实例，属于重复实例化引发的双重释放问题

背后的Linux共享库行为 #

Linux下的共享库链接有几个关键规则：

• 把静态库链接到共享库时，链接器会把静态库中被引用的目标文件完整嵌入到共享库，不会做跨共享库的符号合并
• 当两个共享库都包含同一符号的定义时，动态链接器默认会选第一个加载的共享库中的符号（符号遮蔽），但静态变量的内存空间是各自独立的——这就可能出现初始化用的是liba.so里的符号，析构却处理libb.so里的实例，或者反过来，最终引发内存错误

可行的解决方案 #

• 把静态库改成共享库：将lib_static.a编译为共享库lib_static.so，让liba.so和libb.so都链接这个共享库，这样所有模块共享同一套实例和静态变量
• 调整单例实现方式：用函数内静态变量的单例模式（static Singleton& getInstance() { static Singleton inst; return inst; }），不过这只能解决单例的重复实例问题，类内全局静态变量还得单独处理
• 合并共享库：如果业务允许，把liba.so和libb.so合并成一个共享库，避免重复链接静态库

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