匿名对象的回收时机取决于强引用可达性而非是否匿名：若无任何变量、静态字段、集合或线程栈持有它，则作用域结束即成gc候选；若被监听器、缓存或线程等长期持有，则生命周期由持有者决定。
匿名对象本身不决定回收时机，真正起作用的是它是否还被任何强引用可达。只要创建后没被变量、静态字段、集合容器或线程栈等持有，它就和普通局部对象一样，在作用域结束且无其他引用时，成为GC可回收对象。
看它有没有被“谁”拿着
匿名对象能否被回收，关键不在“匿名”，而在是否有强引用链指向它：
- 如果只是 new Person().getName() 这样调用完就丢，没有赋值、没传给任何长期存活对象，那它几乎立刻变成不可达对象；
- 但如果写成 button.addActionListener(new ActionListener(){...})，监听器会被 button 内部的 listener 列表强引用着，实际生命周期由 button 决定，哪怕匿名，也得等 button 被回收或手动移除监听器；
- 再比如 static List ——这个匿名 Config 就被 static 集合牢牢持有着，不会被回收。
结合 GC Roots 看可达性路径
JVM 每次 GC 前都会从 GC Roots 出发做可达性分析。匿名对象只要满足以下任一条件，就会被判定为可回收：
- 没被任何局部变量（栈帧中）引用；
- 没被任何静态字段（方法区）间接引用；
- 没被任何活跃线程、JNI 引用或系统类持有着；
- 也没被软/弱/虚引用之外的其他方式间接连到 Roots 上。
注意那些容易误判的场景
开发者常以为“匿名 = 立刻回收”，但现实中有几个典型反例：
- 注册监听器未反注册：匿名监听器被 UI 组件长期持有，造成内存泄漏；
- 放进缓存或队列：如 queue.offer(new Task())，只要队列还活着，Task 就不会回收；
- 构造过程触发资源绑定：比如 new Thread(() -> {...}).start()，线程启动后，JVM 会通过线程栈和线程组维持对它的强引用，直到线程终止。
怎么验证它是不是真被回收了？
不能靠代码逻辑“感觉”，得靠工具观察：
- 加 -XX:+PrintGCDetails 查看 GC 日志，关注新生代回收量是否随匿名对象使用频率明显上升；
- 用 VisualVM 或 JConsole 抓堆快照，筛选对应类实例数，对比前后差异；
- 配合 WeakReference 测试：把匿名对象包进 WeakReference，稍后调用 ref.get() == null 可间接判断它是否已被回收（注意：不保证立即响应，但比 System.gc() 更可靠）。
