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