Java内存回收机制概述
Java内存回收是Java虚拟机（JVM）自动管理内存的核心功能，旨在通过垃圾回收（Garbage Collection, GC）机制自动回收不再使用的对象内存，避免手动内存管理带来的内存泄漏和悬垂指针问题，与C/C++等需要手动释放内存的语言不同，Java通过GC实现了“自动内存管理”，让开发者更专注于业务逻辑，本文将深入探讨Java内存回收的原理、实现方式及优化策略。
内存回收的对象：如何判定“垃圾”？
垃圾回收的第一步是确定哪些对象是“不再使用的垃圾”，JVM主要通过两种算法判定对象是否可回收：
引用计数法
为每个对象维护一个引用计数器,每当有一个地方引用该对象时，计数器加1；引用失效时减1，当计数器为0时，对象即可被回收，但该方法无法解决循环引用问题（如两个对象相互引用，即使无外部引用，计数器也无法归零），因此Java未采用此方法。
可达性分析算法
这是Java主流的垃圾判定算法,通过一系列称为“GC Roots”的对象作为起点，从这些节点开始向下搜索，走过的路径称为“引用链”，若一个对象到GC Roots没有任何引用链相连，则该对象不可达，判定为垃圾，GC Roots包括：虚拟机栈中引用的对象、方法区中类静态属性引用的对象、本地方法栈中JNI（即Native方法）引用的对象等。
垃圾回收算法与实现
确定了垃圾对象后,JVM需要通过具体的回收算法清理内存，常见的垃圾回收算法包括：
标记-清除（Mark-Sweep）
算法分为两个阶段：
- 标记：遍历所有对象，标记出所有可回收的垃圾对象。
- 清除：直接回收标记对象的内存，使内存变为空闲。
缺点：会产生内存碎片，可能导致后续分配大对象时无法找到连续内存空间。
标记-复制（Mark-Copy）
将内存分为大小相等的两块,每次只使用其中一块，当一块内存用尽时，将存活对象复制到另一块，然后清空原内存块。
优点：实现简单，内存无碎片；缺点：内存利用率仅50（半区复制），不适合老年代对象存活率高的场景。
标记-整理（Mark-Compact）
结合标记-清除和标记-复制的优点：先标记可回收对象，然后将所有存活对象向内存一端移动，最后直接清理端边界以外的内存。
优点：内存无碎片，利用率高；缺点：移动对象并更新引用指针的操作效率较低。
JVM中的垃圾回收器
JVM通过不同的垃圾回收器实现上述算法,以适应不同场景的需求：
Serial GC（串行回收器）
单线程回收,进行垃圾回收时需暂停所有用户线程（Stop-The-World），适用于客户端模式或内存较小的环境，简单高效。
Parallel GC（并行回收器）
Serial GC的多线程版本，在垃圾回收时启动多条线程并行工作，缩短停顿时间，是JDK 8及之前服务端模式的默认回收器，注重吞吐量（单位时间内完成的总任务量）。
CMS（Concurrent Mark Sweep）并发标记清除回收器
以获取最短回收停顿时间为目标,采用“标记-清除”算法，并在标记阶段与用户线程并发执行（除初始标记和重新标记外），但存在内存碎片和并发失败风险，JDK 14中被移除。
G1（Garbage-First）垃圾优先回收器
面向服务端,将堆划分为多个大小相等的Region，跟踪每个Region的回收价值，优先回收价值高的Region（垃圾最多），兼顾吞吐量和停顿时间，是JDK 9后的默认回收器。
ZGC与Shenandoah
低延迟回收器,目标是将停顿时间控制在毫秒级甚至亚毫秒级，通过并发标记、并发转移等技术实现，适用于超大内存（TB级）场景。
内存回收的优化策略
尽管Java内存回收是自动的,但不当的程序设计仍可能导致内存问题，优化策略包括：
避免内存泄漏
内存泄漏指对象不再使用,但因引用未被释放而无法被GC回收，常见原因包括：静态集合类引用对象、未关闭的资源（如数据库连接、IO流）、监听器未注销等，通过代码审查和工具（如VisualVM、MAT）定位泄漏点。
合理设置JVM参数
根据应用场景调整堆大小（-Xms、-Xmx）、新生代与老年代比例（-XX:NewRatio）、GC日志（-Xlog:gc*）等参数，避免频繁GC或内存溢出（OOM）。
使用弱引用与软引用
对于缓存等场景,可通过WeakReference（弱引用，GC时直接回收）或SoftReference（软引用，内存不足时回收）避免强引用导致的内存问题。
减少大对象分配
大对象（如长数组、大字符串）直接进入老年代，触发Major GC，增加停顿时间，可通过对象池或拆分大对象优化。
Java内存回收通过可达性分析判定垃圾对象,结合标记-清除、复制、整理等算法，由不同的垃圾回收器实现自动管理，开发者需理解其原理，通过优化代码和JVM参数，避免内存泄漏和性能问题，充分发挥Java自动内存管理的优势。
