JVM精华总结：堆（对象分配与GC主战场）、Metaspace（类元数据，热部署易OOM）、栈（线程私有，递归过深或-Xss过小致StackOverflowError）是排障核心；Minor GC频繁需查Eden大小与对象存活率，Full GC骤增先排查老年代/Metaspace耗尽或promotion failure；类加载双亲委派决定SPI和Web隔离机制，类卸载依赖类加载器回收；生产必配-Xms=-Xmx、-XX:MetaspaceSize/MaxMetaspaceSize、-Xlog:gc与-XX:+HeapDumpOnOutOfMemoryError。
写一份实用的 Java JVM 精华总结教程，关键不是堆砌概念，而是把真正影响开发、调优和排障的核心机制讲清楚、讲透，同时避免教科书式罗列。重点聚焦“哪些必须懂”“为什么重要”“怎么用得上”。
内存结构：搞清对象去哪儿了
JVM 内存不是一块大铁板，而是分区域协作的系统。重点盯住堆（Heap）、方法区（Metaspace）、栈（Stack）、本地方法栈和程序计数器这五块。其中堆和方法区最常出问题。
- 堆：所有对象实例分配地，又分新生代（Eden + 两个 Survivor）和老年代。GC 主战场，对象从 Eden 出生，熬过几次 Minor GC 才进老年代。
- 方法区（JDK 8+ 是 Metaspace）：存类信息、常量、静态变量、即时编译代码。Metaspace 使用本地内存，不会 OOM 堆空间，但可能耗尽系统内存——常见于热部署频繁或大量动态生成类（如某些 ORM、Groovy 脚本）。
-
栈：每个线程私有，存局部变量、操作数栈、方法调用链。栈深度超限（比如递归太深）会抛
StackOverflowError；栈总大小不够（-Xss 设置过小）则可能启动失败。
垃圾回收：别只背算法，要看它怎么动
GC 不是黑盒，理解它的触发时机、回收范围和停顿表现，才能合理选参数、定位问题。
- Minor GC 频繁？大概率是 Eden 太小，或对象“活得太久”（比如缓存没及时清理），导致大量对象提前晋升到老年代。
- Full GC 骤增？先查是否老年代真的满了，还是 Metaspace 耗尽、System.gc() 被显式调用、或者出现“promotion failure”（Survivor 放不下，直接进老年代撑爆）。
- 选收集器不是越新越好：小应用用 Serial 或 Parallel 就够；低延迟场景（如交易系统）优先 G1 或 ZGC；大堆（>64G）且要求极低停顿，ZGC 更稳。关键是结合业务吞吐/延迟目标+实际压测结果来定。
类加载与双亲委派：不只是机制，更是隔离和热更的基础
类加载过程（加载→验证→准备→解析→初始化）中，双亲委派模型决定了“谁来加载哪个类”，直接影响 SPI、自定义类加载器、模块冲突等现实问题。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
- 启动类加载器（Bootstrap）加载
rt.jar等核心类；扩展类加载器（Extension）加载java.ext.dirs下的 jar；应用类加载器（AppClassLoader）加载 classpath 的类。 - 打破双亲委派的典型场景：JDBC 的
DriverManager需要加载用户 jar 中的驱动类，靠Thread.currentThread().getContextClassLoader()实现；Tomcat 为隔离 Web 应用，每个 app 用独立的WebAppClassLoader，并先尝试自己加载（违反委派）。 - 类卸载只有在满足“该类所有实例被回收 + 类加载器被回收 + 类的 Class 对象没被引用”时才可能发生——所以动态加载大量类后不释放类加载器，就会 Metaspace OOM。
JVM 启动参数：精简常用项，拒绝无效配置
生产环境不需要记住全部参数，但以下几组必须熟练：
- 内存相关：-Xms 和 -Xmx 设成相等（防扩容抖动）；-XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 显式设置（避免频繁扩容）；-Xss 控制单线程栈大小（高并发服务适当调小，如 256k）。
- GC 日志：-Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps（JDK 8）；JDK 9+ 用 -Xlog:gc*:gc.log:time,tags。日志是调优唯一依据，不打开等于闭眼开车。
- 诊断支持：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dump/ 自动导出堆快照；-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly（配合 hsdis）看 JIT 编译结果（高级调试用）。
不复杂但容易忽略：JVM 的本质是运行时契约，它让 Java “一次编写，到处运行”，也带来抽象成本。真正掌握，靠的是在真实 OOM、GC 飙高、CPU 持续 100% 的现场反复验证和推演，而不是背熟一张图。
