GC Root是JVM认定的“不可回收的引用起点”，包括虚拟机栈局部变量、方法区静态变量、常量池引用、JNI引用等；从这些起点出发可达的对象被视为存活，不可达者才可回收。
Java内存泄漏的本质，是对象本该被回收却因被GC Root间接持有而持续驻留堆中。理解GC Root，就是抓住内存泄漏诊断和预防的命门。
GC Root是什么：不是对象，而是“不可回收的引用起点”
GC Root不是某类特定对象，而是JVM明确认定“绝不能被回收”的引用位置集合。垃圾回收器从这些点出发，沿着引用链向下扫描——所有能到达的对象都被标记为存活；无法到达的，才进入回收队列。
关键在于：一个对象是否成为GC Root，不取决于它自身类型，而取决于它所处的**内存位置和生命周期保障机制**。例如：
- 方法执行时栈帧里的局部变量（如
User u = new User()中的u），只要方法没返回，它就是GC Root - 类加载后长期驻留的方法区中的静态变量（
public static User cache），整个应用运行期间默认都是GC Root - 字符串常量池里的字面量（
"SUCCESS"）或显式调用intern()的字符串，也属于GC Root - 正在被线程以
synchronized锁定的对象，在锁释放前会被视为GC Root
为什么GC Root直接决定内存泄漏是否发生
内存泄漏不是“对象没被删”，而是“不该活的对象还连在GC Root树上”。只要存在一条从GC Root出发、经由强引用构成的路径，哪怕业务逻辑早已弃用该对象，JVM也必须保留它。
立即学习“Java免费学习笔记（深入）”；
典型泄漏场景举例：
- 静态集合类（如
static List<User> allUsers = new ArrayList<>()）不断添加对象，却从不清理——这些对象始终通过静态变量这条GC Root链存活 - 监听器注册后未反注册，而监听器又持有所在Activity或Service的强引用——Activity销毁后仍被GC Root（如系统广播管理器）间接持有
- ThreadLocal变量未手动
remove()，且线程长期复用（如线程池），导致其持有的大对象无法脱离GC Root链
哪些常见情况会让对象“意外”成为GC Root链一环
开发者容易忽略的是：GC Root本身不会泄漏，但它的引用可能被不当延长。以下操作会隐式强化GC Root效力：
- 将对象赋值给
public static final字段——该对象及其整个引用图都变成“永久存活” - 在JNI层长期持有Java对象引用（
NewGlobalRef），却未在适当时候调用DeleteGlobalRef - 使用未关闭的资源类（如
FileInputStream）触发了finalize机制，而finalize队列中的对象在执行前也被临时视为GC Root - 线程未终止，其栈帧中残留的局部变量持续作为GC Root，拖住大量中间对象
如何验证一个对象是否真因GC Root而泄漏
不能只看代码逻辑，要借助工具实证：
- 用
jmap -histo:live <pid>观察对象数量是否随时间增长 - 用
jstack <pid>检查是否有异常长生命周期的线程在运行 - 用VisualVM、JProfiler或MAT打开堆转储（heap dump），筛选出“Path to GC Roots”——真正泄漏点往往藏在第3~5层引用之后
- 重点关注“excludes weak/soft/phantom references”选项，确保看到的是强引用链
识别出GC Root路径后，再回代码里切断非必要引用，比如把静态缓存换成WeakHashMap，或在合适时机调用remove()/unregister()。
