Android应用内存泄漏：匿名类持有局部变量引用问题排查

你遇到的这个问题在Android开发里特别常见——匿名内部类会隐式持有外部作用域中被引用变量（这里是LeakingActivity实例）的强引用，而你的callbacks是静态列表，一旦Callback被加入这个列表，就会一直攥着Activity的强引用不放，哪怕Activity已经销毁，GC也没法回收它，最终导致内存泄漏。

下面是几个针对性的解决方案，按实用度排序：

方案1：静态内部类 + WeakReference（最稳妥的通用方案） #

把匿名Callback改成静态内部类，并用WeakReference包装Activity，既避免了匿名类的隐式强引用，又能在需要时安全获取存活的Activity实例。

public class LeakTracker { 
    public static List<Callback> callbacks = new ArrayList<>(); 
    public static List<WeakReference<LeakingActivity>> weakList = new ArrayList<>(); 

    // 静态内部类，不会隐式持有外部类或Activity的强引用
    private static class SafeCallback implements Callback {
        private final WeakReference<LeakingActivity> activityRef;

        public SafeCallback(LeakingActivity activity) {
            this.activityRef = new WeakReference<>(activity);
        }

        @Override
        public void onTrigger() {
            // 使用前先检查Activity是否存活
            LeakingActivity activity = activityRef.get();
            if (activity != null && !activity.isFinishing() && !activity.isDestroyed()) {
                // 在这里执行原业务逻辑
            }
        }
    }

    public void startLeak(LeakingActivity activity) { 
        callbacks.add(new SafeCallback(activity)); 
    }
}

方案2：Activity销毁时主动移除回调 #

如果业务场景允许，在LeakingActivity的onDestroy()方法中，从LeakTracker.callbacks里移除对应的Callback，直接切断强引用链。

public class LeakingActivity extends AppCompatActivity {
    private Callback activityCallback;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        LeakTracker tracker = new LeakTracker();
        // 把匿名Callback赋值给成员变量，方便后续移除
        activityCallback = new Callback() {
            // 原逻辑实现
        };
        tracker.callbacks.add(activityCallback);
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        // 移除回调，释放强引用
        LeakTracker.callbacks.remove(activityCallback);
    }
}

⚠️ 注意：如果callbacks会被多线程操作，要记得加锁保证线程安全，避免并发修改异常。

方案3：将静态列表改为弱引用列表 #

把callbacks改成存储WeakReference<Callback>，这样当Callback没有其他强引用时，GC会自动回收它，间接释放Activity的引用。但要定期清理列表里失效的弱引用，防止列表无限膨胀。

public class LeakTracker { 
    // 用弱引用列表存储回调
    public static List<WeakReference<Callback>> callbacks = new ArrayList<>(); 

    public void startLeak(LeakingActivity activity) { 
        callbacks.add(new WeakReference<>(new Callback() {
            // 原逻辑实现
        })); 
        
        // 添加新回调时顺便清理失效的弱引用
        Iterator<WeakReference<Callback>> iterator = callbacks.iterator();
        while (iterator.hasNext()) {
            if (iterator.next().get() == null) {
                iterator.remove();
            }
        }
    }
}

方案4：Lambda表达式配合WeakReference（仅限Callback是函数式接口） #

如果Callback是只有一个抽象方法的函数式接口，用Lambda写法会更简洁，同样要配合WeakReference避免强引用：

public class LeakTracker { 
    public static List<Callback> callbacks = new ArrayList<>(); 

    public void startLeak(LeakingActivity activity) { 
        WeakReference<LeakingActivity> activityRef = new WeakReference<>(activity);
        callbacks.add(() -> {
            LeakingActivity aliveActivity = activityRef.get();
            if (aliveActivity != null) {
                // 执行业务逻辑
            }
        }); 
    }
}

核心思路总结 #

匿名类引发内存泄漏的本质是隐式强引用+长期存活的容器（这里是静态列表），解决的核心就是两个方向：要么用弱引用打破强引用链，要么在合适时机主动释放引用。

内容的提问来源于stack exchange，提问作者darklord