垃圾回收仅保障内存逻辑安全而非业务一致性；GC Roots精确枚举于栈帧局部变量、静态字段等固定区域；STW确保标记阶段一致性快照；并发收集器依赖写屏障、增量更新或SATB维持三色标记安全；移动式回收通过OopMap与安全点原子更新引用。
垃圾回收过程本身不负责业务数据一致性，它只保障内存状态的逻辑安全——即不误删仍被引用的对象，也不访问已释放的内存地址。这种“安全性”本质是内存管理层面的正确性，而非数据库或分布式系统中的ACID一致性。
GC Roots的精确枚举是起点
所有主流JVM（如HotSpot）将GC Roots严格限定在几个明确区域：栈帧中的局部变量、静态字段、常量池项、JNI全局引用、被同步锁持有的对象等。这些位置可被精确快照，不会因线程执行而动态增删引用源。若Roots枚举遗漏（如漏掉某个本地方法引用），就可能把存活对象误判为垃圾，造成悬垂指针和崩溃——这属于GC实现缺陷，不是算法原理问题。
Stop-the-World与一致性快照
标记阶段必须在“一致性快照”下进行：所有Java线程暂停（STW），确保从GC Roots出发的引用链在分析过程中不发生变化。例如，线程A正在执行obj.field = null，若标记在赋值前开始，obj仍被引用；若在赋值后开始，obj可能被回收。STW消除了这种竞态，使可达性分析结果可预测、可验证。
并发算法中的三色标记与增量更新
CMS和G1等低延迟收集器允许用户线程与标记线程并发运行，但需额外机制维持安全性：
- 写屏障（Write Barrier）：每次对象引用字段被修改时触发，检查是否破坏了“黑色对象→白色对象”的引用关系。若破坏（如黑对象新增指向白对象的引用），则将该白对象重新标记为灰色，加入待扫描队列。
- 增量更新（Incremental Update）：记录并发期间新建立的跨代/跨区域引用，避免漏标。
- 原始快照（SATB）：G1采用的方式，在标记开始前先“快照”所有引用，之后只处理被修改的引用，保证不漏标已存在但尚未扫描到的路径。
移动式回收的指针更新保障
复制算法和标记-整理算法会移动对象。此时必须原子更新所有指向该对象的引用，否则会出现“野指针”。HotSpot通过以下方式确保：
- 移动前，用OopMap快速定位所有可能存有该对象引用的位置（如栈、寄存器、其他对象字段）；
- 在安全点（Safepoint）统一暂停线程，批量修正引用；
- 对Java堆外引用（如DirectByteBuffer的address字段），由写屏障配合元数据跟踪，防止遗漏。
