蝦皮C++后端一面：解析static析構順序問題 ？
在C++編程的廣闊世界里，static關鍵字猶如一位低調卻又至關重要的幕后英雄，廣泛應用于變量、函數以及類的成員之中 ，發揮著不可或缺的作用。從修飾局部變量以保留其狀態，到限制函數的作用域，再到實現類成員的共享，static的身影無處不在。
然而，在關注static帶來的各種便利時，我們往往容易忽視一個重要的方面 ——static對象的析構問題。析構函數作為對象生命周期結束時的清理機制，對于static對象而言，有著獨特的規則和容易被誤解的地方。這些細節問題，雖然平時可能不常被提及，但一旦在復雜的項目中出現，就可能引發難以排查的錯誤，導致程序運行異常。接下來，就讓我們深入探究static析構的奧秘，揭開它神秘的面紗。
一、static 關鍵字的多面剖析
在深入探討 static 析構順序之前，我們先來全面認識一下 static 關鍵字在 C++ 中的強大功能。它就像一個多面手，在不同的場景下有著不同的神奇效果。
1.1修飾變量
（1）修飾局部變量：當 static 修飾局部變量時，這個局部變量就擁有了 “超能力”—— 持久性。普通的局部變量在函數結束時就會被銷毀，如同曇花一現。但靜態局部變量卻不一樣，它在程序運行期間一直存在，就像一個忠誠的衛士，堅守崗位。它的生命周期從第一次被初始化開始，一直延續到程序結束 。比如，我們在一個函數中定義一個靜態局部變量來統計函數被調用的次數：
void countFunctionCalls() {
static int callCount = 0;
callCount++;
std::cout << "函數被調用了 " << callCount << " 次" << std::endl;
}每次調用countFunctionCalls函數，callCount的值都會保留上一次調用結束時的值，并在此基礎上增加，而不會像普通局部變量那樣每次都重新初始化為 0。
（2）修飾全局變量：static 修飾全局變量時，就像是給這個全局變量戴上了一個 “神秘面紗”，將其作用域限制在了當前文件中。全局變量默認是具有外部鏈接性的，也就是說，在其他文件中可以通過extern關鍵字來訪問它。但被 static 修飾后，它就只能在當前文件中被訪問，其他文件無法窺探到它的存在。
這樣做的好處是可以避免不同文件中同名全局變量的沖突，提高代碼的模塊化和安全性 。例如，在一個大型項目中，可能有多個文件都需要使用一個名為config的配置變量，如果不使用 static 修飾，就需要非常小心地管理這個變量，防止在不同文件中被意外修改。而使用 static 修飾后，每個文件都可以有自己獨立的config變量，互不干擾。
（3）修飾類成員變量：在類中，static 修飾的成員變量就像是一個公共的寶藏，被類的所有對象共享。每個對象都可以訪問和修改這個靜態成員變量，而且對它的修改會影響到所有對象。靜態成員變量不屬于任何一個具體的對象，而是屬于整個類。它的初始化需要在類外進行，例如：
class MyClass {
public:
static int sharedValue;
};
int MyClass::sharedValue = 0;在上面的代碼中，sharedValue是MyClass類的靜態成員變量，在類外進行了初始化。所有MyClass類的對象都可以訪問和修改sharedValue，比如：
MyClass obj1, obj2;
obj1.sharedValue = 10;
std::cout << "obj2的sharedValue: " << obj2.sharedValue << std::endl; // 輸出101.2修飾函數
當 static 修飾函數時，這個函數就變成了一個 “隱士”，它的作用域被限制在了當前文件中。其他文件無法調用這個靜態函數，只有當前文件中的其他函數可以訪問它。這在模塊化編程中非常有用，可以將一些只在當前文件中使用的輔助函數聲明為靜態函數，隱藏實現細節，提高代碼的封裝性 。比如，我們在一個文件中實現一個數學計算模塊，其中有一些內部使用的輔助函數，我們可以將它們聲明為靜態函數：
// mathUtils.cpp
static int add(int a, int b) {
return a + b;
}
int calculateSum() {
int result = add(3, 5);
return result;
}在上面的代碼中，add函數被聲明為靜態函數，只能在mathUtils.cpp文件中被調用，其他文件無法訪問它。這樣可以避免命名沖突，同時也保護了函數的實現細節不被外部隨意修改。
1.3static 成員
（1）static 成員變量
static成員變量是屬于類的，而不是屬于類的某個對象。這意味著無論創建多少個類的對象，static成員變量在內存中都只有一份拷貝，所有對象共享這一份數據 。例如，我們有一個Student類，其中包含一個static成員變量totalStudentCount用于統計學生總數，代碼如下：
class Student {
public:
Student() {
totalStudentCount++;
}
~Student() {
totalStudentCount--;
}
static int getTotalStudentCount() {
return totalStudentCount;
}
private:
static int totalStudentCount;
};
int Student::totalStudentCount = 0;
int main() {
Student s1, s2;
std::cout << "Total students: " << Student::getTotalStudentCount() << std::endl;
return 0;
}在上述代碼中，totalStudentCount 是static 成員變量，在類外進行初始化。每個Student對象創建時，totalStudentCount 會增加；對象銷毀時，totalStudentCount 會減少。通過 Student::getTotalStudentCount() 函數可以獲取當前學生總數 。
static成員變量的內存分配在靜態存儲區，它的生命周期從程序開始到程序結束。與普通成員變量不同，普通成員變量是在對象創建時分配內存，存儲在對象的內存空間中，每個對象都有自己獨立的一份；而 static 成員變量不依賴于對象的創建，即使沒有創建任何對象，也可以訪問static成員變量 。
（2）static 成員函數
static成員函數同樣屬于類，而不是類的對象。它的一個重要特點是沒有this指針，因為它不與任何特定的對象相關聯 。這就導致static成員函數只能訪問靜態成員變量和靜態成員函數，不能訪問非靜態成員。例如：
class MathUtils {
public:
static int add(int a, int b) {
return a + b;
}
private:
static int result;
};
int MathUtils::result = 0;
int main() {
int sum = MathUtils::add(3, 5);
std::cout << "Sum: " << sum << std::endl;
return 0;
}在這個 MathUtils 類中，add 函數是 static 成員函數，它可以直接通過類名調用，無需創建 MathUtils 對象。由于沒有 this 指針，它不能訪問非靜態成員 。相比之下，普通成員函數有 this 指針，它指向調用該函數的對象，因此可以訪問對象的所有成員，包括靜態和非靜態成員 。static 成員函數常用于實現一些與類相關但不依賴于具體對象狀態的操作，比如工具類中的方法、工廠模式中的創建對象方法等 。
二、static析構的原理與規則
析構函數，簡單來說，它的作用與構造函數恰好相反。構造函數是在對象創建時被調用，用于初始化對象的成員變量和資源；而析構函數則是在對象銷毀時被調用，負責清理對象所占用的資源，比如釋放動態分配的內存、關閉打開的文件、斷開網絡連接等 。
析構函數有著獨特的特點。它沒有返回值，連void類型都不能指定，因為它的使命就是默默地完成清理工作，不需要向外界返回任何結果。它的函數名是在類名前面加上波浪號~，以此來表明它是析構函數，與構造函數區分開來 。比如，對于一個名為Student的類，它的析構函數就是~Student()。而且，析構函數不能帶有參數，這就意味著它不能被重載，一個類只能有一個析構函數 。這是 C++ 語言的設計規則，保證了析構函數的唯一性和確定性，讓編譯器能夠準確地在合適的時機調用它。
2.1調用時機
（1）局部對象：當局部對象離開其作用域時，析構函數就會被自動調用。例如，在一個函數內部定義的對象，當函數執行結束，程序的控制權離開這個函數時，這個局部對象的析構函數就會被調用。就像下面這段代碼：
void testFunction() {
class LocalClass {
public:
~LocalClass() {
std::cout << "LocalClass的析構函數被調用" << std::endl;
}
};
LocalClass obj;
}// 當程序執行到這里，obj離開作用域，其析構函數被調用在testFunction函數中，obj是一個局部對象，當函數結束時，obj的析構函數會自動執行，輸出 “LocalClass 的析構函數被調用”。
（2）靜態對象：靜態對象包括靜態局部對象和靜態全局對象，它們的析構函數會在程序結束時被調用。靜態局部對象在函數第一次執行到它的定義處時被初始化，之后在函數多次調用過程中，它不會被重新初始化。而當整個程序結束時，靜態局部對象和靜態全局對象的析構函數才會被調用 。比如：
class StaticClass {
public:
~StaticClass() {
std::cout << "StaticClass的析構函數被調用" << std::endl;
}
};
static StaticClass globalStaticObj;
void anotherFunction() {
static StaticClass localStaticObj;
}
int main() {
anotherFunction();
return 0;
}// 程序結束時，localStaticObj和globalStaticObj的析構函數被調用在這個例子中，globalStaticObj是靜態全局對象，localStaticObj是靜態局部對象，它們的析構函數都會在main函數結束，程序即將退出時被調用。
（3）全局對象：全局對象的析構函數調用時機和靜態對象類似，也是在程序結束時被調用。全局對象在程序啟動時就被創建并初始化，在整個程序運行期間都存在，直到程序結束才會被銷毀，此時其析構函數被調用 。比如：
class GlobalClass {
public:
~GlobalClass() {
std::cout << "GlobalClass的析構函數被調用" << std::endl;
}
};
GlobalClass globalObj;
int main() {
return 0;
}// 程序結束時，globalObj的析構函數被調用在這個代碼中，globalObj是全局對象，當main函數返回，程序即將結束時，globalObj的析構函數會被調用，輸出 “GlobalClass 的析構函數被調用”。
（4）動態創建對象：通過new關鍵字動態創建的對象，需要使用delete關鍵字來手動釋放內存，并且在釋放內存時會調用析構函數。如果不使用delete釋放動態分配的對象，就會導致內存泄漏，這是 C++ 編程中需要特別注意的問題 。例如：
class DynamicClass {
public:
~DynamicClass() {
std::cout << "DynamicClass的析構函數被調用" << std::endl;
}
};
int main() {
DynamicClass* ptr = new DynamicClass();
delete ptr; // 調用DynamicClass的析構函數
return 0;
}在main函數中，我們使用new創建了一個DynamicClass對象，并將其指針賦值給ptr。當我們使用delete ptr時，DynamicClass對象的析構函數會被調用，輸出 “DynamicClass 的析構函數被調用”，然后釋放該對象所占用的內存。如果遺漏了delete ptr這一步，那么這個DynamicClass對象所占用的內存就永遠不會被釋放，造成內存泄漏。
2.2析構函數的特點
析構函數是 C++ 中一種特殊的成員函數，它的主要作用是在對象銷毀時進行一些必要的清理工作，比如釋放對象在生命周期內動態分配的資源，像內存、文件句柄、網絡連接等 。它的定義方式很獨特，函數名是在類名前加上字符~ ，例如，對于類MyClass，其析構函數為~MyClass()。
析構函數有幾個顯著的特性：它沒有參數，也沒有返回值類型，這是因為它的目的純粹是為了清理對象相關的資源，不需要接收額外的信息，也無需返回任何數據給調用者 。而且，一個類只能有一個析構函數，如果用戶沒有顯式定義析構函數，系統會自動生成默認的析構函數 。
不過，默認析構函數通常不會執行實際的清理操作，只是一個空函數體。只有當類中包含需要手動釋放的資源時，才需要用戶自定義析構函數 。當對象的生命周期結束時，比如局部對象在其作用域結束時，動態分配的對象在使用delete操作符時，以及全局或靜態對象在程序終止時，C++ 編譯系統會自動調用析構函數 。例如：
class Resource {
public:
Resource() {
data = new int[10];
std::cout << "Resource constructed" << std::endl;
}
~Resource() {
delete[] data;
std::cout << "Resource destructed" << std::endl;
}
private:
int* data;
};
int main() {
{
Resource res;
}
std::cout << "End of main" << std::endl;
return 0;
}在上述代碼中，Resource類的析構函數負責釋放構造函數中動態分配的整數數組。在main函數中，當res對象離開其作用域時，析構函數會自動被調用，輸出 “Resource destructed”，然后才輸出 “End of main” 。這清晰地展示了析構函數在對象銷毀時自動執行清理工作的特性。
2.3static 對象的析構順序
static對象包括全局static對象和局部static對象，它們的析構順序遵循特定的規則 。根據 C++ 標準，全局static對象的析構順序與它們的構造順序相反 。例如：
class GlobalStaticA {
public:
GlobalStaticA() {
std::cout << "GlobalStaticA constructed" << std::endl;
}
~GlobalStaticA() {
std::cout << "GlobalStaticA destructed" << std::endl;
}
};
class GlobalStaticB {
public:
GlobalStaticB() {
std::cout << "GlobalStaticB constructed" << std::endl;
}
~GlobalStaticB() {
std::cout << "GlobalStaticB destructed" << std::endl;
}
};
GlobalStaticA a;
GlobalStaticB b;
int main() {
std::cout << "Inside main" << std::endl;
return 0;
}在這個例子中，a和b是全局static對象。程序運行時，首先會構造a，輸出 “GlobalStaticA constructed”，然后構造b，輸出 “GlobalStaticB constructed” 。當程序結束時，會先析構b，輸出 “GlobalStaticB destructed”，再析構a，輸出 “GlobalStaticA destructed” 。
對于局部static對象，它們在程序執行流第一次到達其定義處時被構造，析構則發生在程序結束時，并且析構順序也與構造順序相反 。來看下面這個例子：
class LocalStatic {
public:
LocalStatic() {
std::cout << "LocalStatic constructed" << std::endl;
}
~LocalStatic() {
std::cout << "LocalStatic destructed" << std::endl;
}
};
void func() {
static LocalStatic s;
}
int main() {
func();
std::cout << "Inside main" << std::endl;
return 0;
}在func函數中，s是局部static對象。當第一次調用func時，s被構造，輸出 “LocalStatic constructed” 。當程序結束時，s被析構，輸出 “LocalStatic destructed” 。如果在main函數中有多個局部static對象，它們的構造和析構順序也遵循上述規則 。理解static對象的析構順序對于正確管理資源、避免內存泄漏以及確保程序的穩定性至關重要，在復雜的程序中，尤其要注意不同static對象之間可能存在的依賴關系對析構順序的影響 。
三、static 對象析構順序深度解析
3.1單文件內的規則
在單文件的簡單場景下，static 對象的析構順序遵循一個清晰且固定的規則：按照構造順序的相反順序進行析構 。這就好比我們搭建一座積木塔，搭建的過程是從下往上一層一層堆積（構造順序），而拆除的時候則是從上往下一層一層取下（析構順序）。
我們通過具體的代碼示例來直觀感受一下：
#include <iostream>
class StaticObject {
public:
StaticObject(const std::string& name) : m_name(name) {
std::cout << m_name << " 的構造函數被調用" << std::endl;
}
~StaticObject() {
std::cout << m_name << " 的析構函數被調用" << std::endl;
}
private:
std::string m_name;
};
StaticObject globalObj("全局靜態對象");
void testFunction() {
static StaticObject localStaticObj("局部靜態對象");
}
int main() {
testFunction();
return 0;
}在上述代碼中，首先定義了一個StaticObject類，它有一個構造函數和一個析構函數，用于輸出對象的構造和析構信息 。然后，在文件中定義了一個全局靜態對象globalObj，在testFunction函數中定義了一個局部靜態對象localStaticObj 。
當程序運行時，首先會調用全局靜態對象globalObj的構造函數，輸出 “全局靜態對象 的構造函數被調用” 。接著，當testFunction函數被調用時，會調用局部靜態對象localStaticObj的構造函數，輸出 “局部靜態對象 的構造函數被調用” 。
而在程序結束時，析構的順序則與構造順序相反。首先調用局部靜態對象localStaticObj的析構函數，輸出 “局部靜態對象 的析構函數被調用” ，然后調用全局靜態對象globalObj的析構函數，輸出 “全局靜態對象 的析構函數被調用” 。
通過這個簡單的示例，我們可以清晰地看到在單文件內，static 對象嚴格按照構造順序的相反順序進行析構，這是 C++ 語言為了保證資源的正確釋放和對象生命周期的合理管理而制定的規則 。這種規則使得我們在編寫代碼時，能夠更好地預測和控制程序的行為，減少因資源管理不當而引發的錯誤 。
3.2多文件場景的復雜性
當我們的項目涉及多個文件時，static 對象析構順序的問題就變得復雜起來 。在多文件場景下，不同文件中的 static 對象析構順序是未定義的 。這意味著，我們無法確切地知道哪個文件中的 static 對象會先被析構，哪個會后被析構 。這種不確定性源于 C++ 標準并沒有對多文件中 static 對象的析構順序做出明確規定，其順序主要取決于編譯器的實現和鏈接器的處理方式 。
這種未定義的析構順序可能會導致一些潛在的問題，其中最常見的就是資源依賴問題 。例如，假設在file1.cpp中定義了一個靜態對象obj1，它在析構時需要訪問file2.cpp中定義的靜態對象obj2 。如果obj2先于obj1被析構，那么當obj1析構時訪問obj2，就會訪問到一個已經被銷毀的對象，從而引發未定義行為，可能導致程序崩潰或出現其他難以調試的錯誤 。
下面是一個簡單的多文件示例來展示這種問題：
// file1.cpp
#include <iostream>
class Object1 {
public:
~Object1() {
std::cout << "Object1 析構，嘗試訪問Object2" << std::endl;
// 這里假設需要訪問Object2的某個成員或方法
// 由于析構順序不確定，可能此時Object2已被析構
}
};
static Object1 obj1;
// file2.cpp
#include <iostream>
class Object2 {
public:
~Object2() {
std::cout << "Object2 析構" << std::endl;
}
};
static Object2 obj2;在這個示例中，Object1 的析構函數中假設需要訪問 Object2 。由于多文件中 static 對象析構順序未定義，Object2 有可能先于 Object1 被析構，那么當Object1 析構時訪問 Object2，就會出現問題 。這種問題在實際項目中往往很難調試，因為它可能不是每次都會復現，而且錯誤發生的位置可能與實際問題的根源相距甚遠 。
多文件場景下 static 對象析構順序的未定義性給我們的編程帶來了一定的挑戰，需要我們在設計和實現代碼時格外小心，避免出現因析構順序不當而導致的資源依賴問題 。
四、static 析構常見問題
4.1析構順序導致的問題
在 C++ 編程中，static對象的析構順序問題常常容易被忽視，但卻可能引發嚴重的程序錯誤。以 OceanBase 源碼中的一個實際案例來說，在其開源代碼里，有這樣一段代碼：
oceanbase::sql::ObSQLSessionInfo &session() {
static oceanbase::sql::ObSQLSessionInfo SESSION;
return SESSION;
}
ObArenaAllocator &session_alloc() {
static ObArenaAllocator SESSION_ALLOC;
return SESSION_ALLOC;
}
int ObTableApiProcessorBase::init_session() {
int ret = OB_SUCCESS;
static const uint32_t sess_version = 0;
static const uint32_t sess_id = 1;
static const uint64_t proxy_sess_id = 1;
if (OB_FAIL(session().test_init(sess_version, sess_id, proxy_sess_id, &session_alloc()))) {
LOG_WARN("init session failed", K(ret));
}
// more...
return ret;
}在系統退出時，這段代碼可能會導致 coredump 問題 。利用 ASAN 診斷發現，靜態對象SESSION析構時會引用SESSION_ALLOC，而SESSION_ALLOC同樣是一個靜態對象。由于 C++ 中static變量的析構規則是先構造者后析構 ，當SESSION_ALLOC先于SESSION析構時，SESSION析構時就會訪問到非法內存，因為此時SESSION_ALLOC已經析構，其所管理的內存資源已被釋放，SESSION再去訪問相關資源就會出錯，從而引發 coredump 。
為了更直觀地理解，我們可以用一個簡單的示例程序來驗證這種析構順序：
#include <iostream>
using namespace std;
class A {
public:
A() { cout << "construct A" << endl; }
~A() { cout << "deconstruct A" << endl; }
void init() {}
};
class B {
public:
B() { cout << "construct B" << endl; }
~B() { cout << "deconstruct B" << endl; }
void init(A &a) { a.init(); }
};
A &getA() {
static A a;
return a;
}
B &getB() {
static B b;
return b;
}
void func() {
getB().init(getA());
}
int main(int argc, const char *argv[]) {
func();
return 0;
}運行上述程序，輸出結果為：
construct A
construct B
deconstruct B
deconstruct A從輸出可以清晰地看到，A先構造，B后構造，而析構時，B先析構，A后析構，這完全符合先構造者后析構的規則 。在實際項目中，像 OceanBase 遇到的這種由于static對象析構順序不當導致的問題，往往需要對代碼中各個static對象之間的依賴關系有清晰的認識，并進行合理的設計和處理 。
4.2內存泄漏問題
在 C++ 中，內存泄漏是一個常見且棘手的問題，而static成員指針如果使用不當，就很容易引發內存泄漏 。當static成員指針指向動態分配的內存，但在析構時沒有正確釋放該內存，就會導致這部分內存無法被回收，從而造成內存泄漏 。例如：
class Resource {
public:
Resource() {
data = new int[100];
}
~Resource() {
// 這里沒有釋放data內存，會導致內存泄漏
}
private:
static int* data;
};
int* Resource::data = nullptr;
int main() {
Resource res;
return 0;
}在上述代碼中，Resource類的data是一個static成員指針，在構造函數中分配了內存，但析構函數中沒有釋放，當程序結束時，data所指向的內存就會泄漏 。內存泄漏的危害是隨著程序運行時間的增長，可用內存會逐漸減少，這可能導致系統性能下降，程序響應速度變慢。最終，當可用內存被耗盡時，程序可能會崩潰，甚至導致整個系統出現故障 。
為了解決這個問題，我們需要在析構函數中正確釋放static成員指針所指向的內存 。修改后的代碼如下：
class Resource {
public:
Resource() {
data = new int[100];
}
~Resource() {
delete[] data;
data = nullptr;
}
private:
static int* data;
};
int* Resource::data = nullptr;
int main() {
Resource res;
return 0;
}這樣，在Resource對象析構時，data所指向的內存會被正確釋放，從而避免了內存泄漏問題 。此外，我們還可以利用智能指針來管理static成員指針，進一步提高代碼的安全性和可靠性 。例如：
#include <memory>
class Resource {
public:
Resource() {
data = std::make_unique<int[]>(100);
}
~Resource() {
// 智能指針會自動釋放內存，無需手動delete
}
private:
static std::unique_ptr<int[]> data;
};
std::unique_ptr<int[]> Resource::data = nullptr;
int main() {
Resource res;
return 0;
}使用std::unique_ptr后，data的內存管理變得更加安全和便捷，無需手動釋放內存，智能指針會在其生命周期結束時自動釋放所指向的內存 。
4.3多線程環境下的析構問題
在多線程環境中，static變量的析構會面臨線程安全的挑戰 。以 MNN 推理引擎在 IOS 平臺出現的崩潰案例為例，實際代碼中存在子線程訪問靜態變量的情況，當子線程崩潰時，主線程在調用_exit函數 。異常信息顯示為Exception Type: EXC_BAD_ACCESS，Exception Codes: KERN_INVALID_ADDRESS at 0x000095f59f17ce20，Exception Subtype: SIGSEGV，Triggered by Thread: 28 。
從理論上來說，C++11 標準對靜態變量在多線程環境下的使用有相關規范 。在構造階段，如果多個線程同時嘗試初始化同一個局部靜態變量，C++11 規定后續線程需要等待正在初始化的線程完成初始化 。在析構階段，線程生命周期的對象全部在靜態變量之前析構，靜態變量按照后構造的先析構的棧式順序釋放 。
不同的編譯器對這些特性的實現有所不同 。例如，GCC 從 4.3 版本開始支持靜態變量構造和析構函數的多線程安全 。在構造階段，對于局部靜態變量，多線程調用時，首先構造靜態變量的線程先加鎖，其他線程等待前者執行完鎖操作 。對于全局靜態變量，按照聲明順序在主線程構造，早于子線程啟動 。在析構階段，全局和局部靜態變量的析構函數在所有線程結束后才開始調用，保證析構時線程安全 。而對于 Apple clang 編譯器，其對多線程析構構造的支持情況不太明確，從實際案例來看，屬于部分支持 。
在多線程環境下，除了構造和析構階段的線程安全問題，如果在這兩個階段之間，多個線程訪問靜態變量的含有寫操作的成員函數，或某種異步操作的函數，仍然可能出現數據競爭和不一致的問題 。例如：
class SharedData {
public:
static int value;
static void increment() {
++value;
}
};
int SharedData::value = 0;
void threadFunction() {
for (int i = 0; i < 1000; ++i) {
SharedData::increment();
}
}
int main() {
std::thread t1(threadFunction);
std::thread t2(threadFunction);
t1.join();
t2.join();
std::cout << "Final value: " << SharedData::value << std::endl;
return 0;
}在上述代碼中，SharedData類的value是一個static成員變量，increment函數對其進行寫操作 。當多個線程同時調用increment函數時，由于沒有同步機制，會導致數據競爭，最終的value值可能不是預期的 2000 。為了解決這個問題，我們可以使用互斥鎖等同步機制來保證線程安全：
#include <mutex>
class SharedData {
public:
static int value;
static std::mutex mtx;
static void increment() {
std::lock_guard<std::mutex> lock(mtx);
++value;
}
};
int SharedData::value = 0;
std::mutex SharedData::mtx;
void threadFunction() {
for (int i = 0; i < 1000; ++i) {
SharedData::increment();
}
}
int main() {
std::thread t1(threadFunction);
std::thread t2(threadFunction);
t1.join();
t2.join();
std::cout << "Final value: " << SharedData::value << std::endl;
return 0;
}通過使用std::lock_guard和std::mutex，確保了在對value進行寫操作時的線程安全 。
五、解決static析構問題的方法
5.1確保正確的析構順序
在實際編程中，確保static對象的正確析構順序是避免因析構順序不當而引發問題的關鍵 。以修復 OceanBase 代碼中由于static變量析構順序導致的 coredump 問題為例，我們可以通過調整代碼邏輯來保證析構順序 。
在原代碼中，ObSQLSessionInfo類型的SESSION靜態對象析構時會引用ObArenaAllocator類型的SESSION_ALLOC靜態對象，當SESSION_ALLOC先于SESSION析構時，就會導致SESSION析構時訪問非法內存 。為了解決這個問題，我們可以在SESSION構造之前，主動調用一次session_alloc 。具體修改后的代碼如下：
oceanbase::sql::ObSQLSessionInfo &session() {
static oceanbase::sql::ObSQLSessionInfo SESSION;
return SESSION;
}
ObArenaAllocator &session_alloc() {
static ObArenaAllocator SESSION_ALLOC;
return SESSION_ALLOC;
}
int ObTableApiProcessorBase::init_session() {
int ret = OB_SUCCESS;
static const uint32_t sess_version = 0;
static const uint32_t sess_id = 1;
static const uint64_t proxy_sess_id = 1;
// ensure allocator is constructed before session to
// avoid coredump at observer exit
ObArenaAllocator &dummy_allocator = session_alloc();
UNUSED(dummy_allocator);
if (OB_FAIL(session().test_init(sess_version, sess_id, proxy_sess_id, &session_alloc()))) {
LOG_WARN("init session failed", K(ret));
}
// more...
return ret;
}通過這種方式，使得SESSION_ALLOC先于SESSION構造，根據static對象先構造者后析構的規則，就能保證在析構時，SESSION先于SESSION_ALLOC析構，從而避免了訪問非法內存的問題 。在設計和編寫代碼時，我們應該充分考慮static對象之間的依賴關系，盡量將相互依賴的static對象的構造和析構順序進行合理安排，以確保程序的穩定性和正確性 。
5.2資源管理策略
為了有效避免static析構時可能出現的內存泄漏和懸空指針問題，引入智能指針是一種非常有效的資源管理策略 。智能指針是 C++ 中用于自動管理動態分配資源的類模板，它利用 RAII（資源獲取即初始化）技術，在對象創建時獲取資源，在對象銷毀時自動釋放資源，從而避免了手動new/delete操作可能帶來的內存泄漏和懸空指針風險 。
例如，當我們有一個static成員指針指向動態分配的內存時，使用智能指針可以大大簡化資源管理 。假設我們有一個DataManager類，其中包含一個static成員指針data指向動態分配的整數數組：
#include <memory>
class DataManager {
public:
static void init() {
data = std::make_unique<int[]>(100);
}
static void deinit() {
// 智能指針會自動釋放內存，無需手動delete
}
private:
static std::unique_ptr<int[]> data;
};
std::unique_ptr<int[]> DataManager::data = nullptr;在上述代碼中，我們使用std::unique_ptr來管理data指針 。在init函數中，通過std::make_unique創建一個包含 100 個整數的數組，并將其賦值給data 。當程序結束，DataManager類的static成員析構時，std::unique_ptr會自動調用delete[]來釋放數組所占用的內存，無需我們手動編寫釋放代碼，從而避免了內存泄漏的風險 。
除了std::unique_ptr，C++ 還提供了std::shared_ptr用于實現多個指針共享同一資源的場景，它通過引用計數來管理資源的生命周期，當引用計數為 0 時，自動釋放資源 。還有std::weak_ptr，它是一種弱引用智能指針，用于解決std::shared_ptr的循環引用問題 。根據不同的場景需求，合理選擇和使用智能指針，可以顯著提高代碼的安全性和可靠性 。
5.3多線程環境下的處理
在多線程環境中，static變量的析構面臨著線程安全的挑戰，需要遵循相關標準規范并采取合適的處理方式 。C++11 標準為static變量在多線程環境下的使用提供了一些規范 。在構造階段，對于局部靜態變量，如果多個線程同時嘗試初始化同一個局部靜態變量，C++11 規定后續線程需要等待正在初始化的線程完成初始化 。在析構階段，線程生命周期的對象全部在靜態變量之前析構，靜態變量按照后構造的先析構的棧式順序釋放 。
為了確保多線程環境下static變量析構的線程安全，我們可以利用鎖機制來同步對static變量的訪問 。例如，當多個線程可能同時訪問和修改一個static成員變量時，我們可以使用互斥鎖來保護對它的操作 。假設有一個Counter類，其中包含一個static成員變量count用于計數：
#include <mutex>
class Counter {
public:
static void increment() {
std::lock_guard<std::mutex> lock(mtx);
++count;
}
static int getCount() {
std::lock_guard<std::mutex> lock(mtx);
return count;
}
private:
static int count;
static std::mutex mtx;
};
int Counter::count = 0;
std::mutex Counter::mtx;在上述代碼中，std::mutex類型的mtx用于保護對count的操作 。在increment和getCount函數中，使用std::lock_guard來自動管理鎖的生命周期，在函數進入時自動加鎖，離開時自動解鎖 。這樣，即使在多線程環境下，也能保證對count的操作是線程安全的 。
另外，線程本地存儲（TLS）也是一種在多線程環境下處理數據的有效方式 。通過使用thread_local關鍵字聲明變量，可以使每個線程擁有自己獨立的變量副本，避免了線程間的數據競爭 。例如：
#include <iostream>
#include <thread>
thread_local int threadLocalValue = 0;
void threadFunction() {
++threadLocalValue;
std::cout << "Thread " << std::this_thread::get_id() << ": threadLocalValue = " << threadLocalValue << std::endl;
}
int main() {
std::thread t1(threadFunction);
std::thread t2(threadFunction);
t1.join();
t2.join();
return 0;
}在這個例子中，threadLocalValue是一個線程本地存儲變量，每個線程都有自己獨立的副本 。在threadFunction中對threadLocalValue的修改只影響當前線程的副本，不會影響其他線程，從而避免了多線程環境下的競爭問題 。在多線程環境下處理static析構問題時，我們要充分理解 C++11 標準的相關規范，合理運用鎖機制和線程本地存儲等技術，確保程序的線程安全性和正確性 。
六、高頻面試題講解
面試題 1：全局靜態變量和局部靜態變量析構順序誰先誰后？
答案：通常局部靜態變量先析構，全局靜態變量后析構。它們均在 main 結束或調用 exit 時析構，析構順序與構造順序相反，全局靜態變量于 main 前構造，局部靜態變量在函數首次執行到聲明處構造，所以一般全局靜態構造更早。
題目 2：同一函數里多個局部靜態對象，其析構順序如何確定？
答案：與構造順序相反。即后構造的先析構，遵循 “后進先出” 原則。
題目 3：程序包含多個文件，各文件有全局靜態變量，析構順序是怎樣的？
答案：析構順序不確定。不同文件全局靜態變量的構造順序編譯器不定，依 “先構造后析構” 原則，其析構順序同樣不確定。
題目 4：類的靜態成員變量何時析構？
答案：和程序生命周期一致，于 main 函數結束或調用 exit 后析構。其需類外定義，同一源文件內，按和定義相反順序析構；不同源文件時，析構順序編譯器未規定。
題目5：看以下代碼，說出析構函數調用順序：
class A {};
class B {};
A a;
int main() {
B b;
static A a2;
return 0;
}答案：先 b 析構（局部對象在函數結束時析構），接著 a2 析構（局部靜態于 main 結束后析構），最后 a 析構（全局對象于程序結束最后析構）。
題目 6：若局部靜態對象所在函數未被調用，其析構函數會執行嗎？
答案：不會。局部靜態對象在函數首次調用至聲明處構造，沒構造便不會觸發析構。
題目 7：派生類對象含靜態成員變量，對象析構時，靜態成員變量析構會受影響嗎？
答案：不受影響。類靜態成員變量析構僅取決于程序結束與否，和類對象創建或析構無直接聯系。
題目 8：以下程序析構順序是什么？
class A {};
class B {};
class C {};
class D {};
C c;
int main() {
A a;
B b;
static D d;
return 0;
}答案：先 b 再 a（局部對象按定義相反序析構），然后 d 析構（靜態對象于程序結束析構），最后 c 析構（全局對象程序結束析構，c 比 d 構造更早）。
題目9：使用 atexit 注冊清理函數，其和靜態變量析構，執行先后順序如何？
答案：通常靜態變量析構優先。atexit 注冊的函數在所有靜態存儲持續期對象析構后，由 exit 觸發執行。
題目10：靜態對象析構期間拋未捕獲異常，會有什么狀況？
答案：C++ 里會調用 std::terminate 結束程序。靜態對象析構屬程序結束關鍵階段，需避免拋未捕獲異常。
