类变量（static字段）实际存于堆中，而非方法区；实例变量一定在堆里，但可能被JIT栈上分配；局部变量存于栈帧；数组对象在堆，元素依类型分别存储。
类变量（static字段）存在方法区，但JVM 8+实际在堆里
Java规范说类变量存方法区，但HotSpot从JVM 7开始把类元数据移到元空间（Native内存），而static字段本身——包括引用和基本类型值——全放在堆中。这是因为方法区只管类结构（如常量池、字段描述符），不存运行时数据。
常见错误现象：OutOfMemoryError: Metaspace只跟类定义数量有关，跟static字段大小无关；但大对象的static集合（比如static Map<string byte></string>）会撑爆堆，报OutOfMemoryError: Java heap space。
- 使用场景：工具类里的缓存、全局配置、单例引用——它们的生命期与类加载器绑定，但存储位置是堆
- 参数差异：无特殊JVM参数控制
static字段存放位置；-XX:MaxMetaspaceSize只管元空间，不管堆中静态数据 - 性能影响：访问
static字段比实例字段略快（少一次对象头偏移计算），但差别微乎其微；真正影响性能的是GC压力——长期存活的大static对象会卡在老年代，拖慢Full GC
实例变量一定在堆里，但可能被JIT优化掉
每个对象实例创建时，其所有实例变量（包括父类继承的）都作为对象布局的一部分，分配在堆中。这是确定行为，不随JVM版本变化。
容易踩的坑：看到“逃逸分析”就以为实例变量能上栈——其实JIT优化的是整个对象，不是单独拎出某个字段。只要对象没逃逸，它的全部字段都可能随对象一起分配在栈上（标量替换），但一旦逃逸（比如被传进Thread.start()或写入static字段），所有字段立刻回堆。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 使用场景：普通业务对象（如
User、Order）的字段，只要没被外部引用，JIT可能直接栈分配，避免GC - 验证方式：加
-XX:+PrintEscapeAnalysis -XX:+DoEscapeAnalysis看日志，注意JDK 16+默认关闭逃逸分析，需显式开启 - 兼容性影响：逃逸分析是HotSpot特有优化，OpenJ9、GraalVM等不一定支持；别依赖它做内存设计
局部变量不在堆也不在方法区，而在虚拟机栈帧里
虽然问题没问，但很多人混淆“变量存放位置”。方法内声明的局部变量（包括int、Object引用）既不存堆也不存方法区，而是在当前线程的虚拟机栈帧的局部变量表中。引用本身在这里，它指向的对象才在堆里。
典型错误现象：认为String s = "hello"的s在字符串常量池——其实s是栈上变量，"hello"字面量对象在堆（JDK 7+），常量池里只存指向它的引用。
- 参数差异：
-Xss控制栈大小，影响能同时存在的局部变量总量，但不影响堆内存使用 - 性能影响：栈分配极快，无GC开销；但递归过深或大量局部数组仍可能栈溢出（
StackOverflowError） - 注意：基本类型局部变量（如
int i = 5）完全不涉及堆，值就存在栈帧里
数组对象和元素的存放位置要分开看
数组本身是对象，所以数组引用变量按上述规则处理（局部则在栈，实例字段则在堆），但数组的**元素**存放位置取决于元素类型：
- 基本类型数组（如
int[]）：整个数组对象（含所有元素）都在堆中连续分配 - 引用类型数组（如
String[]）：数组对象本身在堆，每个槽位存一个引用（4或8字节），而这些引用指向的String对象，各自独立分配在堆中（可能分散） - 容易忽略的点：
new byte[1024 * 1024]这种大数组，即使只用一次，也会在堆中占1MB连续空间，容易触发CMS或G1的混合GC决策
复杂点在于：JVM对大数组有特殊分配策略（比如G1会优先尝试Humongous区），但开发者无法控制具体落在哪块堆内存——唯一能干预的是通过-XX:G1HeapRegionSize调整区域大小，间接影响大数组是否被标记为Humongous。
