数组实现内存分配统计的核心是用整型数组作为计数器集合记录各尺寸块分配频次，如count[4]对应8b/16b/32b/64b四类，按size区间自增对应下标，仅建模观测不替代malloc/free。

用数组实现内存分配统计，核心是把数组当作“计数器集合”来记录不同大小内存块的使用频次或剩余数量，而不是直接管理真实内存。它不替代malloc/free，而是对分配行为做轻量级建模和趋势观测。

用整型数组统计各尺寸块的分配次数

假设你关注的是 8B、16B、32B、64B 四类小内存块的申请频率，可定义：
int count[4] = {0}; // 下标0→8B, 1→16B, 2→32B, 3→64B
每次调用自定义分配函数 my_malloc(size) 时，根据 size 落入的区间，执行对应下标的自增：

• size ≤ 8 → count[0]++
• 8
• 16
• 32

运行一段时间后，打印 count 数组就能看出哪类尺寸被高频申请——比如 count[2] 持续飙升，说明程序存在大量中等对象（如小结构体），可能值得优化对象复用或池化。

用二维数组追踪变量生命周期与增长拐点

若想观察某类变量（如连接句柄、缓存条目）的数量随时间的变化，可用二维数组模拟时间切片快照：
int snapshot[10][2]; // 每行存 {时刻戳, 当前数量}，最多记录10次
在关键节点（如每秒、每次请求处理后）记录当前活跃变量数：

• snapshot[i][0] = current_time_ms();
• snapshot[i][1] = active_handles;

后续遍历该数组，计算相邻行的差值：snapshot[i][1] - snapshot[i-1][1]。若连续出现正向大跳变（如+50、+48、+52），说明变量增长进入线性加速期；若差值由正转负且幅度增大，则提示资源正在批量释放或泄漏已停止。

结合堆栈特征识别异常分配模式

单纯看数量不够，需关联内存位置特征。例如，在 Java 中可配合 jstack + 自定义 agent 获取每个 new int[n] 的调用栈深度和方法名，再用字符串数组暂存高频栈顶方法：

• String[] top_methods = new String[5]; // 记录调用最频繁的5个方法名
• int[] method_freq = new int[5]; // 对应频次

当发现 method_freq[0] 占总分配次数 70% 以上，且对应方法是某个循环内的临时数组创建，就暴露了典型冗余分配：本可用单个数组复用，却每次 new 出新实例。这时数组统计成了性能瓶颈的“定位探针”，而非仅是计数工具。

注意边界与失效场景

数组统计逻辑轻便，但有明显局限：

• 固定长度数组无法应对未知规模的尺寸分类，应预留 overflow 槽位或改用 HashMap
• 纯数值统计不保留地址/内容，无法判断是否同一块内存被重复释放或越界访问
• 多线程环境下需加锁或用 AtomicInteger[]，否则 count[i]++ 可能丢失更新
• 它反映的是“行为趋势”，不是内存镜像；要查真实泄漏，仍需 heap dump 配合 MAT 分析