垃圾收集器是jvm内存状态的响应机制，其行为由堆结构划分、对象分配策略、gc触发条件和回收算法共同决定。分代设计影响gc范围，参数调优需匹配应用特征，碎片管理依赖算法与布局协同。
垃圾收集器不是独立运行的黑盒，它和JVM内存管理的每个环节都紧密咬合——堆结构划分、对象分配策略、GC触发条件、回收算法选择，全都取决于当前内存布局与使用状态。
堆内存布局决定GC行为边界
JVM堆被划分为新生代（Eden + Survivor）和老年代，这种分代设计直接决定了不同GC算法的适用场景。比如Minor GC只清理新生代，而Full GC才触及整个堆。如果Survivor区过小，对象频繁“躲不过”一次复制就晋升老年代，会加速老年代碎片化；若老年代空间不足但尚未达到阈值，可能触发CMS并发模式失败，回退为Serial Old单线程STW回收。
- 通过-XX:NewRatio控制新老代比例，合理匹配应用对象生命周期特征
- 用-XX:SurvivorRatio调整Eden与Survivor大小，避免过早晋升或空间浪费
- 大对象（如长数组）可能直接进入老年代（-XX:PretenureSizeThreshold），绕过新生代，影响Minor GC频率
对象分配策略影响GC效率
对象优先在Eden区分配，这是最轻量的路径。但TLAB（Thread Local Allocation Buffer）的存在让多线程分配几乎无锁，一旦TLAB耗尽或对象过大，就会触发同步分配或直接进入老年代。频繁的TLAB重填或大量大对象分配，都会抬高GC压力。
- 开启-XX:+UseTLAB提升小对象分配吞吐，关闭则适用于极低延迟敏感场景（需权衡）
- 监控-XX:+PrintGCDetails中的“allocation failure”日志，定位频繁分配失败点
- 避免在循环中创建短命大对象，它们既不适宜TLAB也不利于复制算法
GC触发条件由内存水位动态驱动
GC不是定时执行，而是由内存使用率、分配速率、预测晋升量等实时指标共同触发。例如G1通过预测模型估算Mixed GC应处理哪些Region，ZGC则依赖着色指针标记进度决定是否启动并发标记周期。一次Young GC后若发现老年代剩余空间不足以容纳预期晋升对象，就可能立即触发并发周期或降级为Full GC。
- 用-XX:MaxGCPauseMillis设定目标停顿时间，G1/ZGC据此动态调整工作节奏
- 关注Metaspace扩容日志（如“Metaspace GC”），类加载过多也会间接引发Full GC
- 避免人为调高-XX:MaxHeapSize却不配比新生代，易造成老年代“假性紧张”
回收算法与内存碎片深度耦合
标记-清除（CMS）不整理内存，久而久之产生碎片，导致大对象无法分配而触发Full GC；标记-整理（Serial Old、Parallel Old）虽解决碎片，但移动成本高；G1和ZGC则通过Region化+并发整理，在可控停顿内兼顾空间利用率与吞吐。碎片问题本质是内存布局与回收动作不匹配的结果。
- CMS已废弃，生产环境应转向G1或ZGC，尤其对延迟敏感型服务
- G1的-XX:G1HeapRegionSize影响Region粒度，过大降低灵活性，过小增加管理开销
- ZGC要求堆大小为2^n MB（如4G、8G），否则自动向下取整，影响实际可用容量
理解JVM内存管理，关键在于把GC看作内存状态的响应机制——它不凭空发生，而是在堆结构、分配行为、使用趋势共同作用下的必然结果。
