冠军资讯
代码一只喵在构建高并发、高可用的Java应用时， JVM中的垃圾回收机制往往是影响系统稳定性和性能的关键因素之一。线上系统频繁出现 Full GC 导致服务卡顿，CPU 飙升，甚至 OOM，这些问题往往与垃圾回收配置不当，或者代码中存在内存泄漏有关。 就像 Nginx 配置不合理，导致并发连接数上不去，反向代理和负载均衡策略失效一样，JVM 垃圾回收也需要精细的配置和监控。本文将从底层原理、实战配置、监控调优等多方面深入剖析 JVM 垃圾回收机制，助你打造稳定高效的 Java 应用。
JVM 内存区域与垃圾回收
JVM 内存区域划分
JVM 内存区域主要分为以下几个部分：
- 堆（Heap）： 所有线程共享的区域，用于存储对象实例。JVM 垃圾回收的主要战场。
- 方法区（Method Area）： 所有线程共享的区域，用于存储类信息、常量、静态变量等。也称为“永久代”（PermGen space）或者“元空间”（Metaspace）。
- 虚拟机栈（VM Stack）： 每个线程私有的区域，用于存储局部变量、操作数栈、动态链接等。
- 本地方法栈（Native Method Stack）： 每个线程私有的区域，类似于虚拟机栈，但是用于执行 Native 方法。
- 程序计数器（Program Counter Register）： 每个线程私有的区域，用于记录当前线程执行的字节码指令地址。
垃圾回收区域
通常，我们所说的垃圾回收，主要针对的是堆和方法区这两个区域。尤其是堆，几乎所有对象实例都在这里分配内存，也是垃圾回收的重点关注对象。
垃圾回收算法
标记阶段
- 引用计数法： 给对象添加一个计数器，有引用时加 1，引用失效时减 1。缺点是无法解决循环引用问题。
- 可达性分析算法： 从 GC Roots 开始向下搜索，能够到达的对象就标记为“存活”，否则就标记为“垃圾”。GC Roots 包括虚拟机栈中引用的对象、方法区中类静态属性引用的对象、常量引用的对象、本地方法栈中 JNI 引用的对象。
清理阶段
- 标记-清除算法： 标记出所有需要回收的对象，然后统一回收。缺点是会产生大量不连续的内存碎片，导致后续分配大对象时无法找到足够的连续内存。
- 复制算法： 将内存分为两块区域，每次只使用其中一块。垃圾回收时，将存活的对象复制到另一块区域，然后清理整个区域。缺点是浪费一半的内存空间。
- 标记-整理算法： 标记出所有需要回收的对象，然后将存活的对象向一端移动，最后清理掉边界以外的内存。解决了内存碎片问题，但是整理过程效率较低。
- 分代收集算法： 根据对象存活周期的不同，将堆内存划分为新生代和老年代。新生代采用复制算法，老年代采用标记-清除或者标记-整理算法。
常见的垃圾回收器
Serial 收集器
单线程收集器，Stop-The-World（STW）。简单高效，适用于单核 CPU 环境。
ParNew 收集器
Serial 收集器的多线程版本，也 Stop-The-World。适用于多核 CPU 环境。
Parallel Scavenge 收集器
关注吞吐量（Throughput），即 CPU 用于运行用户代码的时间与 CPU 总消耗时间的比值。适合后台计算等不需要太多交互的任务。
CMS 收集器
Concurrent Mark Sweep，关注响应时间，尽量缩短 Stop-The-World 时间。分为初始标记、并发标记、重新标记、并发清除四个阶段。 缺点是会产生内存碎片，并且对 CPU 资源比较敏感。
G1 收集器
Garbage First，将堆内存划分为多个大小相等的 Region，每个 Region 都可以是 Eden、Survivor 或者 Old Generation。G1 能够精准地控制 Stop-The-World 时间，并且避免产生过多的内存碎片。是 JDK 9 默认的垃圾回收器。
JVM 垃圾回收调优实战
监控 GC 日志
通过 GC 日志可以了解垃圾回收的运行情况，例如：
-verbose:gc
-Xloggc:/path/to/gc.log
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
可以使用 GCeasy 等工具分析 GC 日志，找到性能瓶颈。
合理设置堆大小
堆大小的设置需要根据应用的实际情况进行调整。过小的堆容易导致频繁的 GC，过大的堆会增加 GC 的时间。一般建议将堆的初始大小和最大大小设置为相同的值，避免堆的动态扩展。
-Xms4g
-Xmx4g
选择合适的垃圾回收器
根据应用的特点选择合适的垃圾回收器。例如，对响应时间要求高的应用可以选择 CMS 或者 G1，对吞吐量要求高的应用可以选择 Parallel Scavenge。
代码层面的优化
- 避免创建不必要的对象。
- 及时释放不再使用的对象引用，避免内存泄漏。
- 使用对象池技术，重用对象。
- 避免在循环中创建大量临时对象。
实战避坑经验总结
- 慎用
System.gc()：显式调用System.gc()会触发 Full GC，可能会导致应用卡顿。应该尽量避免使用。 - 注意 Direct Memory 的使用： Direct Memory 不受 JVM 管理，如果使用不当容易导致 OOM。需要监控 Direct Memory 的使用情况，及时释放。
- 字符串常量池陷阱：过度使用
String.intern()可能导致永久代/元空间 OOM。 - 排查内存泄漏： 使用 MAT (Memory Analyzer Tool) 等工具分析 dump 文件，找到内存泄漏的原因。 定位到内存泄漏的代码，可以有效地避免 Full GC 的频繁发生。
总结
JVM 垃圾回收机制是 Java 应用性能优化的重要一环。理解其底层原理，掌握调优技巧，可以有效地提高应用的稳定性和性能。 通过监控 GC 日志、合理设置堆大小、选择合适的垃圾回收器、优化代码等手段，可以最大限度地减少 GC 对应用的影响。 结合 Nginx 等反向代理服务器的优化，例如调整 worker_connections 参数，可以进一步提升系统的整体性能。
