Instrumentation.getObjectSize()返回对象浅层大小（shallow size），即对象头、实例字段及对齐填充所占堆内存，不含引用对象；必须通过-javaagent启动Agent并在premain中获取Instrumentation实例。
Instrumentation.getObjectSize 是 Java 提供的、用于估算对象**浅层内存占用（shallow size）** 的标准方式，但它不能精确测量变量或对象的实际运行时内存消耗，尤其不反映引用对象的深层结构、JVM 优化（如指针压缩、字段重排序）、堆外内存、GC 状态等。
它测的是什么？
该方法返回的是 JVM 认为该对象在堆上“当前分配的字节数”，主要包括：
- 对象头（mark word + class pointer，通常 8 或 12 字节，取决于是否开启指针压缩）
- 实例字段所占空间（按对齐规则补齐，例如 int 占 4 字节，但可能因前后字段导致 padding）
- 数组额外的长度字段（仅数组对象）
- 不包含：它所引用的其他对象（如 String 内部的 char[]、HashMap 的 Node 链表）、线程栈中的局部变量引用、常量池条目、JIT 编译代码、直接内存等
为什么说它“不精确”？
原因包括：
- 指针压缩（CompressedOops）开启时，对象引用占 4 字节而非 8 字节，但 Instrumentation 不暴露此上下文，结果依赖 JVM 启动参数（如 -XX:+UseCompressedOops）
- 字段重排序：JVM 可能调整字段声明顺序以减少 padding，实际布局与源码顺序不同，getObjectSize 返回的是运行时布局大小
- 无 GC 干预：它不触发 GC，也不考虑对象是否已被标记为可回收；返回值是“已分配但未必活跃”的快照
- 无法获取动态结构大小：例如 ArrayList 内部 elementData 数组可能很大，但只扩容未填满，getObjectSize 只算数组本身，不算其中 null 元素——但这不代表“有效数据”少，只是浅层统计
怎么用才更合理？
若需借助它做内存分析，建议：
- 确保 JVM 以相同参数（尤其是 -XX:+UseCompressedOops / -XX:-UseCompressedOops）启动，避免跨环境比较失真
- 配合 java.lang.instrument.Instrumentation 使用，需通过 Java Agent 注入（不能直接调用），典型流程：写 premain → 打 jar → 启动时加 -javaagent
- 对同一类多个实例多次测量，观察分布，避开个别因对齐导致的异常值
- 若要估算“总内存影响”，需手动递归计算引用关系（即 shallow size + retained size 估算），此时推荐用成熟的工具如 Eclipse MAT、VisualVM 或 JOL（Java Object Layout）
替代方案推荐
比 getObjectSize 更可靠的做法：
- JOL（Java Object Layout）：命令行或 API 方式输出对象内存布局详情（含字段偏移、padding、对齐），适合深度调试
- Heap dump + MAT 分析：真实捕获堆快照，计算 Retained Heap（即该对象被回收后能释放的总内存）
- Runtime.totalMemory() - Runtime.freeMemory()：粗粒度监控整体堆变化，需控制变量（如强制 GC 前后对比），适合宏观趋势观察
