一、引言

在算法工程中，大家一般關注四大核心維度：穩定、成本、效果、性能。

其中，性能尤為關鍵——它既能提升系統穩定性，又能降低成本、優化效果。因此，工程團隊將微秒級的性能優化作為核心攻堅方向。

本文將結合具體案例，分享算法SRE在日常性能優化中的寶貴經驗，助力更多同學在實踐中優化系統性能、實現業務價值最大化。

二、給浮點轉換降溫

算法工程的核心是排序，而排序離不開特征。特征大多是浮點數，必然伴隨頻繁的數值轉換。零星轉換對CPU無足輕重，可一旦規模如洪水傾瀉，便會出現CPU瞬間飆紅、性能斷崖式下跌的情況，導致被迫堆硬件，白白抬高成本開銷。

例如：《交易商詳頁相關推薦 - neuron-csprd-r-tr-rel-cvr-v20-s6》 特征處理占用CPU算力時間的61%。其中大量工作都在做Double浮點轉換，如圖所示：

圖片

優化前CPU時間占比 18%

Double.parseDouble、Double.toString是JDK原生原子API了，還能優化？直接給答案：能！

浮點轉字符串：Ryu算法

https://github.com/ulfjack/ryu

Ryu算法，用“查表＋定長整數運算”徹底摒棄“動態多精度運算＋內存管理”的重開銷，既正確又高效。

算法的完整正確性證明：https://dl.acm.org/citation.cfm? doid=3296979.3192369

 偽代碼說明 

// ——“普通”浮點到字符串（高成本）——
void convertStandard(double d, char *out) {
    // 1. 拆分浮點：符號、指數、尾數
    bool sign = (d < 0);
    int  exp  = extractExponent(d);    // 提取二進制指數
    uint64_t mant = extractMantissa(d);
    
    // 2. 構造大整數：mant × 2^exp —— 可能要擴容內存
    BigInt num = BigInt_from_uint64(mant);
    num = BigInt_mul_pow2(num, exp);    // 多精度移位，高開銷
   
    // 3. 逐位除以 10 生成十進制，每次都是多精度除法
    //    ——每次 divMod 都要循環內部分配和多精度運算
    char buf[32];
    int  len = 0;
    while (!BigInt_is_zero(num)) {
        BigInt digit, rem;
        BigInt_divmod(num, 10, &digit, &rem);  // 慢：多精度除法
        buf[len++] = '0' + BigInt_to_uint32(digit);
        BigInt_free(num);
        num = rem;
    }
    
    // 4. 去除多余零、插入小數點和符號
    formatOutput(sign, buf, len, out);
}




// ——Ryu 方法（低成本）——
void convertRyu(double d, char *out) {
    // 1. 拆分浮點：符號、真實指數、尾數（隱含1）
    bool sign = (d < 0);
    int  e2   = extractBiasedExponent(d) - BIAS;
    uint64_t m2 = extractMantissa(d) | IMPLIED_ONE;
    
    // 2. 一次查表：獲得 5^k 和對應位移量
    //    ——預先計算好，運行時無動態開銷
    int      k     = computeDecimalExponent(e2);
    uint64_t pow5  = POW5_TABLE[k];        // 只讀數組（cache 友好）
    int      shift = SHIFT_TABLE[k];
    
    // 3. 單次 64×64 位乘法 + 右移 —— 固定時間
    __uint128_t prod = ( __uint128_t )m2 * pow5;
    uint64_t    v    = (uint64_t)(prod >> shift);
    
    // 4. 固定最多 ~20 次小循環，v%10 生成每位數字
    //    ——循環次數上限，與具體數值無關
    char buf[24];
    int  len = 0;
    do {
        buf[len++] = '0' + (v % 10);
        v /= 10;
    } while (v);
   
    // 5. 去零、插小數點、加符號：輕量字符串操作
    formatShort(sign, buf, len, k, out);
}

傳統方法 vs. Ryu算法對比：

字符串轉浮點：Fast_Float算法

https://github.com/wrandelshofer/FastDoubleParser

相比Java自帶的Double.parseDouble使用復雜狀態機（如BigDecimal或 BigInteger）來處理各種情況，FastDoubleParser使用以下優化策略。

FastDoubleParser 優化策略

※  分離階段

• 將輸入拆分為三個部分：significand、exponent、special cases（如 NaN, Infinity）。
• 解析時直接處理整數位和小數位的組合。

※  整型加速 + 倍數轉換

