JVMTI 不提供容器对象内存的精确深大小测量，仅支持浅大小获取与基础遍历；需手动实现对象图遍历、字段解析、重复引用检测及对齐计算，结合压缩指针状态估算真实占用。
JVMTI（JVM Tool Interface）本身不直接提供对象堆内存占用的精确测量能力，尤其对“容器对象”（如 ArrayList、HashMap 等）的实际内存消耗，需结合对象图遍历、字段偏移计算与对象头/对齐规则综合估算。单纯依赖 JVMTI 的 GetObjectsWithTags 或 IterateThroughHeap 只能获取对象引用和基础大小，无法自动展开内部引用结构或识别容器持有的元素所占空间。
理解容器对象内存占用的组成
一个容器对象（如 ArrayList）的总堆内存 = 自身对象开销 + 数组引用字段 + 底层数组对象（如 Object[]）+ 数组中每个非 null 元素对象的深大小（若需“实际占用”）。JVMTI 不内置深大小计算，必须手动实现对象图遍历与重复引用检测。
- 自身对象：约 12–16 字节（含对象头、类指针、对齐填充）
- 底层数组：如
elementData是Object[10]，则数组对象本身约 24 字节 + 10 × 4（或 8）字节引用空间（取决于压缩指针是否开启） - 元素对象：若元素是 String、自定义 POJO 等，需递归计算其字段引用的对象——这一步 JVMTI 不自动做，需你用
GetFieldName/GetFieldModifiers解析字段类型，并用GetThreadLocalStorage配合自定义标记做去重遍历
用 JVMTI 获取容器对象基础信息的关键步骤
可在 VMInit 回调中启用 heap iteration，并在 IterateThroughHeap 中按 class tag 过滤目标容器类（如 tag 对应 java/util/ArrayList），再调用 GetTag 和 GetClassSignature 确认类型。对每个匹配对象，使用 GetFieldDeclaringClass 和 GetFieldName 定位关键字段（如 elementData、table），再通过 GetFieldValue 提取其值（即数组或 Node[] 引用）。
- 注意：
GetFieldValue返回的是jobject，需再次调用GetTag判断是否已处理过该数组，避免重复计数 - 数组长度可用
GetArrayLength获取；数组元素类型用GetArrayClass+GetClassSignature区分是对象数组还是基本类型数组 - 对
HashMap这类结构，还需解析Node链表或红黑树节点，逐个读取key、value字段并递归追踪
补充说明：为什么不能只信 GetObjectSize
JVMTI 的 GetObjectSize 仅返回对象自身的 shallow size（浅大小），不含它引用的其他对象。例如 ArrayList 调用 GetObjectSize 可能只返回 24 字节，而它持有的 1000 个字符串对象完全不计入——这显然不是“实际占用”。真实监控需构建可达性图，等价于实现一个轻量级的“内存分析器内核”，JVMTI 提供的是探针和钩子，不是现成的内存报告工具。
- 建议配合
-XX:+UseCompressedOops状态判断指针宽度（影响字段偏移和数组引用大小） - 生产环境慎用全堆遍历：
IterateThroughHeap会触发全局安全点，可能引起明显 STW 延迟 - 更实用的做法是：先用 JVMTI 标记可疑容器实例（如 size > 1000 的 ArrayList），再在 GC 后用
FollowReferences按需做局部深遍历
替代方案与工程建议
若目标是可观测、低开销的容器内存监控，优先考虑 JVM 自带机制：
-
JFR（Java Flight Recorder）：开启
jdk.ObjectAllocationInNewTLAB和jdk.ObjectAllocationOutsideTLAB事件，配合堆转储分析容器创建热点 -
Heap Dump + MAT / JProfiler：用
jmap -dump抓取快照后，在 MAT 中用 OQL 查询SELECT * FROM java.util.ArrayList WHERE @size > 500，再用“Merge Shortest Paths to GC Roots”看谁在持有多大数据 -
Agent + Instrumentation：比 JVMTI 更易上手，用
java.lang.instrument在ArrayList.add等方法插桩，记录 size 变化与引用关系，适合业务侧定制化埋点
