存優(yōu)化——內(nèi)表濫用、內(nèi)存泄漏、大對(duì)象占用的排查與優(yōu)化方案)
ABAP核心進(jìn)階篇120篇調(diào)試與性能優(yōu)化20篇第四篇ABAP程序內(nèi)存優(yōu)化——內(nèi)表濫用、內(nèi)存泄漏、大對(duì)象占用的排查與優(yōu)化方案博客標(biāo)題《ABAP程序內(nèi)存優(yōu)化內(nèi)表濫用、內(nèi)存泄漏、大對(duì)象占用的排查與優(yōu)化方案》博客簡(jiǎn)介講解ABAP程序內(nèi)存分配的底層邏輯結(jié)合SAT內(nèi)存分析功能定位內(nèi)表未釋放、全局變量冗余、大對(duì)象重復(fù)實(shí)例化等內(nèi)存問(wèn)題分享內(nèi)表初始行預(yù)分配、無(wú)用數(shù)據(jù)及時(shí)清理、對(duì)象池復(fù)用、內(nèi)表數(shù)據(jù)拆分處理的優(yōu)化技巧解決程序運(yùn)行時(shí)內(nèi)存溢出、系統(tǒng)資源占用過(guò)高問(wèn)題。 寫(xiě)在前面上一篇我們把數(shù)據(jù)庫(kù)性能這塊啃下來(lái)了——通過(guò)ST05定位慢SQL、用FATE替代循環(huán)內(nèi)SELECT、給大表加合適的索引把一個(gè)210秒的報(bào)表干到了12.5秒。但故事到這里還沒(méi)完。當(dāng)DB時(shí)間被優(yōu)化到極致或者程序干脆是CPU密集型時(shí)下一個(gè)瓶頸就浮出水面了——內(nèi)存。你一定見(jiàn)過(guò)這些場(chǎng)景報(bào)表跑到一半突然Memory Consumption has Exceeded the Limit然后Dump后臺(tái)作業(yè)被管理員Kill掉SAT里80%的CPU時(shí)間花在內(nèi)表操作上多用戶(hù)同時(shí)跑同一個(gè)程序系統(tǒng)整體內(nèi)存飄紅。這些問(wèn)題的根源都是內(nèi)存使用不當(dāng)。內(nèi)存優(yōu)化全景底層模型EM(2GB)/Heap/Paging排查工具SAT Memory Analysis反模式修復(fù)預(yù)分配/釋放/分批/對(duì)象池實(shí)戰(zhàn)案例3.2GB → 480MBWork Process 內(nèi)存配額內(nèi)表擴(kuò)容機(jī)制快照對(duì)比定位大戶(hù)按內(nèi)存降序排列APPEND預(yù)分配 / FREE釋放SELECT指定字段 / 對(duì)象池復(fù)用分批處理 / DELETEPACKSELECT *→指定字段一次性→分批循環(huán)NEW→對(duì)象池結(jié)果表定期PACK本篇學(xué)習(xí)目標(biāo)理解ABAP Work Process內(nèi)存的三層模型EM / Heap / Paging掌握SAT內(nèi)存分析功能能快速定位內(nèi)存熱點(diǎn)和泄漏點(diǎn)看懂內(nèi)表在內(nèi)存里的真實(shí)布局避免APPEND濫用導(dǎo)致的內(nèi)存碎片掌握預(yù)分配、及時(shí)清理、分批處理等內(nèi)存優(yōu)化核心技巧能獨(dú)立排查并修復(fù) OOMOut Of Memory問(wèn)題前置閱讀第二篇《核心工具入門(mén)》里SAT的基礎(chǔ)用法、第三篇里實(shí)戰(zhàn)案例的ST12時(shí)間分解部分。適用版本SAP NetWeaver 7.51一、ABAP內(nèi)存分配底層邏輯 1.1 為什么要懂底層┌─────────────────────────────────────────────────────────────────────────────────┐ │ 你以為的內(nèi)存 vs 實(shí)際的內(nèi)存 │ ├─────────────────────────────────────────────────────────────────────────────────┤ │ │ │ ? 你以為DATA聲明 → 系統(tǒng)自動(dòng)搞定內(nèi)存 → 用完自動(dòng)釋放 │ │ ? 實(shí)際 系統(tǒng)有嚴(yán)格的內(nèi)存配額Work Process內(nèi)存耗盡就Dump │ │ 即使你的邏輯正確內(nèi)存碎片也會(huì)讓系統(tǒng)分配不到連續(xù)空間 │ │ │ │ ? 你以為內(nèi)表APPEND就追加一行沒(méi)什么成本 │ │ ? 實(shí)際 APPEND如果沒(méi)有預(yù)留空間 → 每次都要重新申請(qǐng)更大的連續(xù)內(nèi)存塊 復(fù)制舊數(shù)據(jù) │ │ 10萬(wàn)次APPEND 10萬(wàn)次內(nèi)存分配 9萬(wàn)次數(shù)據(jù)拷貝 │ │ │ │ ? 你以為函數(shù)返回、內(nèi)表用完 → 內(nèi)存自動(dòng)釋放 │ │ ? 實(shí)際 Global Function / Class Static 變量 → 跟Work Process同壽命 │ │ Lcl變量 → 函數(shù)返回才釋放但如果內(nèi)表被EXPORT到Memory ID → 永遠(yuǎn)不釋放 │ │ │ │ 不懂底層 不懂你的代碼在干什么。 │ │ 很多內(nèi)存問(wèn)題不是Bug是默認(rèn)行為導(dǎo)致的。 │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘ 1.2 Work Process內(nèi)存三層模型共享內(nèi)存 Shared Memory多WP共享 / 表緩沖擴(kuò)展內(nèi)存 EM2GB配額 / 99%的變量在這里堆內(nèi)存 HeapEM不夠時(shí)使用 / 易碎片分頁(yè)區(qū) Paging磁盤(pán)交換 / 極慢層級(jí)說(shuō)明關(guān)鍵參數(shù)共享內(nèi)存多個(gè)WP共享表緩沖在這里只讀為主ST04/SM04查看擴(kuò)展內(nèi)存 EM99%的變量在此每個(gè)WP上限約2GBabap/heap_area_total堆內(nèi)存 HeapEM不夠時(shí)使用匿名對(duì)象/動(dòng)態(tài)內(nèi)表abap/heap_area_dyn分頁(yè)區(qū) Paging磁盤(pán)交換極慢優(yōu)化目標(biāo)永遠(yuǎn)不要走到這一步-一句話(huà)總結(jié)每個(gè)Work Process有2GB的賬戶(hù)額度用完就會(huì)透支到Heap再不行就Dump。 1.3 內(nèi)表的內(nèi)存布局最關(guān)鍵內(nèi)表底層是數(shù)組結(jié)構(gòu) 動(dòng)態(tài)擴(kuò)容機(jī)制擴(kuò)容是指數(shù)增長(zhǎng)的。初始 Capacity 0 APPEND 第1行 → 申請(qǐng) 80 bytes → Capacity 1 APPEND 第2行 → Capacity滿(mǎn)了申請(qǐng) 160 bytes → 復(fù)制舊行 → 加新行 APPEND 第3行 → Capacity滿(mǎn)了申請(qǐng) 320 bytes → 復(fù)制舊行 → 加新行 APPEND 第5行 → 申請(qǐng) 640 bytes → 復(fù)制舊4行 → 加新行 ... APPEND 第N行 → 每次翻倍擴(kuò)容10萬(wàn)行觸發(fā)約17次擴(kuò)容累計(jì)拷貝超300萬(wàn)行數(shù)據(jù)解決方案預(yù)分配初始行 聲明時(shí)預(yù)分配 DATA: gt_table TYPE TABLE OF ty_item WITH NON-UNIQUE DEFAULT KEY INITIAL SIZE 100000. 或運(yùn)行時(shí)動(dòng)態(tài)預(yù)分配N(xiāo)etWeaver 7.40 gt_table VALUE #( INITIAL SIZE lv_lines ).二、SAT內(nèi)存分析實(shí)戰(zhàn) 2.1 SAT不只是查CPU的SAT有四種分析模式其中Memory Analysis模式可做內(nèi)存快照對(duì)比精準(zhǔn)定位每個(gè)變量的內(nèi)存占用。模式啟動(dòng)方式核心輸出Time (CPU時(shí)間)默認(rèn)每個(gè)函數(shù)/代碼塊的CPU消耗Memory AnalysisSAT → Change Mode → Memory每個(gè)變量的內(nèi)存占用快照 快照對(duì)比CoverageChange Mode → Coverage代碼覆蓋情況Profile Parameters直接看程序內(nèi)動(dòng)態(tài)創(chuàng)建的對(duì)象/內(nèi)存統(tǒng)計(jì) 2.2 讀懂SAT內(nèi)存分析結(jié)果SAT Memory Inspector 結(jié)果頁(yè) ┌──────────────┬──────────────┬──────────────┬────────────┐ │ 變量名 │ 類(lèi)型 │ 當(dāng)前內(nèi)存 │ 內(nèi)存增長(zhǎng) │ ├──────────────┼──────────────┼──────────────┼────────────┤ │ GT_REPORT │ TABLE (STD) │ 2.1 GB │ 2.1 GB │ │ GT_MATERIAL │ TABLE (STD) │ 384.2 MB │ 384.2 MB │ │ MO_INSTANCE1 │ OBJECT │ 156.3 MB │ 156.3 MB │ └──────────────┴──────────────┴──────────────┴────────────┘解讀口訣按當(dāng)前內(nèi)存降序排列 → 前3名就是你的內(nèi)存大戶(hù) → 重點(diǎn)看50MB以上的條目 → 超過(guò)1GB 必須優(yōu)化?？煺諏?duì)比最重要的排查技巧程序執(zhí)行前拍快照A → 執(zhí)行關(guān)鍵代碼段 → 拍快照B → 差值為正 新增內(nèi)存差值為負(fù) 釋放內(nèi)存。如果函數(shù)返回后差值仍為正 → 內(nèi)存泄漏三、內(nèi)表濫用內(nèi)存問(wèn)題的頭號(hào)元兇 3.1 問(wèn)題一APPEND without INITIAL SIZE —— 擴(kuò)容風(fēng)暴寫(xiě)法APPEND 10萬(wàn)行內(nèi)存分配次數(shù)累積拷貝量? 無(wú)預(yù)分配12,800 ms17次約300萬(wàn)行 × 80B ≈ 240MB? INITIAL SIZE 10萬(wàn)1,500 ms1次0拷貝? SELECT INTO TABLE800 ms1次直接填充原則循環(huán)內(nèi)APPEND 5000行時(shí)必須預(yù)分配大內(nèi)表10000行建議預(yù)分配可預(yù)估行數(shù)時(shí)如從另一個(gè)內(nèi)表的LINES來(lái)直接預(yù)分配。 3.2 問(wèn)題二內(nèi)表沒(méi)釋放 —— 用完不刪留著過(guò)年場(chǎng)景ASELECT INTO TABLE 查了10萬(wàn)行占100MB只處理前100行就退出了內(nèi)表沒(méi)清空——100MB還掛在WP上。場(chǎng)景B三步處理流程中Step 1查VBAK占50MB、Step 2查VBAP占150MB、Step 3關(guān)聯(lián)匹配結(jié)果占200MB。Step 3完后VBAK和VBAP還在 → 總內(nèi)存400MB。正確做法Step 3完后立刻FREE中間表 → 總內(nèi)存從400MB降至200MB。REFRESH vs CLEAR vs FREE 選型指南指令效果適用場(chǎng)景CLEAR清空1行或結(jié)構(gòu)內(nèi)表只清表頭數(shù)據(jù)行還在清空結(jié)構(gòu)體REFRESH清空內(nèi)表所有行釋放數(shù)據(jù)內(nèi)存保留表頭空間內(nèi)表要繼續(xù)用、需要重用FREE釋放所有內(nèi)存連表頭一起清內(nèi)表徹底不用了實(shí)戰(zhàn)口訣內(nèi)表要繼續(xù)用 → REFRESH內(nèi)表徹底不用 → FREE循環(huán)內(nèi)臨時(shí)內(nèi)表 → 每次REFRESH PACK大數(shù)據(jù)量中間表 → 處理完立刻FREE。 3.3 問(wèn)題三內(nèi)表字段冗余 —— 只取所需不取所有字段選擇單行字節(jié)數(shù)100萬(wàn)行內(nèi)存DB時(shí)間SELECT *~520 bytes520 MB2,400 ms只選5個(gè)字段~60 bytes60 MB320 ms差距8.7倍8.7倍7.5倍四、全局變量與內(nèi)存泄漏看不見(jiàn)的隱形炸彈?? 4.1 ABAP里的5種內(nèi)存泄漏來(lái)源泄漏來(lái)源根因與后果Class Static 變量跟Work Process同壽命第一次執(zhí)行后就一直掛著Global Function 內(nèi)局部變量老版本ABAP的靜態(tài)內(nèi)存特性函數(shù)返回后不釋放EXPORT TO MEMORY IDEXPORT了但忘了IMPORT或DELETEREFRESH ON COMMIT 未及時(shí)提交刷新緩沖被延遲數(shù)據(jù)越積越多對(duì)象實(shí)例未釋放CREATE OBJECT / NEW 之后沒(méi)FREE?? 4.2 Class Static 變量泄漏最常見(jiàn)也最難防問(wèn)題Class Static屬性生命周期 Work Process整個(gè)生命周期。第一次NEW之后只要WP沒(méi)重啟內(nèi)存就一直在即使你退出了當(dāng)前程序也不會(huì)釋放。用戶(hù)A跑了1次占5MB用戶(hù)B又跑了1次累積占10MB一天200個(gè)用戶(hù)重復(fù)數(shù)據(jù)越來(lái)越多。修復(fù)方案一用實(shí)例屬性而非Static屬性隨對(duì)象生命周期釋放。修復(fù)方案二如果必須用Static真正需要緩存做去重大小限制——先查重已緩存就直接返回不再APPEND超過(guò)上限時(shí)REFRESH清空重來(lái)。五、大對(duì)象重復(fù)實(shí)例化構(gòu)造函數(shù)的隱形成本 5.1 對(duì)象創(chuàng)建到底有多重寫(xiě)法CPU耗時(shí)內(nèi)存增長(zhǎng)泄漏的對(duì)象實(shí)例數(shù)? 只NEW不FREE8.2秒520 MB1000個(gè) ? NEW 每次FREE但沒(méi)清內(nèi)部緩存15.6秒12 MB0但CPU翻倍? 對(duì)象池復(fù)用單次創(chuàng)建0.3秒52 MB0復(fù)用1個(gè)實(shí)例 5.2 對(duì)象池Object Pool復(fù)用技巧適合場(chǎng)景循環(huán)內(nèi)需要反復(fù)使用同一個(gè)復(fù)雜對(duì)象構(gòu)造函數(shù)開(kāi)銷(xiāo)大對(duì)象實(shí)例可以被重置到初始狀態(tài)有RESET方法。ABAP單WP是單線程的無(wú)并發(fā)安全問(wèn)題。模板代碼只創(chuàng)建一次對(duì)象 → 循環(huán)內(nèi)每次只做RESET → 用完FREE一次。對(duì)象池復(fù)用可讓CPU時(shí)間減少90%省掉反復(fù)構(gòu)造/析構(gòu)的開(kāi)銷(xiāo)。六、內(nèi)表數(shù)據(jù)拆分處理大數(shù)據(jù)量分塊是王道 6.1 當(dāng)數(shù)據(jù)超過(guò)內(nèi)存極限怎么辦每個(gè)WP的EM上限2GB加上其他變量占用實(shí)際安全線約100-200萬(wàn)行。超過(guò)這個(gè)量必須分塊處理。 6.2 三種分塊處理模式模式一SELECT分塊—— 用UP TO ... ROWS OFFSET分批查。?? OFFSET大時(shí)前面所有行都要跳過(guò)總行數(shù)很大時(shí)性能下降。模式二主鍵范圍分批推薦—— 每批查完后記住最后一條主鍵值下一批WHERE主鍵 上次最后一條。DB直接根據(jù)主鍵定位不需要OFFSET跳過(guò)每批查詢(xún)都是O(1)定位。適用主鍵是連續(xù)范圍數(shù)字ID的表。模式三內(nèi)表分批DELETE PACK—— 當(dāng)必須把所有中間結(jié)果存在一個(gè)內(nèi)表里時(shí)定期DELETE已處理的行 PACK TABLE釋放尾部預(yù)留空間。內(nèi)表刪除行后底層內(nèi)存不會(huì)自動(dòng)收縮一定要PACK否則內(nèi)存白白浪費(fèi)。七、完整實(shí)戰(zhàn)案例后臺(tái)訂單清算作業(yè)從3.2GB降到480MB 7.1 問(wèn)題定位SAT Memory Inspector 結(jié)果按內(nèi)存降序 ┌────────────────┬────────────────┬────────────────┐ │ 變量 │ 當(dāng)前內(nèi)存 │ 內(nèi)存增長(zhǎng) │ ├────────────────┼────────────────┼────────────────┤ │ GT_VBAK_MONTH │ 1,040 MB │ 1,040 MB │ │ GT_VBAP_MONTH │ 1,560 MB │ 1,560 MB │ │ GT_RESULT_ALL │ 420 MB │ 420 MB │ │ MO_PRICERULE │ 160 MB │ 160 MB │ └────────────────┴────────────────┴────────────────┘ 合計(jì)3,205 MB → 超過(guò)EM上限2GB根因① GT_VBAK_MONTH GT_VBAP_MONTH一次性SELECT *了300萬(wàn)行字段冗余嚴(yán)重 ② MO_PRICERULE循環(huán)創(chuàng)建5次每次帶100MB內(nèi)部緩存→內(nèi)存泄漏 ③ GT_RESULT_ALL前50萬(wàn)行已處理完但沒(méi)DELETEPACK ④ LCL_BUFFER循環(huán)內(nèi)每次REFRESH但沒(méi)PACK容量空間。 7.2 四項(xiàng)優(yōu)化落地優(yōu)化項(xiàng)優(yōu)化前優(yōu)化后提升① SELECT * → 指定字段 主鍵范圍分批2,600 MB25 MB峰值104倍② 對(duì)象池復(fù)用循環(huán)內(nèi)只NEW一次5次構(gòu)造1次構(gòu)造CPU節(jié)省90%③ 結(jié)果分批DELETE PACK420 MB累積380 MBPACK過(guò)釋放空洞④ 循環(huán)內(nèi)臨時(shí)表 REFRESH PACK未釋放預(yù)留空間釋放尾部空洞減少內(nèi)存碎片 7.3 效果驗(yàn)證指標(biāo)優(yōu)化前優(yōu)化后提升幅度內(nèi)存峰值3,200 MB480 MB6.7倍GT_VBAK VBAP 占用2,600 MB25 MB (峰值)104倍對(duì)象實(shí)例泄漏5個(gè) × 160MB1個(gè)無(wú)泄漏5倍APPEND 擴(kuò)容次數(shù)1001次預(yù)分配徹底消除作業(yè)成功率60%100%? 完全解決八、內(nèi)存優(yōu)化檢查清單 紅牌級(jí)必須改循環(huán)內(nèi)APPEND/INSERT → 有沒(méi)有INITIAL SIZE預(yù)分配SELECT INTO TABLE大數(shù)據(jù)量(10萬(wàn)行) → 有沒(méi)有分批處理CLASS-DATA / Static變量 → 有沒(méi)有無(wú)上限增長(zhǎng)風(fēng)險(xiǎn)CREATE OBJECT / NEW之后 → 有沒(méi)有FREEEXPORT TO MEMORY ID → 有沒(méi)有對(duì)應(yīng)DELETE內(nèi)表用完了 → 有沒(méi)有FREE/REFRESH循環(huán)內(nèi)臨時(shí)內(nèi)表 → 有沒(méi)有每次REFRESH PACK 黃牌級(jí)建議改SELECT * INTO TABLE → 能不能指定字段大數(shù)據(jù)量結(jié)果表(50萬(wàn)行) → 有沒(méi)有定期DELETE PACK聲明SORTED/HASHED TABLE → 數(shù)據(jù)量夠大嗎查找頻繁嗎循環(huán)內(nèi)頻繁NEW同類(lèi)對(duì)象 → 能不能用對(duì)象池復(fù)用DESCRIBE TABLE行數(shù)可以預(yù)知 → 有沒(méi)有INITIAL SIZE預(yù)分配 常規(guī)級(jí)好習(xí)慣內(nèi)表處理完部分行后 → DELETE PACK釋放空間程序退出前 → SAT快照確認(rèn)無(wú)異常大殘留內(nèi)存FUNCTION/CLASS全局變量 → 確認(rèn)必要的生命周期提交測(cè)試時(shí) → SAT Memory Analysis跑一遍記錄峰值九、總結(jié)核心知識(shí)回顧無(wú)預(yù)分配用完未釋放SELECT *Static泄漏循環(huán)NEW一次性加載內(nèi)存優(yōu)化流程STAT確認(rèn)峰值SAT Memory Analysis定位大戶(hù)分析原因INITIAL SIZEFREE / REFRESH指定字段改實(shí)例屬性對(duì)象池復(fù)用分批處理SAT驗(yàn)證 回歸測(cè)試編碼原則和DB優(yōu)化互補(bǔ)能用預(yù)分配就不用裸APPEND —— 省時(shí)間也省內(nèi)存碎片用完FREE是基本功 —— 函數(shù)結(jié)束前回頭掃一遍確保所有臨時(shí)變量都FREE了CLASS-DATA要謹(jǐn)慎 —— 寫(xiě)Static之前先問(wèn)自己這東西真的要跟WP同壽命嗎能分塊就不要一次塞 —— 超過(guò)10萬(wàn)行的處理先想分批方案對(duì)象池是好東西 —— 但前提是對(duì)象能被RESET成初始狀態(tài)下一篇預(yù)告《業(yè)務(wù)邏輯層性能優(yōu)化循環(huán)嵌套、冗余計(jì)算、低效算法的優(yōu)化技巧》作者愛(ài)喝水的魚(yú)丶版本記錄2026年8月 你在ABAP內(nèi)存優(yōu)化中踩過(guò)哪些坑有沒(méi)有用SAT內(nèi)存分析發(fā)現(xiàn)過(guò)意想不到的內(nèi)存大戶(hù)歡迎分享你的優(yōu)化故事。 SAP-ABAP：程序內(nèi)存優(yōu)化——內(nèi)表濫用、內(nèi)存泄漏、大對(duì)象占用的排查與優(yōu)化方案
ABAP核心進(jìn)階篇120篇調(diào)試與性能優(yōu)化20篇第四篇ABAP程序內(nèi)存優(yōu)化——內(nèi)表濫用、內(nèi)存泄漏、大對(duì)象占用的排查與優(yōu)化方案博客標(biāo)題《ABAP程序內(nèi)存優(yōu)化內(nèi)表濫用、內(nèi)存泄漏、大對(duì)象占用的排查與優(yōu)化方案》博客簡(jiǎn)介講解ABAP程序內(nèi)存分配的底層邏輯結(jié)合SAT內(nèi)存分析功能定位內(nèi)表未釋放、全局變量冗余、大對(duì)象重復(fù)實(shí)例化等內(nèi)存問(wèn)題分享內(nèi)表初始行預(yù)分配、無(wú)用數(shù)據(jù)及時(shí)清理、對(duì)象池復(fù)用、內(nèi)表數(shù)據(jù)拆分處理的優(yōu)化技巧解決程序運(yùn)行時(shí)內(nèi)存溢出、系統(tǒng)資源占用過(guò)高問(wèn)題。 寫(xiě)在前面上一篇我們把數(shù)據(jù)庫(kù)性能這塊啃下來(lái)了——通過(guò)ST05定位慢SQL、用FATE替代循環(huán)內(nèi)SELECT、給大表加合適的索引把一個(gè)210秒的報(bào)表干到了12.5秒。但故事到這里還沒(méi)完。當(dāng)DB時(shí)間被優(yōu)化到極致或者程序干脆是CPU密集型時(shí)下一個(gè)瓶頸就浮出水面了——內(nèi)存。你一定見(jiàn)過(guò)這些場(chǎng)景報(bào)表跑到一半突然Memory Consumption has Exceeded the Limit然后Dump后臺(tái)作業(yè)被管理員Kill掉SAT里80%的CPU時(shí)間花在內(nèi)表操作上多用戶(hù)同時(shí)跑同一個(gè)程序系統(tǒng)整體內(nèi)存飄紅。這些問(wèn)題的根源都是內(nèi)存使用不當(dāng)。內(nèi)存優(yōu)化全景底層模型EM(2GB)/Heap/Paging排查工具SAT Memory Analysis反模式修復(fù)預(yù)分配/釋放/分批/對(duì)象池實(shí)戰(zhàn)案例3.2GB → 480MBWork Process 內(nèi)存配額內(nèi)表擴(kuò)容機(jī)制快照對(duì)比定位大戶(hù)按內(nèi)存降序排列APPEND預(yù)分配 / FREE釋放SELECT指定字段 / 對(duì)象池復(fù)用分批處理 / DELETEPACKSELECT *→指定字段一次性→分批循環(huán)NEW→對(duì)象池結(jié)果表定期PACK本篇學(xué)習(xí)目標(biāo)理解ABAP Work Process內(nèi)存的三層模型EM / Heap / Paging掌握SAT內(nèi)存分析功能能快速定位內(nèi)存熱點(diǎn)和泄漏點(diǎn)看懂內(nèi)表在內(nèi)存里的真實(shí)布局避免APPEND濫用導(dǎo)致的內(nèi)存碎片掌握預(yù)分配、及時(shí)清理、分批處理等內(nèi)存優(yōu)化核心技巧能獨(dú)立排查并修復(fù) OOMOut Of Memory問(wèn)題前置閱讀第二篇《核心工具入門(mén)》里SAT的基礎(chǔ)用法、第三篇里實(shí)戰(zhàn)案例的ST12時(shí)間分解部分。適用版本SAP NetWeaver 7.51一、ABAP內(nèi)存分配底層邏輯 1.1 為什么要懂底層┌─────────────────────────────────────────────────────────────────────────────────┐ │ 你以為的內(nèi)存 vs 實(shí)際的內(nèi)存 │ ├─────────────────────────────────────────────────────────────────────────────────┤ │ │ │ ? 你以為DATA聲明 → 系統(tǒng)自動(dòng)搞定內(nèi)存 → 用完自動(dòng)釋放 │ │ ? 實(shí)際 系統(tǒng)有嚴(yán)格的內(nèi)存配額Work Process內(nèi)存耗盡就Dump │ │ 即使你的邏輯正確內(nèi)存碎片也會(huì)讓系統(tǒng)分配不到連續(xù)空間 │ │ │ │ ? 你以為內(nèi)表APPEND就追加一行沒(méi)什么成本 │ │ ? 實(shí)際 APPEND如果沒(méi)有預(yù)留空間 → 每次都要重新申請(qǐng)更大的連續(xù)內(nèi)存塊 復(fù)制舊數(shù)據(jù) │ │ 10萬(wàn)次APPEND 10萬(wàn)次內(nèi)存分配 9萬(wàn)次數(shù)據(jù)拷貝 │ │ │ │ ? 你以為函數(shù)返回、內(nèi)表用完 → 內(nèi)存自動(dòng)釋放 │ │ ? 實(shí)際 Global Function / Class Static 變量 → 跟Work Process同壽命 │ │ Lcl變量 → 函數(shù)返回才釋放但如果內(nèi)表被EXPORT到Memory ID → 永遠(yuǎn)不釋放 │ │ │ │ 不懂底層 不懂你的代碼在干什么。 │ │ 很多內(nèi)存問(wèn)題不是Bug是默認(rèn)行為導(dǎo)致的。 │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘ 1.2 Work Process內(nèi)存三層模型共享內(nèi)存 Shared Memory多WP共享 / 表緩沖擴(kuò)展內(nèi)存 EM2GB配額 / 99%的變量在這里堆內(nèi)存 HeapEM不夠時(shí)使用 / 易碎片分頁(yè)區(qū) Paging磁盤(pán)交換 / 極慢層級(jí)說(shuō)明關(guān)鍵參數(shù)共享內(nèi)存多個(gè)WP共享表緩沖在這里只讀為主ST04/SM04查看擴(kuò)展內(nèi)存 EM99%的變量在此每個(gè)WP上限約2GBabap/heap_area_total堆內(nèi)存 HeapEM不夠時(shí)使用匿名對(duì)象/動(dòng)態(tài)內(nèi)表abap/heap_area_dyn分頁(yè)區(qū) Paging磁盤(pán)交換極慢優(yōu)化目標(biāo)永遠(yuǎn)不要走到這一步-一句話(huà)總結(jié)每個(gè)Work Process有2GB的賬戶(hù)額度用完就會(huì)透支到Heap再不行就Dump。 1.3 內(nèi)表的內(nèi)存布局最關(guān)鍵內(nèi)表底層是數(shù)組結(jié)構(gòu) 動(dòng)態(tài)擴(kuò)容機(jī)制擴(kuò)容是指數(shù)增長(zhǎng)的。初始 Capacity 0 APPEND 第1行 → 申請(qǐng) 80 bytes → Capacity 1 APPEND 第2行 → Capacity滿(mǎn)了申請(qǐng) 160 bytes → 復(fù)制舊行 → 加新行 APPEND 第3行 → Capacity滿(mǎn)了申請(qǐng) 320 bytes → 復(fù)制舊行 → 加新行 APPEND 第5行 → 申請(qǐng) 640 bytes → 復(fù)制舊4行 → 加新行 ... APPEND 第N行 → 每次翻倍擴(kuò)容10萬(wàn)行觸發(fā)約17次擴(kuò)容累計(jì)拷貝超300萬(wàn)行數(shù)據(jù)解決方案預(yù)分配初始行 聲明時(shí)預(yù)分配 DATA: gt_table TYPE TABLE OF ty_item WITH NON-UNIQUE DEFAULT KEY INITIAL SIZE 100000. 或運(yùn)行時(shí)動(dòng)態(tài)預(yù)分配N(xiāo)etWeaver 7.40 gt_table VALUE #( INITIAL SIZE lv_lines ).二、SAT內(nèi)存分析實(shí)戰(zhàn) 2.1 SAT不只是查CPU的SAT有四種分析模式其中Memory Analysis模式可做內(nèi)存快照對(duì)比精準(zhǔn)定位每個(gè)變量的內(nèi)存占用。模式啟動(dòng)方式核心輸出Time (CPU時(shí)間)默認(rèn)每個(gè)函數(shù)/代碼塊的CPU消耗Memory AnalysisSAT → Change Mode → Memory每個(gè)變量的內(nèi)存占用快照 快照對(duì)比CoverageChange Mode → Coverage代碼覆蓋情況Profile Parameters直接看程序內(nèi)動(dòng)態(tài)創(chuàng)建的對(duì)象/內(nèi)存統(tǒng)計(jì) 2.2 讀懂SAT內(nèi)存分析結(jié)果SAT Memory Inspector 結(jié)果頁(yè) ┌──────────────┬──────────────┬──────────────┬────────────┐ │ 變量名 │ 類(lèi)型 │ 當(dāng)前內(nèi)存 │ 內(nèi)存增長(zhǎng) │ ├──────────────┼──────────────┼──────────────┼────────────┤ │ GT_REPORT │ TABLE (STD) │ 2.1 GB │ 2.1 GB │ │ GT_MATERIAL │ TABLE (STD) │ 384.2 MB │ 384.2 MB │ │ MO_INSTANCE1 │ OBJECT │ 156.3 MB │ 156.3 MB │ └──────────────┴──────────────┴──────────────┴────────────┘解讀口訣按當(dāng)前內(nèi)存降序排列 → 前3名就是你的內(nèi)存大戶(hù) → 重點(diǎn)看50MB以上的條目 → 超過(guò)1GB 必須優(yōu)化?？煺諏?duì)比最重要的排查技巧程序執(zhí)行前拍快照A → 執(zhí)行關(guān)鍵代碼段 → 拍快照B → 差值為正 新增內(nèi)存差值為負(fù) 釋放內(nèi)存。如果函數(shù)返回后差值仍為正 → 內(nèi)存泄漏三、內(nèi)表濫用內(nèi)存問(wèn)題的頭號(hào)元兇 3.1 問(wèn)題一APPEND without INITIAL SIZE —— 擴(kuò)容風(fēng)暴寫(xiě)法APPEND 10萬(wàn)行內(nèi)存分配次數(shù)累積拷貝量? 無(wú)預(yù)分配12,800 ms17次約300萬(wàn)行 × 80B ≈ 240MB? INITIAL SIZE 10萬(wàn)1,500 ms1次0拷貝? SELECT INTO TABLE800 ms1次直接填充原則循環(huán)內(nèi)APPEND 5000行時(shí)必須預(yù)分配大內(nèi)表10000行建議預(yù)分配可預(yù)估行數(shù)時(shí)如從另一個(gè)內(nèi)表的LINES來(lái)直接預(yù)分配。 3.2 問(wèn)題二內(nèi)表沒(méi)釋放 —— 用完不刪留著過(guò)年場(chǎng)景ASELECT INTO TABLE 查了10萬(wàn)行占100MB只處理前100行就退出了內(nèi)表沒(méi)清空——100MB還掛在WP上。場(chǎng)景B三步處理流程中Step 1查VBAK占50MB、Step 2查VBAP占150MB、Step 3關(guān)聯(lián)匹配結(jié)果占200MB。Step 3完后VBAK和VBAP還在 → 總內(nèi)存400MB。正確做法Step 3完后立刻FREE中間表 → 總內(nèi)存從400MB降至200MB。REFRESH vs CLEAR vs FREE 選型指南指令效果適用場(chǎng)景CLEAR清空1行或結(jié)構(gòu)內(nèi)表只清表頭數(shù)據(jù)行還在清空結(jié)構(gòu)體REFRESH清空內(nèi)表所有行釋放數(shù)據(jù)內(nèi)存保留表頭空間內(nèi)表要繼續(xù)用、需要重用FREE釋放所有內(nèi)存連表頭一起清內(nèi)表徹底不用了實(shí)戰(zhàn)口訣內(nèi)表要繼續(xù)用 → REFRESH內(nèi)表徹底不用 → FREE循環(huán)內(nèi)臨時(shí)內(nèi)表 → 每次REFRESH PACK大數(shù)據(jù)量中間表 → 處理完立刻FREE。 3.3 問(wèn)題三內(nèi)表字段冗余 —— 只取所需不取所有字段選擇單行字節(jié)數(shù)100萬(wàn)行內(nèi)存DB時(shí)間SELECT *~520 bytes520 MB2,400 ms只選5個(gè)字段~60 bytes60 MB320 ms差距8.7倍8.7倍7.5倍四、全局變量與內(nèi)存泄漏看不見(jiàn)的隱形炸彈?? 4.1 ABAP里的5種內(nèi)存泄漏來(lái)源泄漏來(lái)源根因與后果Class Static 變量跟Work Process同壽命第一次執(zhí)行后就一直掛著Global Function 內(nèi)局部變量老版本ABAP的靜態(tài)內(nèi)存特性函數(shù)返回后不釋放EXPORT TO MEMORY IDEXPORT了但忘了IMPORT或DELETEREFRESH ON COMMIT 未及時(shí)提交刷新緩沖被延遲數(shù)據(jù)越積越多對(duì)象實(shí)例未釋放CREATE OBJECT / NEW 之后沒(méi)FREE?? 4.2 Class Static 變量泄漏最常見(jiàn)也最難防問(wèn)題Class Static屬性生命周期 Work Process整個(gè)生命周期。第一次NEW之后只要WP沒(méi)重啟內(nèi)存就一直在即使你退出了當(dāng)前程序也不會(huì)釋放。用戶(hù)A跑了1次占5MB用戶(hù)B又跑了1次累積占10MB一天200個(gè)用戶(hù)重復(fù)數(shù)據(jù)越來(lái)越多。修復(fù)方案一用實(shí)例屬性而非Static屬性隨對(duì)象生命周期釋放。修復(fù)方案二如果必須用Static真正需要緩存做去重大小限制——先查重已緩存就直接返回不再APPEND超過(guò)上限時(shí)REFRESH清空重來(lái)。五、大對(duì)象重復(fù)實(shí)例化構(gòu)造函數(shù)的隱形成本 5.1 對(duì)象創(chuàng)建到底有多重寫(xiě)法CPU耗時(shí)內(nèi)存增長(zhǎng)泄漏的對(duì)象實(shí)例數(shù)? 只NEW不FREE8.2秒520 MB1000個(gè) ? NEW 每次FREE但沒(méi)清內(nèi)部緩存15.6秒12 MB0但CPU翻倍? 對(duì)象池復(fù)用單次創(chuàng)建0.3秒52 MB0復(fù)用1個(gè)實(shí)例 5.2 對(duì)象池Object Pool復(fù)用技巧適合場(chǎng)景循環(huán)內(nèi)需要反復(fù)使用同一個(gè)復(fù)雜對(duì)象構(gòu)造函數(shù)開(kāi)銷(xiāo)大對(duì)象實(shí)例可以被重置到初始狀態(tài)有RESET方法。ABAP單WP是單線程的無(wú)并發(fā)安全問(wèn)題。模板代碼只創(chuàng)建一次對(duì)象 → 循環(huán)內(nèi)每次只做RESET → 用完FREE一次。對(duì)象池復(fù)用可讓CPU時(shí)間減少90%省掉反復(fù)構(gòu)造/析構(gòu)的開(kāi)銷(xiāo)。六、內(nèi)表數(shù)據(jù)拆分處理大數(shù)據(jù)量分塊是王道 6.1 當(dāng)數(shù)據(jù)超過(guò)內(nèi)存極限怎么辦每個(gè)WP的EM上限2GB加上其他變量占用實(shí)際安全線約100-200萬(wàn)行。超過(guò)這個(gè)量必須分塊處理。 6.2 三種分塊處理模式模式一SELECT分塊—— 用UP TO ... ROWS OFFSET分批查。?? OFFSET大時(shí)前面所有行都要跳過(guò)總行數(shù)很大時(shí)性能下降。模式二主鍵范圍分批推薦—— 每批查完后記住最后一條主鍵值下一批WHERE主鍵 上次最后一條。DB直接根據(jù)主鍵定位不需要OFFSET跳過(guò)每批查詢(xún)都是O(1)定位。適用主鍵是連續(xù)范圍數(shù)字ID的表。模式三內(nèi)表分批DELETE PACK—— 當(dāng)必須把所有中間結(jié)果存在一個(gè)內(nèi)表里時(shí)定期DELETE已處理的行 PACK TABLE釋放尾部預(yù)留空間。內(nèi)表刪除行后底層內(nèi)存不會(huì)自動(dòng)收縮一定要PACK否則內(nèi)存白白浪費(fèi)。七、完整實(shí)戰(zhàn)案例后臺(tái)訂單清算作業(yè)從3.2GB降到480MB 7.1 問(wèn)題定位SAT Memory Inspector 結(jié)果按內(nèi)存降序 ┌────────────────┬────────────────┬────────────────┐ │ 變量 │ 當(dāng)前內(nèi)存 │ 內(nèi)存增長(zhǎng) │ ├────────────────┼────────────────┼────────────────┤ │ GT_VBAK_MONTH │ 1,040 MB │ 1,040 MB │ │ GT_VBAP_MONTH │ 1,560 MB │ 1,560 MB │ │ GT_RESULT_ALL │ 420 MB │ 420 MB │ │ MO_PRICERULE │ 160 MB │ 160 MB │ └────────────────┴────────────────┴────────────────┘ 合計(jì)3,205 MB → 超過(guò)EM上限2GB根因① GT_VBAK_MONTH GT_VBAP_MONTH一次性SELECT *了300萬(wàn)行字段冗余嚴(yán)重 ② MO_PRICERULE循環(huán)創(chuàng)建5次每次帶100MB內(nèi)部緩存→內(nèi)存泄漏 ③ GT_RESULT_ALL前50萬(wàn)行已處理完但沒(méi)DELETEPACK ④ LCL_BUFFER循環(huán)內(nèi)每次REFRESH但沒(méi)PACK容量空間。 7.2 四項(xiàng)優(yōu)化落地優(yōu)化項(xiàng)優(yōu)化前優(yōu)化后提升① SELECT * → 指定字段 主鍵范圍分批2,600 MB25 MB峰值104倍② 對(duì)象池復(fù)用循環(huán)內(nèi)只NEW一次5次構(gòu)造1次構(gòu)造CPU節(jié)省90%③ 結(jié)果分批DELETE PACK420 MB累積380 MBPACK過(guò)釋放空洞④ 循環(huán)內(nèi)臨時(shí)表 REFRESH PACK未釋放預(yù)留空間釋放尾部空洞減少內(nèi)存碎片 7.3 效果驗(yàn)證指標(biāo)優(yōu)化前優(yōu)化后提升幅度內(nèi)存峰值3,200 MB480 MB6.7倍GT_VBAK VBAP 占用2,600 MB25 MB (峰值)104倍對(duì)象實(shí)例泄漏5個(gè) × 160MB1個(gè)無(wú)泄漏5倍APPEND 擴(kuò)容次數(shù)1001次預(yù)分配徹底消除作業(yè)成功率60%100%? 完全解決八、內(nèi)存優(yōu)化檢查清單 紅牌級(jí)必須改循環(huán)內(nèi)APPEND/INSERT → 有沒(méi)有INITIAL SIZE預(yù)分配SELECT INTO TABLE大數(shù)據(jù)量(10萬(wàn)行) → 有沒(méi)有分批處理CLASS-DATA / Static變量 → 有沒(méi)有無(wú)上限增長(zhǎng)風(fēng)險(xiǎn)CREATE OBJECT / NEW之后 → 有沒(méi)有FREEEXPORT TO MEMORY ID → 有沒(méi)有對(duì)應(yīng)DELETE內(nèi)表用完了 → 有沒(méi)有FREE/REFRESH循環(huán)內(nèi)臨時(shí)內(nèi)表 → 有沒(méi)有每次REFRESH PACK 黃牌級(jí)建議改SELECT * INTO TABLE → 能不能指定字段大數(shù)據(jù)量結(jié)果表(50萬(wàn)行) → 有沒(méi)有定期DELETE PACK聲明SORTED/HASHED TABLE → 數(shù)據(jù)量夠大嗎查找頻繁嗎循環(huán)內(nèi)頻繁NEW同類(lèi)對(duì)象 → 能不能用對(duì)象池復(fù)用DESCRIBE TABLE行數(shù)可以預(yù)知 → 有沒(méi)有INITIAL SIZE預(yù)分配 常規(guī)級(jí)好習(xí)慣內(nèi)表處理完部分行后 → DELETE PACK釋放空間程序退出前 → SAT快照確認(rèn)無(wú)異常大殘留內(nèi)存FUNCTION/CLASS全局變量 → 確認(rèn)必要的生命周期提交測(cè)試時(shí) → SAT Memory Analysis跑一遍記錄峰值九、總結(jié)核心知識(shí)回顧無(wú)預(yù)分配用完未釋放SELECT *Static泄漏循環(huán)NEW一次性加載內(nèi)存優(yōu)化流程STAT確認(rèn)峰值SAT Memory Analysis定位大戶(hù)分析原因INITIAL SIZEFREE / REFRESH指定字段改實(shí)例屬性對(duì)象池復(fù)用分批處理SAT驗(yàn)證 回歸測(cè)試編碼原則和DB優(yōu)化互補(bǔ)能用預(yù)分配就不用裸APPEND —— 省時(shí)間也省內(nèi)存碎片用完FREE是基本功 —— 函數(shù)結(jié)束前回頭掃一遍確保所有臨時(shí)變量都FREE了CLASS-DATA要謹(jǐn)慎 —— 寫(xiě)Static之前先問(wèn)自己這東西真的要跟WP同壽命嗎能分塊就不要一次塞 —— 超過(guò)10萬(wàn)行的處理先想分批方案對(duì)象池是好東西 —— 但前提是對(duì)象能被RESET成初始狀態(tài)下一篇預(yù)告《業(yè)務(wù)邏輯層性能優(yōu)化循環(huán)嵌套、冗余計(jì)算、低效算法的優(yōu)化技巧》作者愛(ài)喝水的魚(yú)丶版本記錄2026年8月 你在ABAP內(nèi)存優(yōu)化中踩過(guò)哪些坑有沒(méi)有用SAT內(nèi)存分析發(fā)現(xiàn)過(guò)意想不到的內(nèi)存大戶(hù)歡迎分享你的優(yōu)化故事。