高频创建大数组会导致堆内存压力剧增，引发频繁Minor GC和老年代缓慢增长，需通过GC日志、jstat和MAT分析定位分配热点与异常引用，修复应聚焦堆内存优化而非类加载机制。
在循环体内反复声明并初始化同名高维基本类型数组（如 int[][] arr = new int[100][100];），本身不会引发元空间（Metaspace）问题或类加载泄漏，但确实可能造成堆内存压力剧增，从而触发高频 Minor GC 甚至 Full GC。排查重点应落在堆分配行为、对象生命周期和引用管理上，而非怀疑“类重复加载”。
看 GC 日志确认是否为堆压力型高频回收
启用 -XX:+PrintGCDetails -Xloggc:gc.log 后，关注以下特征：
- Minor GC 频率极高（例如每秒数次），且每次 GC 前 Eden 区使用率持续接近 100%
- 单次 Minor GC 回收量小，Survivor 区占用低，说明对象几乎不存活过一次 GC
- GC Cause 大量为
Allocation Failure，而非Metadata GC Threshold或System.gc() - 老年代使用量（OU）缓慢但持续上升，尤其在循环密集执行时段
用 jstat 快速定位分配热点
执行 jstat -gc <pid> 2000（每 2 秒刷新），重点关注三组指标联动变化：
- EU（Eden 使用量）快速冲高又骤降：说明循环内持续批量分配大数组
- YGC 次数陡增，但 YGCT（Young GC 耗时）不高：符合轻量但高频的堆填充模式
- OC（老年代容量）稳定，OU（老年代已用）却明显爬升：提示部分数组因 Survivor 空间不足或晋升阈值低，提前进入老年代
检查数组是否被意外长期持有
高频创建本身未必致命，真正危险的是创建后未及时脱离作用域或被静态/缓存结构强引用：
- 检查该数组变量是否被添加进
static List<int[][]>、全局 Map 或线程局部缓存中 - 查看是否作为返回值暴露给外部，或被闭包、监听器、异步任务等捕获并延长生命周期
- 用 MAT 或 JVisualVM 打开堆 dump，按 class 过滤
[[I（二维 int 数组），再查其 GC Roots，确认持有链是否异常
做对照实验验证归因
不依赖猜测，用两个简单改动快速验证：
- 注释掉循环内
new int[N][M]语句，仅保留其余逻辑，观察 GC 频率是否显著下降 - 将
new int[100][100]替换为等体积对象（如new byte[40000]），若 GC 行为一致，说明是纯内存占用问题；若明显加剧，需检查是否伴随隐式装箱或额外对象创建
本质上，这不是 JVM 配置或类机制的问题，而是代码对堆资源的粗放使用。修复方向明确：减少单次数组尺寸、复用已有数组、改用流式处理或分块计算，避免在热路径上无节制地申请大块堆内存。