• 在范圍允許的情況下使用“64位整數直接表示”有效位。
• 再通過預計算的“冪次表（10? 或 2?）”進行快速縮放，避免慢速浮點乘法。

※  避免慢路徑

• 避免使用BigDecimal或字符串轉高精度，再轉回double的慢路徑。
• 對于大多數輸入，整個解析過程不涉及任何內存分配。

※  SIMD加速（原版 C++）

在C++中使用SIMD指令批量處理字符，Java版受限于JVM，但仍通過循環展開等技術盡量進行優化。

 轉換思路 

Input: "123.45e2"
1. 拆分成：
   significand = 12345 (去掉小數點)
   exponent = 2 - 2 = 0  // 小數點后兩位，但有 e2
2. 快速轉換：
   result = 12345 * 10^0 = 12345.0
3. 最終使用 Double.longBitsToDouble 構造結果

壓測報告

Double 字符解析相對JDK原生API 4.43倍 加速

代碼優化樣例

通過多層判斷，盡可能不讓Object o做toString()操作。

減少toString觸發的可能

工具類 替換浮點轉換算法

性能實測效果

啟用Ryu、Fast_Float算法替換JDK原生浮點轉換，效果如下：

優化后CPU時間占比 0.19%【性能提升(18-0.19)/18=98%】

CPU實際獲得50%收益

RT實際獲得25%左右性能收益

小結

告別原生JDK浮點轉換的高昂代價，擁抱Ryu與FastDoubleParser，讓CPU從繁忙到清閑，性能“回血”，節約的成本大家可以吃火鍋。

三、拔掉詭異的GC毛刺

小堆GC問題

特征維度多時內存壓力大，GC問題可以預期。但很多同學可能沒有見過，小堆場景，GC也可能頻繁觸發，甚至引發異常。

如圖所示：18GB堆 擴容 -> 30GB堆，均出現RT99周期脈沖，致使5~6%的失敗率。

社區瀑布流廣告投放-Neuron精排 因GC導致錯誤

GC問題分析

首先這是GC問題，其次增加了近1倍的內存，沒有絲毫緩解，判斷這應該是個偽GC問題。

Neuron主要功能就是拿著特征轉向量做排序。一般特征量都是億起步，多的達十億，因此特征緩存必不可少。但是這個場景，僅僅是將1700個左右的廣告特征信息進行了緩存，為什么對象內存會出現周期性的脈沖？

年輕代+老年代 周期共振脈沖

如圖所示，關鍵的問題在于“共振”。因此要用放大鏡看問題，再如圖所示：

共振點 放大

共振點CPU峰值水位：28%

GC 暫停時間

到這里，其實問題已經很明顯了：

• C4作為世界頂級垃圾回收器，GC的能力不用懷疑，STW（Stop-The-World）的時間理論是亞毫秒級。
• 如果GC能力沒問題，算力又充足，那么造成RT99翻倍的原因：要么是線程在等數據，要么是線程忙不過來。
• Neuron堆內存大頭是緩存，那么老年代回收的數據一定是緩存數據，年輕代一定是在回補緩存缺口。

為什么會有這個邏輯？因為緩存命中率一直是 99.9%【1700個廣告條目】，如圖所示：

圖片

在極高緩存命中率的場景下，僅清理少量緩存條目，也可能造成“緩存缺口”。緩存缺口本質上也是一次“中斷”，線程被迫等待或執行數據回補，導致性能抖動。

為方便理解，類比“缺頁中斷”（Page Fault）：當程序訪問未加載的內存頁時，操作系統必須中斷執行、加載數據，再繼續運行。

解決方案

首先是緩存命中率一定是越高越好，99.9%的命中率沒毛病。問題出在1700條廣告緩存條目，究竟為何必須如此頻繁地設置過期？【TTL: 60~90s】

原因是：業務期望廣告特征，能夠盡可能實時更新。

緩存失效策略

失效時間 60~90s

關鍵在于，緩存條目必須及時失效，卻又不能因GC過度而引發性能問題。從觀察結果來看，年輕代的GC沒有對RT99的性能產生明顯影響，這說明年輕代GC的力度恰到好處，不會造成頻繁的“緩存缺口”。既然如此，我們考慮：如果能徹底規避老年代GC，性能瓶頸的問題是否就能迎刃而解？

因此，我們嘗試大幅提高對象晉升到老年代的門檻，直接提升了幾個數量級。

增加JVM參數：


-XX:GPGCTimeStampPromotionThresholdMS # 對象晉升老年代前的時間閾值
默認值：2000  調整為：6000000 (1.6小時)


