← 返回

如何使用 OpenResty XRay 快速定位 C++ 模組中的記憶體洩漏

章亦春釋出於 Oct 11, 2025 更新於 Oct 11, 2025

預計閱讀 7 分鐘

閱讀次數

在某些關鍵時刻，核心服務的穩定性直接關係到業務的成敗。最近，我們的一位客戶就遇到了讓運維團隊頭疼的問題：Nginx 服務的記憶體像“黑洞”一樣不斷膨脹。臨時重啟只能緩解一時壓力，問題卻總是死灰復燃。我們將透過這篇文章分享如何用 OpenResty XRay 快速發現並定位這一隱蔽的記憶體洩漏問題，以及如何把複雜、漫長的記憶體洩漏定位過程，賦能成一個“診斷 → 規劃 → 驗證”可複用的閉環。

使用 OpenResty XRay 快速透視和解決您的軟體問題

技術困境與初步診斷

我們一位客戶的核心 Nginx 服務記憶體佔用持續上漲，彷彿一個“記憶體黑洞”。雖然臨時重啟能緩解一時的壓力，但問題很快再次出現。

挑戰與風險：

技術層： 生產環境下的 C/C++ 模組記憶體洩漏，堪稱最難解決的問題之一。傳統除錯工具（如 GDB）無法直接用於線上，而程式碼審計則如同大海撈針，耗時且低效。
業務層： 如果放任不管，記憶體消耗會持續加劇，導致響應變慢、頻繁崩潰，最終威脅核心業務的連續性。這意味著：使用者體驗下降，使用者逐漸流失；品牌聲譽受損和直接的經濟損失。

靠定時重啟來“續命”，無異於飲鴆止渴，讓整個業務長期暴露在風險之中。在接到求助後，我們立即利用動態追蹤產品 OpenResty XRay 直接在生產環境對記憶體分配進行分析。僅僅幾分鐘，工具就自動生成了記憶體洩露火焰圖，為問題排查提供了清晰的突破口。

火焰圖一目瞭然地顯示了記憶體分配主要集中在三個區域：

Nginx 記憶體池
TLS 相關記憶體
ngx_dubbo_module 函式

Nginx 記憶體池和 TLS 都是久經考驗的成熟元件，發生記憶體洩漏的機率極低。因此，我們將分析的重點迅速鎖定在嫌疑最大的 ngx_dubbo_module 函式上。

火焰圖指路，鎖定記憶體洩漏的“重災區”

第一步：鎖定可疑函式。

藉助 OpenResty XRay 的強大動態追蹤能力，我們不需要翻閱海量日誌或進行地毯式程式碼審計，就能像“庖丁解牛”一樣高效地剖析問題，我們 zoom in 嫌疑最大的 ngx_dubbo_module 函式。

記憶體洩露火焰圖清晰地指出，記憶體分配的峰頂指向了 ngx_dubbo_hessian2_encode_payload_map 函式，這裡就是記憶體洩漏的“重災區”。

第二步：深入程式碼，發現疑點。

我們定位到該函式的原始碼，很快就發現了可疑之處：

ngx_int_t ngx_dubbo_hessian2_encode_payload_map(ngx_pool_t *pool, ngx_array_t *in, ngx_str_t *out)
{
    try {
        // ...
        for (size_t i=0; i<in->nelts; i++) {
            string key((const char*)kv[i].key.data, kv[i].key.len);
            if (0 == (key.compare("body"))) {
                // 這裡用 new 建立了物件
                ByteArray *tmp = new ByteArray((const char*)kv[i].value.data, kv[i].value.len);
                ObjectValue key_obj(key);
                ObjectValue value_obj((Object*)tmp);
                // 將物件放入 Map，但之後沒有看到 delete 操作
                strMap.put(key_obj, value_obj);
            } else {
                // ...
            }
        }
        // ...
    } catch (...) {
        // ...
    }
}

程式碼中使用 new ByteArray 建立了 tmp 物件，但通讀全篇，我們都沒有找到與之對應的 delete 操作。直覺告訴我們，問題就出在這裡。tmp 物件被包裝成 ObjectValue 後，傳遞給了 strMap.put 方法。它的生命週期到底由誰管理？

第三步：順藤摸瓜，追溯物件生命週期。

為了弄清真相，我們必須深入到 hessian2 庫的實現細節中。

首先，tmp 指標被用來構造 ObjectValue：ObjectValue value_obj((Object*)tmp);，其對應的建構函式非常簡單，只是將指標存起來，並未涉及任何智慧指標或所有權轉移的操作。

// ObjectValue 建構函式
ObjectValue(Object* obj) : _type(OBJ) { _value.obj = obj; }

接著，value_obj 被傳入 strMap.put 方法。這個方法內部會呼叫 value.get_object() 來獲取原始的物件指標：

// Map::put 方法實現
void Map::put(const ObjectValue&amp; key, const ObjectValue&amp; value,
        bool chain_delete_key, bool chain_delete_value) {
    pair<Object*, bool> ret_key = key.get_object();
    pair<Object*, bool> ret_value = value.get_object();
    // ...
    // 根據 get_object 返回的 bool 值決定是否將物件加入“刪除鏈”
    if (ret_value.second || chain_delete_value) {
        _delete_chain.push_back(ret_value.first);
    }
    _map[ret_key.first] = ret_value.first;
}

Map 內部有一個 _delete_chain，用來管理需要釋放的記憶體。一個物件是否被加入這個“刪除鏈”，取決於 get_object() 返回的 bool 值，或者呼叫 put 方法時傳入的 chain_delete_value 引數。

現在，我們來看最關鍵的 ObjectValue::get_object 方法：

