java内存分配与垃圾回收由jvm自动协同完成，核心是基于对象生命周期的分代模型：新对象入eden，minor gc后存活对象移至survivor，多次存活或大对象直接进老年代；回收策略依业务目标选cms/g1（低延迟）、parallel（高吞吐）或zgc/shenandoah（大堆低停顿）；参数需整体调优，如-xms/-xmx相等、-xmn控年轻代大小、-xx:survivorratio调比例；对象回收依赖gc roots可达性分析，软/弱/虚引用提供差异化生命周期控制。
Java 内存分配与垃圾回收策略不是靠“手动设计”的，而是由 JVM 根据运行时数据特征、预设参数和所选垃圾收集器自动协同工作的结果。开发者要做的是理解分代模型、掌握关键参数、匹配业务场景选择合适策略，而不是从零构建一套机制。
基于对象生命周期的分代分配是核心逻辑
JVM 堆内存默认按对象存活时间划分为年轻代（Eden + Survivor）和老年代。这种划分不是硬编码规则，而是对“大部分对象朝生夕死”这一经验的工程实现：
- 新对象优先在 Eden 区分配；空间不足时触发 Minor GC，存活对象进入 Survivor 区
- 对象在 Survivor 区经历若干次 GC 后仍存活（默认 15 次，可通过 -XX:MaxTenuringThreshold 调整），晋升至老年代
- 大对象（如超大数组）可能直接分配到老年代，避免在年轻代反复复制，可通过 -XX:PretenureSizeThreshold 设置阈值
垃圾回收策略取决于目标而非固定公式
不同收集器适用于不同系统诉求，没有“最优”，只有“更合适”：
- 追求低延迟（如 Web API、实时交互）：选 CMS 或 G1，支持并发标记，减少 STW 时间
- 追求高吞吐量（如批处理、后台计算）：用 Parallel Scavenge + Parallel Old，以吞吐量为目标调优（-XX:GCTimeRatio）
- 兼顾响应与吞吐（现代主流选择）：ZGC 或 Shenandoah，支持亚毫秒级停顿，适合大堆（>4GB）场景
关键参数要结合堆结构一起看
单设一个参数往往无效，需配合整体堆布局理解其作用：
- -Xms 与 -Xmx 设为相等，避免堆动态扩容带来的额外开销和碎片
- -Xmn 控制年轻代大小，影响 Minor GC 频率；过小导致频繁 GC，过大则延长单次 GC 时间
- -XX:SurvivorRatio 决定 Eden 与一个 Survivor 的比例（如设为 8 表示 Eden:Survivor = 8:1），影响对象在年轻代的驻留能力
- 元空间不用设初始大小（-XX:MetaspaceSize 可设预警阈值），但需监控类加载行为，防止动态生成类过多引发 OOM
判断对象是否可回收依赖可达性分析
JVM 不用引用计数，而是从 GC Roots 出发做深度遍历：
- GC Roots 包括栈中局部变量、静态字段、常量池引用、JNI 引用等
- 不可达对象不会立即回收，若重写了 finalize()（已弃用），会进 F-Queue 队列等待二次标记，但不推荐依赖此机制
- 软/弱/虚引用提供不同强度的生命周期控制，例如缓存可用 SoftReference，监听回收可用 PhantomReference
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
