1. JVM内存区域与模型：从“堆栈”到“元空间”的演进
很多朋友一提到JVM，第一反应就是“堆”和“栈”。这没错，但JVM的内存世界远比这复杂。我刚开始学Java那会儿，也以为内存就这两块，后来在线上排查一个内存溢出问题时，才发现自己太天真了。当时应用频繁Full GC，我盯着堆内存监控图看了半天，死活找不到问题，最后才发现是元空间（Metaspace）爆了。所以，理解JVM内存的完整布局，是解决一切性能问题的起点。
JVM运行时数据区主要分为线程私有和线程共享两大类。线程私有的包括程序计数器（PC Register）、Java虚拟机栈（Java Stack）和本地方法栈（Native Method Stack）。程序计数器是当前线程所执行的字节码的行号指示器，它是唯一一个在JVM规范中没有规定任何OutOfMemoryError情况的区域。每个线程都有自己的虚拟机栈，用于存储栈帧（Stack Frame）。每次方法调用都会创建一个栈帧，用于存储局部变量表、操作数栈、动态链接和方法出口等信息。本地方法栈则为JVM使用到的Native方法服务。
线程共享的区域才是我们通常关注的重点，包括堆（Heap）和方法区（Method Area）。堆是JVM管理的最大一块内存，几乎所有对象实例和数组都在这里分配内存。方法区则用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
这里有个关键变化点：在JDK 8之前，方法区有一个叫“永久代（PermGen）”的实现。很多朋友应该都见过java.lang.OutOfMemoryError: PermGen space这个错误。永久代的大小是固定的，通过-XX:MaxPermSize设置，一旦加载的类太多或者常量池过大，就容易溢出。而且，永久代的垃圾回收效率很低，Full GC时才会触发，经常成为性能瓶颈。
所以，从JDK 8开始，HotSpot JVM彻底移除了永久代，引入了元空间（Metaspace）。元空间不再使用JVM的堆内存，而是使用本地内存（Native Memory）。这意味着，只要你的操作系统内存足够大，理论上元空间可以无限扩展（当然，你可以用-XX:MaxMetaspaceSize来限制它）。这个改动解决了永久代容易溢出的问题，也使得类的元数据管理更加灵活。但这也带来了新的问题：如果元空间无限增长，可能会吃光你的系统内存。我就遇到过因为反射、动态代理生成大量类，导致元空间暴涨，最终把服务器物理内存耗尽的案例。所以，监控Metaspace的使用情况，在JDK 8+的环境中变得同样重要。
2. 垃圾回收核心算法：不只是“标记”与“清除”
说到垃圾回收（GC），很多人第一反应就是“标记-清除”。这确实是基础，但现代JVM的GC算法要精巧得多。理解这些算法，你才能明白为什么会有那么多不同的垃圾收集器，以及如何为你的应用选择合适的那个。
最基础的标记-清除（Mark-Sweep）算法分为两步：首先标记出所有需要回收的对象，然后统一回收。它的主要问题是会产生大量不连续的内存碎片。想象一下你的房间，东西扔得到处都是，虽然总空间够，但想放个大柜子却找不到一块完整的空地。这就是内存碎片化，会导致后续分配大对象时可能触发另一次不必要的GC。
为了解决碎片问题，复制（Copying）算法出现了。它把内存分成大小相等的两块，每次只用一块。当这一块用完了，就把还存活的对象复制到另一块上，然后把已使用的内存一次性清理掉。这个算法简单高效，没有碎片，但代价是可用内存缩小了一半。所以，它非常适合对象“朝生夕死”的新生代（Young Generation）。实际上，HotSpot虚拟机默认将新生代划分为一个较大的Eden空间和两个较小的Survivor空间（比例通常是8:1:1）。每次Minor GC时，将Eden和一个Survivor中存活的对象复制到另一个Survivor中，然后清空Eden和那个已用的Survivor。如果Survivor空间不够存放存活对象，这些对象会通过**分配担保（Handle Promotion）**机制直接进入老年代。
对于对象存活率高的老年代（Old Generation），复制算法就不划算了（复制大量存活对象成本高）。所以老年代一般使用标记-整理（Mark-Compact）算法。它在标记完成后，不是直接清理，而是让所有存活的对象都向内存一端移动，然后直接清理掉边界以外的内存。这样既避免了碎片，又不像复制算法那样浪费空间。但移动对象是个重操作，所以老年代的GC（Major GC/Full GC）通常比新生代的GC（Minor GC）要慢得多。
现代商用JVM的垃圾收集都采用分代收集（Generational Collection）算法。这基于一个经验法则：绝大多数对象都是朝生夕死的。所以，我们把堆分为新生代和老年代。新生代用复制算法，因为每次回收都有大量对象死去，复制少量存活对象的成本很低。老年代用标记-清除或标记-整理算法，因为那里对象存活率高，没有额外空间做分配担保。这种“分而治之”的策略大大提升了GC效率。
3. 七大垃圾收集器：从Serial到ZGC的抉择
知道了算法，我们来看看实现这些算法的“工人”——垃圾收集器。没有最好的收集器，只有最适合你场景的。选错了，性能可能天差地别。
Serial收集器是最古老、最基本的。它是一个单线程收集器，在进行垃圾回收时，必须暂停所有其他工作线程（Stop The World）。听起来很糟糕，对吧？但在客户端模式或单核CPU、内存很小的嵌入式设备上，它没有线程交互开销，简单而高效。对于很多小型应用，它反而是不错的选择。
ParNew收集器本质上是Serial收集器的多线程并行版本。除了使用多线程进行垃圾收集外，其他行为与Serial完全一样。它是许多运行在服务端模式下的JVM中新生代的默认收集器（在JDK 7及之前），一个重要原因是它能与CMS收集器配合工作。
Parallel Scavenge收集器也是一个用于新生代的多线程收集器，但它关注的目标不同。CMS等收集器的目标是尽可能缩短垃圾收集时用户线程的停顿时间（低延迟），而Parallel Scavenge的目标是达到一个可控制的吞吐量（Throughput）。吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)。高吞吐量可以最高效率地利用CPU时间，尽快完成程序的运算任务，适合后台运算、科学计算等不需要太多交互的场景。它提供了两个参数用于精确控制吞吐量：-XX:MaxGCPauseMillis（最大GC停顿时间）和-XX:GCTimeRatio（GC时间占总时间的比率）。
Serial Old和Parallel Old分别是Serial和Parallel Scavenge的老年代版本。Serial Old使用“标记-整理”算法，Parallel Old则使用多线程的“标记-整理”算法。
CMS（Concurrent Mark Sweep）收集器是一款以获取最短回收停顿时间为目标的收集器，非常适合互联网站或B/S系统的服务端，重视服务的响应速度。它的运作过程相对复杂，分为四个步骤：初始标记（STW）、并发标记、重新标记（STW）和并发清除。其中耗时最长的并发标记和并发清除阶段都可以与用户线程一起工作，所以总体上停顿时间较短。但CMS有三个明显的缺点：1）对CPU资源非常敏感，因为并发阶段会占用一部分线程导致应用变慢；2）无法处理“浮动垃圾”，可能在并发清理阶段产生新的垃圾，只能留到下次GC；3）因为是“标记-清除”算法，会产生大量空间碎片，可能导致Full GC提前触发。
G1（Garbage-First）收集器是JDK 7 Update 4之后引入的服务端收集器，目标是替代CMS。它不再坚持固定大小和固定数量的分代区域划分，而是将整个Java堆划分为多个大小相等的独立区域（Region）。G1跟踪各个Region里面的垃圾堆积“价值”大小，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region（名称由来）。它兼具并行与并发、分代收集、空间整合（整体看是标记-整理，局部是复制算法）、可预测停顿等优点。从JDK 9开始，G1成为了服务端模式的默认垃圾收集器。
ZGC（Z Garbage Collector）是JDK 11中引入的一款新的低延迟垃圾收集器（实验性），在JDK 15中转为正式特性。它的目标是在任意堆内存大小下，将停顿时间控制在10毫秒以内。ZGC通过染色指针（Colored Pointers）和读屏障（Load Barriers）等技术，实现了几乎所有垃圾收集阶段都与应用线程并发执行，停顿时间几乎与堆大小无关。对于需要极低延迟（如金融交易、实时游戏）的应用，ZGC是值得深入研究的选项。
4. 类加载机制与双亲委派：Java安全的基石
我们写的.java文件编译成.class字节码后，是如何变成JVM中一个可用的类的？这就涉及到类加载（Class Loading）。这个过程分为加载（Loading）、链接（Linking）、初始化（Initialization）三个阶段。
加载阶段，JVM需要完成三件事：1）通过一个类的全限定名来获取定义此类的二进制字节流；2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构；3）在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。这个阶段我们可以通过自定义类加载器（如从网络、数据库加载字节码）来干预。
链接又分为验证（Verification）、准备（Preparation）、解析（Resolution）。验证确保Class文件的字节流符合JVM规范，不会危害虚拟机安全。准备阶段为**类变量（static变量）**分配内存并设置初始零值（如0、false、null）。解析是将常量池内的符号引用替换为直接引用的过程。
初始化是执行类构造器<clinit>()方法的过程。这个方法是由编译器自动收集类中所有类变量的赋值动作和**静态语句块（static{}块）**中的语句合并产生的。虚拟机会保证在子类的<clinit>()方法执行前，父类的<clinit>()方法已经执行完毕。
这里最核心的机制是双亲委派模型（Parent Delegation Model）。这不是继承关系，而是一种组合关系。JVM内置了三个类加载器：启动类加载器（Bootstrap ClassLoader），用C++实现，负责加载<JAVA_HOME>/lib下的核心类库；扩展类加载器（Extension ClassLoader），负责加载<JAVA_HOME>/lib/ext目录下的类；应用程序类加载器（Application ClassLoader），也叫系统类加载器，负责加载用户类路径（ClassPath）上的类库。我们还可以自定义类加载器。
双亲委派的工作流程是：当一个类加载器收到加载请求时，它首先不会自己去加载，而是把这个请求委派给父类加载器去完成。每一层都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器。只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。
这样做的好处有两个：一是确保类的全局唯一性。比如java.lang.Object，无论哪个加载器要加载这个类，最终都会委派给启动类加载器去加载，这样就保证了在程序中，这个核心类只有一份。二是安全。防止用户自定义一个恶意的java.lang.String类来替换核心API。因为根据委派机制，会优先由启动类加载器加载核心的String类，自定义的类不会被加载。我见过有团队为了热部署，破坏了双亲委派，结果导致了诡异的类冲突问题，排查了整整两天。所以，除非你非常清楚自己在做什么，否则不要轻易破坏这个机制。
5. 内存分配与回收策略：对象的一生
一个对象在JVM中是如何“诞生”、如何“成长”、最终又如何“消亡”的？理解这个过程，对写出内存友好的代码至关重要。
对象的创建通常从一条new指令开始。JVM首先检查这个指令的参数能否在常量池中定位到一个类的符号引用，并检查这个类是否已被加载、解析和初始化过。如果没有，先执行类加载过程。
类加载检查通过后，JVM将为新生对象分配内存。对象所需内存大小在类加载完成后便可完全确定。分配方式有两种：如果Java堆内存是规整的（用过的内存在一边，空闲的在另一边），采用指针碰撞（Bump the Pointer），就是把分界点的指针向空闲空间那边挪动一段与对象大小相等的距离。如果内存不规整，已使用和空闲内存相互交错，JVM就必须维护一个空闲列表（Free List），记录哪些内存块是可用的，分配时从列表中找到一块足够大的空间划分给对象。
在并发环境下，分配内存不是线程安全的。解决这个问题有两种方案：一是采用CAS（Compare And Swap）配上失败重试的方式保证更新操作的原子性；二是TLAB（Thread Local Allocation Buffer），即每个线程在堆中预先分配一小块私有内存，对象优先在TLAB中分配，避免了同步开销。可以通过-XX:+/-UseTLAB参数来设定。
内存分配完成后，JVM需要将分配到的内存空间（不包括对象头）都初始化为零值。这保证了对象的实例字段在Java代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值。
接下来是设置对象头（Object Header）。对象头包含两部分信息：第一部分是Mark Word，用于存储对象自身的运行时数据，如哈希码、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID等。第二部分是类型指针，即对象指向它的类元数据的指针，JVM通过这个指针来确定这个对象是哪个类的实例。如果是数组，对象头还会有一块用于记录数组长度的数据。
从JVM视角看，一个新对象已经产生了。但从程序视角看，对象创建才刚刚开始——执行<init>方法（即构造器），按照程序员的意愿初始化对象，为属性赋真正的值。
对象的内存分配，首先会尝试在栈上分配（Stack Allocation）。如果通过逃逸分析（Escape Analysis）发现一个对象的作用域没有逃逸出方法外（即不会被外部方法引用），那么这个对象就可能被优化为栈上分配。栈上分配的对象随栈帧出栈而销毁，无需GC介入，效率极高。对于逃逸出方法但仅限于线程内的对象，JIT编译器还可能进行标量替换（Scalar Replacement），将这个对象拆散，将其成员变量分解为若干个独立的局部变量。
如果无法在栈上分配，对象会在Eden区分配。当Eden区没有足够空间时，会触发一次Minor GC。在Minor GC中，Eden区存活的对象会被复制到Survivor区（通常是To Survivor），并且年龄加1。以后每次Minor GC，存活的对象会在两个Survivor区之间来回拷贝，每拷贝一次年龄加1。当对象的年龄达到一定阈值（默认15，可通过-XX:MaxTenuringThreshold设置），就会被晋升到老年代。
也有一些特殊情况会直接进入老年代：1）大对象，比如很长的字符串或数组，可以通过-XX:PretenureSizeThreshold参数设置直接进入老年代的阈值，避免在Eden和Survivor区之间来回复制。2）动态对象年龄判定：如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代。
当老年代空间不足时，会触发Major GC（通常伴随至少一次Minor GC，也常被称为Full GC）。Full GC会对整个堆（包括新生代、老年代）以及方法区（元空间）进行回收，停顿时间最长，应尽量避免其频繁发生。
6. 实战调优与故障排查：从参数到工具
理论懂了，最终还是要落地。JVM调优没有银弹，核心是监控、分析、假设、验证的循环。我分享几个实战中踩过的坑和总结的经验。
首先，你得知道看什么。JVM监控工具是我们的眼睛。命令行工具如jps（查看JVM进程）、jstat（查看类加载、GC、JIT编译等统计信息）、jmap（生成堆转储快照）、jstack（生成线程快照）是基本功。可视化工具我推荐JVisualVM（JDK自带）和MAT（Memory Analyzer Tool）。JVisualVM可以实时监控CPU、内存、类、线程，还能做抽样和快照对比。MAT则是分析堆转储文件、定位内存泄漏的神器。
其次，关键的JVM启动参数必须心中有数。堆内存相关：-Xms（初始堆大小）、-Xmx（最大堆大小）。我一般设置成一样，避免堆动态调整带来的性能波动。-Xmn（新生代大小），这个值需要权衡，太大会导致老年代变小，容易触发Full GC；太小则导致Minor GC频繁。老年代大小就是-Xmx减去-Xmn。
新生代内部比例：-XX:SurvivorRatio=8表示Eden和Survivor的比例是8:1:1。-XX:MaxTenuringThreshold=15设置晋升老年代的年龄阈值。
元空间：-XX:MetaspaceSize和-XX:MaxMetaspaceSize。我建议把初始值设得比默认值（约20M）大一些，比如256M，避免运行时频繁扩容。
GC日志是排查问题的金矿。务必加上-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:<path>。分析GC日志，你要关注：GC频率（Minor GC和Full GC多久发生一次）、GC耗时（每次暂停多长时间）、吞吐量（GC时间占应用运行时间的比例）、晋升速率（对象从新生代进入老年代的速度）。如果发现Full GC频繁，通常意味着内存泄漏或老年代空间设置过小。
一个常见的内存泄漏场景是静态集合类持有对象引用。比如用一个static Map做缓存，却忘了设置过期或清理策略，对象只进不出，最终撑爆老年代。排查这类问题，可以用jmap -dump:live,format=b,file=heap.hprof <pid>导出堆转储文件，然后用MAT打开，查看Dominator Tree和Histogram，找到那些占用内存最大的对象和类，顺着引用链（Path to GC Roots）就能找到“罪魁祸首”。
另一个坑是线程局部变量（ThreadLocal）使用不当。ThreadLocal的key是弱引用，但value是强引用。如果线程池中的线程一直存活（比如Tomcat的工作线程），而ThreadLocal使用后没有调用remove()方法，那么value会一直存在一条强引用链：Thread -> ThreadLocalMap -> Entry -> Value，导致无法回收，造成内存泄漏。所以，使用ThreadLocal时，一定要在finally块中调用remove()。
对于栈溢出（StackOverflowError），通常是方法递归调用层次太深，或者线程栈空间太小（通过-Xss设置）。而堆溢出（OutOfMemoryError: Java heap space），除了内存泄漏，也可能是内存设置过小，或者存在一次性加载大量数据（比如从数据库一次查询几十万条记录）的情况。这时候需要结合业务代码和内存分析工具来定位。
最后，调优是一个平衡的艺术。追求低延迟（用CMS或G1），就可能牺牲一些吞吐量；追求高吞吐量（用Parallel Scavenge），停顿时间就可能变长。你需要根据你的应用类型（Web服务、批处理、实时计算）和SLA（服务等级协议）来制定调优目标。没有监控的调优就是盲人摸象，所以，先把监控体系建起来，让数据告诉你问题在哪里。
