java gc面试常见误区包括：①置null不触发回收，仅影响可达性；②finalize()已废弃，禁用且不可靠；③分代是内存组织策略，非独立算法；④跨代引用通过卡表优化扫描效率。
Java面试中，垃圾回收（GC）算法是高频考点，但很多候选人容易掉进几个典型误区——不是记不住知识点，而是理解偏差或混淆了机制与实现细节。
误以为“引用置为null就立刻回收”
这是最常被答错的一点。把对象引用设为null，只是断开了强引用链，它**不触发任何GC动作**，也不保证对象马上被回收。JVM只会在下一次合适的GC周期中，通过可达性分析判定该对象不可达后，才考虑回收。实际回收时机取决于堆内存压力、GC策略（如是否触发Minor GC）、以及当前使用的收集器（如G1的并发标记阶段可能延迟处理）。
建议回答时强调：
• null操作仅影响引用可达性，不是GC指令
• 真正回收由JVM根据内存使用情况自主决定
• 频繁手动置null在现代JVM中收益极低，反而可能干扰JIT优化
混淆“finalize()能救命”和“可替代资源清理”
不少候选人会说：“只要在finalize()里把自己this再赋给静态变量，对象就能活下来”。这虽然技术上可行（属于第二次标记逃生机制），但finalize()已被标记为deprecated（自Java 9起），且在Java 14中彻底移除。它执行不可靠、开销大、顺序不确定，完全不能用于释放文件句柄、数据库连接等关键资源。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
正确做法是：
• 用try-with-resources管理可关闭资源
• 实现Cleaner（Java 9+）或PhantomReference做异步清理
• 明确告知面试官：finalize()是历史遗留，生产环境禁用
把“分代回收”当成独立算法，忽略其组合本质
有人把“分代回收”和“标记-复制”“标记-整理”并列当作第四种算法，这是概念错位。分代回收（Generational GC）是一种内存管理策略，不是具体算法；它基于“弱分代假说”（绝大多数对象朝生夕死），将堆划分为新生代、老年代，并分别选用最适合的算法：新生代用复制算法（高效处理短命对象），老年代用标记-清除或标记-整理（兼顾空间利用率与碎片控制）。
面试中应厘清逻辑：
• 分代是“怎么组织内存”，算法是“怎么清理内存”
• 同一个收集器（如Parallel GC）内部就同时用复制（新生代）+标记-整理（老年代）
• G1则打破分代物理界限，用分区（Region）+增量标记，但仍保留逻辑分代行为
忽视跨代引用对GC效率的真实影响
当老年代对象引用新生代对象时（如缓存Map里存了刚创建的DTO），若每次Minor GC都扫描整个老年代找引用，开销巨大。JVM用记忆集（Remembered Set）和卡表（Card Table）解决这个问题：把老年代按固定大小（如512B）划分成“卡”，一旦有跨代引用写入，对应卡被标记为dirty，Minor GC只需扫描这些dirty卡，大幅减少扫描范围。
这个机制说明：
• GC优化不是纯理论，而是大量工程权衡的结果
• 回答时提到“卡表”比只说“记忆集”更显深度
• 可补充：CMS和G1都依赖此机制，但G1的RSet实现更精细（每个Region维护自己的RSet）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
