死循环内反复创建大数组会导致物理内存秒级耗尽，关键在局部变量+大容量+重复堆分配叠加；需通过代码搜索、内存快照和崩溃日志精准定位并修复。
死循环内反复创建大数组，不是“慢耗尽”，而是几轮迭代就让物理内存告急——关键在“局部变量+大容量+重复堆分配”三者叠加。它不靠泄漏，靠蛮力填满内存页；不靠递归，靠每轮都抢几 MB 甚至上百 MB。排查要快、准、实证，不能只看日志猜。
一眼锁定循环体内非法数组声明
重点不是“有没有循环”，而是“循环里有没有new或等效分配”。直接搜索以下模式：
- Java：
new int\[.*?\]\[.*?\]、new byte\[.*?\]\[.*?\]，尤其带具体数字的如new int[2000][2000] - C/C++：
malloc\(|new.*\[.*?\]\[.*?\]|vector<vector>>\(.*?[0-9]+.*?\)</vector>，注意隐式分配如std::vector<:vector>>(1000, std::vector<int>(1000))</int></:vector> - Python：
\[\[.*?\]\s*for.*?in.*?\]或numpy.zeros\((\d+,\s*\d+)\)出现在while True:或for _ in range(...):内部
用内存快照确认“秒级暴涨”而非缓慢增长
别等 OOM 才行动。在循环开头插入轻量级内存采样：
- Java：用
Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()记录已用堆，打印前加i++计数 - Python：用
psutil.Process().memory_info().rss（单位字节），每 3–5 次迭代打一次点 - C/C++（Linux）：读
/proc/self/status中的VmRSS:行，简单高效
若第 1 次迭代后 RSS 增加 40MB，第 2 次再 +40MB，第 3 次又 +40MB——基本可断定是同一块大数组被反复 new，旧对象还没来得及回收。
区分崩溃表象：是物理内存爆了，还是进程被系统杀掉？
表现不同，根因不同：
- Java 报
java.lang.OutOfMemoryError: Java heap space→ JVM 堆设限被冲破，但系统还有空闲内存 - Java 报
Killed by signal 9 (SIGKILL)或 Linux dmesg 显示Out of memory: Kill process→ 真正的物理内存/swap 耗尽，OOM Killer 主动干掉进程 - C/C++ 程序直接
Segmentation fault或静默退出 → 可能是 malloc 返回 NULL 后未检查，后续解引用崩了；也可能是栈上声明超限（如int a[10000][10000]），但这种情况通常第一轮就崩，不会“瞬间耗尽”
修复必须切断“每轮都申请”的链条
核心就一条：大数组不进循环体。操作方式取决于语言习惯：
- Java：把
int[][] buffer = new int[1000][1000];提到 while 外，循环内只做Arrays.fill()或双层 for 清零 - C++：用
std::vector<:vector>> buffer(1000, std::vector<int>(1000));</int></:vector>在循环外定义，循环内调用buffer.clear(); buffer.resize(1000, std::vector<int>(1000));</int>（更推荐 assign 或 fill） - Python：改用
numpy.empty((1000,1000), dtype=int)预分配，循环中用arr.fill(0)或切片赋值，避免np.zeros重建
如果逻辑真需要每次不同结构，至少加上尺寸校验和内存余量判断，比如先查 psutil.virtual_memory().available 是否低于阈值，再决定是否继续。