// ObjectValue::get_object 方法實現
pair<Object*, bool> ObjectValue::get_object() const {
    switch (_type) {
        // 我們的 tmp 物件型別是 OBJ
        case OBJ:        return pair<Object*, bool>(_value.obj, false);
        case C_OBJ:      return pair<Object*, bool>(_value.obj, false);
        // 其他型別會 new 新物件並返回 true
        case IVAL:       return pair<Object*, bool>(new Integer(_value.ival), true);
        // ...
        default:         return pair<Object*, bool>(NULL, false);
    }
}

真相大白！當 _type 是 OBJ 時，get_object 方法返回的 bool 值是 false。這意味著它告訴呼叫者：“這個指標你不用管，我沒有 new 新記憶體”。然而，我們的 tmp 物件恰恰是在外部 new 出來的。

由於 get_object() 返回 false，並且 put 方法呼叫時未指定 chain_delete_value（預設為 false），導致 if (ret_value.second || chain_delete_value) 條件不成立，tmp 物件最終沒有被加入 _delete_chain。隨著請求不斷處理，無數個 ByteArray 物件被建立出來，卻永遠得不到釋放，記憶體洩漏由此產生。

從被動應對到主動賦能：XRay 帶來的排障新閉環

在追求系統穩定性的道路上，許多團隊陷入了一個怪圈：為了解決問題，蒐集更多的資料來獲得更多的線索，為了收集更多的資料，增加更多的監控指標，搭建更復雜的 Dashboard，投入鉅額預算購買更多的監控工具。結果這些工具帶來了大量碎片化的資訊，資料越來越多，訊雜比卻越來越低。工程師們依然要在“資料墳場”中翻找蛛絲馬跡，淘金一樣篩選有價值的資訊。

這種模式的根本缺陷在於，它將技術問題如記憶體洩漏與商業成本：

一次記憶體洩漏告警，看似只是技術指標的波動，背後卻是工程師寶貴時間的流失；
一次頻繁的線上異常，不僅威脅系統穩定，更意味著業務中斷的潛在風險；
持續高昂的監控投入，卻換不來相匹配的洞察產出。

說到底，這不是“資料太少”，而是“有用的答案太少”。真正高效的可觀測性工具，應該像一把“手術刀”，直接切入問題根源，而不是再給團隊一把“鐵鍬”，讓大家在資料堆裡沒日沒夜地挖。這正是下一代可觀測性平臺所要解決的核心矛盾：

從表象指標走向因果鏈條
從被動告警走向主動分析洞察
從消耗人力走向真正釋放研發生產力

總結

在這個案例中，OpenResty XRay 展示了另一種方式：把複雜、漫長的過程，變成一個可複用的閉環。我們稱之為 “診斷 → 規劃 → 驗證”。

精準切入: 傳統方法是“多看點資料，也許能找到線索”。XRay 的方式則不同：透過火焰圖等視覺化工具，它直接指向問題所在，讓團隊在幾分鐘內就能看到根因。它提供的，不是更多的監控指標，而是關鍵的、能推動行動的洞察。
從確鑿證據出發制定方案: 當知道問題精確落在某一行程式碼或某個 C/C++ 模組時，修復方案就能直奔主題。團隊不需要反覆試錯，而是基於明確證據，快速形成清晰、有效的行動步驟。
立即驗證，形成完整閉環: 修復上線後，XRay 可以再次分析，確認問題是否已徹底消除。這種快速驗證機制，讓整個過程真正閉環：診斷、行動、驗證，環環相扣。

這種閉環能力帶來的價值，已經遠遠超越了單一 Bug 的解決：

技術價值： 賦能團隊以無侵入的方式，直達生產環境中的 C/C++ 模組，將複雜問題簡單化、視覺化。
商業價值：
- 保障業務穩定： 快速消除潛在故障，保障服務的高可用性。
- 提升研發效率： 將工程師從繁瑣、低效的 Debugging 中解放出來，投入到更有價值的業務創新中。
- 最佳化資源成本： 避免因未知效能問題而進行的過度資源配置，實現真正的成本控制。

在這個資料過載的時代，技術團隊需要的不再是更多監控面板，而是一種更智慧、更可信賴的方式，幫他們在最短時間內找到問題、解決問題，這才是可觀測性的真正價值所在。

關於 OpenResty XRay

OpenResty XRay 是一款動態追蹤產品，它可以自動分析執行中的應用，以解決效能問題、行為問題和安全漏洞，並提供可行的建議。在底層實現上，OpenResty XRay 由我們的 Y 語言驅動，可以在不同環境下支援多種不同的執行時，如 Stap+、eBPF+、GDB 和 ODB。

立即申請 OpenResty XRay 試用

關於作者

章亦春是開源 OpenResty^® 專案創始人兼 OpenResty Inc. 公司 CEO 和創始人。

章亦春（Github ID: agentzh），生於中國江蘇，現定居美國灣區。他是中國早期開源技術和文化的倡導者和領軍人物，曾供職於多家國際知名的高科技企業，如 Cloudflare、雅虎、阿里巴巴, 是 “邊緣計算“、”動態追蹤 “和 “機器程式設計 “的先驅，擁有超過 22 年的程式設計及 16 年的開源經驗。作為擁有超過 4000 萬全球域名使用者的開源專案的領導者。他基於其 OpenResty^® 開源專案打造的高科技企業 OpenResty Inc. 位於美國矽谷中心。其主打的兩個產品 OpenResty XRay（利用動態追蹤技術的非侵入式的故障剖析和排除工具）和 OpenResty Edge（最適合微服務和分散式流量的全能型閘道器軟體），廣受全球眾多上市及大型企業青睞。在 OpenResty 以外，章亦春為多個開源專案貢獻了累計超過百萬行程式碼，其中包括，Linux 核心、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl 等，並編寫過 60 多個開源軟體庫。