jvm内存结构直接决定gc行为——堆分代设计（新生代/老年代）匹配对象生命周期，采用不同回收算法；元空间扩容失败或类卸载条件不满足会触发full gc；线程栈大小影响gc停顿；gc日志是验证内存行为的关键证据。
JVM内存结构不是静态的容器，而是GC行为的直接依据——每块区域的用途、对象生命周期特征，决定了GC何时触发、回收哪些对象、采用何种算法。
堆内存划分直接影响GC策略选择
堆分为新生代（Eden + Survivor）和老年代，这种分代设计源于“绝大多数对象朝生暮死”的统计规律。新生代频繁分配和回收，所以用复制算法（如Minor GC），效率高、无碎片；老年代对象存活久、空间大，更适合标记-整理或标记-清除（如Major GC / Full GC）。如果对象直接在老年代分配（如大对象、长期缓存），就绕过了年轻代的快速淘汰机制，可能提前触发老年代GC。
- Eden区满时触发Minor GC，存活对象进入Survivor，年龄达阈值（默认15）则晋升老年代
- Survivor空间不足或老年代剩余空间小于历次晋升平均大小时，可能触发担保机制，直接Full GC
- 元空间（Metaspace）虽不在堆内，但其扩容失败也会间接引发Full GC（因类加载器无法卸载）
方法区（元空间）与GC的间接耦合
Java 8后方法区由元空间替代，使用本地内存，理论上不直接受GC控制。但它与GC强相关：类卸载必须在Full GC时进行，且仅当满足三个条件——该类所有实例已被回收、加载该类的ClassLoader已被回收、该类对应的java.lang.Class对象没有被引用。因此，频繁动态生成类（如某些RPC框架、Groovy脚本）若未合理管理ClassLoader，会导致元空间OOM，并反复触发Full GC。
- 可通过-XX:MaxMetaspaceSize限制上限，避免无节制增长
- 监控项重点关注LoadedClassCount、UnloadedClassCount差值，判断类是否有效卸载
- Spring Boot热部署、OSGi等场景需特别注意ClassLoader泄漏
线程栈与GC看似无关，实则影响停顿时间
虚拟机栈、本地方法栈属于线程私有，不参与GC，但它们的大小（-Xss）会影响GC停顿。每个线程栈需在GC根节点扫描阶段被遍历（如判断栈帧中是否有对象引用），线程数越多、栈越深，GC Roots枚举耗时越长。尤其在CMS或G1中，并发标记阶段仍需安全点暂停，此时大量线程会增加STW时间。
- 高并发服务应合理设置-Xss（如256k而非默认1M），减少单线程栈开销
- 避免在栈上构造深度递归或超长局部对象链，防止意外增大Roots规模
- JDK10+支持ZGC的“无停顿”特性，本质是把Roots扫描并行化并缩短暂停粒度，但仍依赖栈结构可控
GC日志是连接内存结构与实际行为的证据链
光看理论结构不够，GC日志才是验证内存分配与回收是否匹配的关键证据。比如一次Minor GC后Eden使用率仍很高，说明对象分配速率远超回收能力，可能需调大新生代；若老年代在多次Minor GC后缓慢增长，但某次突然激增，大概率是显式调用了System.gc()或存在内存泄漏。
- 开启-XX:+PrintGCDetails -Xloggc:gc.log -XX:+PrintGCTimeStamps获取完整日志
- 关注每次GC前后各区域容量变化（如[PSYoungGen: 1234K->567K(2048K)]），反推对象晋升节奏
- 结合jstat -gc pid实时观察S0C/S1C/EC/OC/MC等字段，比对理论结构与运行态是否一致