-XX:GPGCOldGCIntervalSecs # 老年代固定GC時間推薦。注意：并不是關閉 OldGC
默認值：600 調整為：600000

在這個場景中，實際有效的對象并不多，最多不過5GB。 其余大部分都是生命周期不超過2分鐘的短期廣告特征條目（約1700條）。這種短生命周期、低占用的場景完全靠年輕代GC就能輕松支撐，根本不需要啟用分代GC。

實際測試一天后，完全印證了這一判斷：GC抖動、RT99抖動以及錯誤率抖動全都徹底消失，同時內存也沒有出現任何泄漏。

GC 毛刺消失

RT99失敗率 毛刺峰值降至 1/10 +

小結

C4的分代GC對大堆確實有奇效，但放在小堆場景里，非要套個復雜架構，就成了典型的“形式主義”

大堆適用，小堆不行。

四、是誰偷走了RT時間

業務瓶頸的卡點

最近算法特征多了，推理成本就高了；RT一長，用戶體驗就垮了；產品一急，秒開優化就立項了。

全業務鏈路都已鎖定 RT 優化目標，社區個性化精排也在其中，可這一鏈路優化阻力最大——RT99長期卡在120ms 以上，始終難以突破。

圖片

活用三昧真火

性能分析必看CPU火焰圖。一看圖就是GC問題。

GC日志分析，年輕代+老年代，堆積起來約150GB，而堆內存才給108GB，怎么做到的？->>> 頻繁GC！

GC算力消耗占比 超50%

至少要 150GB 勉強夠用

看看哪里分配內存比較瘋狂，如圖內存分配火焰圖所示：

圖片

內存分配壓力指向兩大熱點

※  Dump

業務剛需，大量序列化點對象帶來的瞬時垃圾情有可原。

※  特征

真正的“吞金獸”——獨占超過50%的堆。業務方解釋：當前500萬特征才勉強把命中率抬到80%，想繼續往上，只能指數級內存擴容，總特征數10億+。堆已拉到128GB，找不到更大規格的機器。

也就是說內存主要被特征吞掉了，優化空間基本沒有。

如果優化止步于此，顯然無法滿足業務方的期望，于是我們進一步深入到Wall火焰圖進行更精細的分析。

圖片

Wall火焰圖同時捕獲了CPU執行與IO等待，因此不能簡單地以棧頂寬度判斷性能瓶頸。否則只會發現線程池空閑的等待任務，看似正常，但真正的性能瓶頸卻隱藏在細節中。

因此，我們需要放大視角，聚焦到具體的業務邏輯堆棧位置。在這個案例中，一旦放大便能發現顯著問題：特征讀取階段的IO等待時間，竟然超過了遠程DML推理與Kafka Dump的總耗時。這直接說明，所謂的80%特征緩存命中率存在明顯的緩存擊穿現象，大量請求可能被迫穿透至遠端Redis或C引擎進行加載，其耗時成本遠高于本地緩存命中的場景。

逐幀跟蹤確認

通過進一步的Trace跟蹤分析，我們的猜測得到了驗證。

圖片

通過和C引擎團隊聯合排查發現，現有架構采用了早期的部署模式，其中為索引分片路由而設立的中間Proxy層成為性能瓶頸，其RT999甚至超過100ms。這種架構帶來的問題在于，上游業務對特征數量需求極大，即使緩存已擴大到500萬條目，也僅能達到80%的命中率。算法工程團隊通過對特征請求進行多層拆分及異步并發查詢優化，但仍有少量長尾特征無法命中緩存，只能依靠C引擎響應。一旦任何一批次特征查詢觸發了C引擎的慢查詢，這一請求的整體RT勢必大幅提升，甚至可能超時。

好在C引擎同時提供了一種更先進的垂直多副本部署模式，能夠去除Proxy這一中心化的瓶頸組件。未來的新架構仍會保留索引分片設計，但會利用旁路方式實現完全的去中心化。

圖片

小結

通過Wall火焰圖深入分析RT性能瓶頸，并結合Trace工具驗證猜想，是優化系統性能不可或缺的關鍵步驟。

五、結語：性能優化無止盡

性能優化沒有終點，只有下一個起點。每次性能的提升，不僅是對技術邊界的突破，更是為業務創造了更多可能性。本文分享的場景和實操經驗，旨在拋磚引玉，幫助各位同學掌握深度性能分析的方法論，避免走彎路，更高效地解決工程難題。希望每位研發和SRE同學，都能從微妙的細節中捕捉優化機會，讓應用在極致性能的路上穩步前進。