java中“常驻内存”数据主要存于方法区（jdk 8+为元空间），包括类元数据、运行时常量池、静态变量、字节码、方法表等；字符串常量池（jdk 7+）和对象实例则分别存于堆和堆中。
Java 中没有“常驻内存”这个官方术语，但开发者常用来指代生命周期长、随类存在而存在、不随对象创建销毁而变化的数据。这类数据主要落在方法区（Method Area），尤其是 JDK 8+ 的元空间（Metaspace）中。
简单说：只要跟“类本身结构”强相关、不依赖具体对象实例的数据，基本都进方法区。
哪些数据明确进入方法区？
方法区是线程共享区域，存储的是 JVM 运行时所需的“类型级”元信息。以下内容在类加载阶段就被写入方法区：
- 类的元数据（Class Metadata）：类名、父类、实现的接口、访问修饰符（public / final / abstract 等）、字段和方法的签名信息
- 运行时常量池（Runtime Constant Pool）：编译期生成的字面量（如数字、字符串字面量注意：JDK 7+ 字符串常量池已移至堆）、符号引用（类/字段/方法的名称和描述符）
- 静态变量（static fields）：包括基本类型值和对象引用（注意：引用指向的对象本身在堆中，但引用变量存方法区）
- 类的字节码（Bytecode）：.class 文件被解析后存入方法区，供解释器或 JIT 编译器使用
- 方法表（vtable / itable）：用于动态分派，记录虚方法的实际入口地址
- 即时编译器生成的热点代码缓存（JIT Code Cache）：HotSpot 中这部分实际属于 CodeCache，虽逻辑上与方法区协同，但物理上独立；不过面试/理解时常一并归入“方法区范畴”
容易混淆的“看起来常驻”，其实不在方法区
有些数据虽然生命周期长，但存放位置另有归属，需特别注意：
-
字符串常量池（String Table）：JDK 7 起从方法区迁移到堆内存。所以
String s = "hello";的 "hello" 在堆里，不是方法区 -
静态变量引用的对象：如
static List<string> cache = new ArrayList();</string>，变量cache的引用存方法区，但new ArrayList()这个对象本身一定在堆中 - 类的实例对象（new 出来的）：无论是否被 static 引用，对象本体永远在堆；方法区只存它的“模板”（即 Class 对象）
- final 基本类型静态常量（如 static final int MAX = 100）：编译期可确定的，可能被直接内联，不一定真占方法区空间；但定义仍属于类元数据的一部分
方法区 ≠ 永久代，也不等于“永久不回收”
方法区是 JVM 规范概念，具体实现有演变：
- JDK 6 及以前：用永久代（PermGen）实现，空间固定，容易 OOM
- JDK 7：字符串常量池和静态变量逐步移出永久代
- JDK 8+：永久代被彻底移除，改用本地内存（Native Memory）实现的元空间（Metaspace），默认无上限（受限于系统内存），类卸载后空间可回收
也就是说，方法区的数据并非“一旦加载永不释放”。当类被卸载（如 Web 容器热部署、OSGi 场景），其元数据会从方法区清除——前提是该类加载器本身也被 GC 掉。
怎么验证某个东西进了方法区？
可通过 JVM 参数配合工具观察：
- 启动时加
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，关注 Full GC 是否触发 Metaspace 回收 - 用
jstat -gc <pid></pid>查看MU（Metaspace Used）和MC（Metaspace Capacity） - 用
jmap -histo:live <pid></pid>或 JConsole / VisualVM 查看类加载数量与 Metaspace 使用趋势 - 故意加载大量动态类（如 CGLIB 代理、Groovy 脚本），观察 Metaspace 是否持续增长甚至 OOM（
java.lang.OutOfMemoryError: Metaspace）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
