安卓内存泄露和gc，内存泄露的场景和解决方案，Emmm，走起

谈及内存泄露，少不了gc

1. Java的垃圾回收机制（GC）简介： Java虚拟机（JVM）通过垃圾回收机制自动管理内存。对象实例在内存（堆）中创建，当它们不再被任何引用变量指向时，理论上应该被GC回收以释放内存。GC主要关注两点：

   • 可达性分析（Reachability Analysis） ：JVM通过从根集（如静态变量、活跃线程的局部变量等）出发，检查哪些对象是"可达的"。不可达的对象可能成为GC的回收目标。
   • 标记和清除：GC将找出的不可达对象标记为待回收，然后在适当的时候清除这些对象，释放内存。

2. 内存泄露与GC的关系： 在Java（和Android）中，内存泄露通常指长时间保持对不再需要的对象的引用。这些对象即便是"无用"的，也仍然是"可达的"，因此GC不会回收它们。这就是为什么内存泄露与GC机制密切相关：即使有GC，错误的引用管理仍然会导致内存泄露。

内存泄露的常见场景：

静态集合类引用

• 场景：静态集合（如static HashMap）用于存储对象引用时，如果不适当地移除这些引用，对象将永远不会被垃圾回收，因为静态成员的生命周期与应用程序一样长。
• 避免策略：定期清理集合中的内容，或者考虑使用弱引用集合，如WeakHashMap。

public class ExampleClass {
    private static final HashMap<Long, Object> cache = new HashMap<>();

    public void addToCache(Long key, Object object) {
        cache.put(key, object);
    }

    public void removeFromCache(Long key) {
        cache.remove(key);
    }

    // 如果忘记调用 removeFromCache，对象将一直占用内存
}

监听器和回调

• 场景：注册但未正确注销的监听器和回调，特别是在Activity或Fragment中。这些对象因为持有对长生命周期对象的引用而无法被回收。
• 避免策略：在组件（如Activity）销毁时，确保注销监听器和回调。

public class MyActivity extends Activity {
    private SomeEventListener listener;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        listener = new SomeEventListener() {
            @Override
            public void onEvent() {
                // do something
            }
        };

        SomeManager.getInstance().registerListener(listener);
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        SomeManager.getInstance().unregisterListener(listener); // 必须注销，否则可能导致内存泄露
    }
}

    ```



##  **内部类和匿名内部类**

-   场景：非静态内部类和匿名内部类隐式持有对外部类的强引用。如果内部类的实例被长生命周期的对象持有，可能会阻止外部类实例被垃圾回收。
-   避免策略：使用静态内部类并传递对外部类的弱引用。


```JAVA
public class OuterClass {
    private int someField;

    public void doSomething() {
        InnerClass innerClass = new InnerClass();
        innerClass.doInnerThing();
    }

    private class InnerClass {
        public void doInnerThing() {
            System.out.println(someField);
        }
    }
    // 如果InnerClass的实例被长生命周期对象持有，可能会阻止OuterClass的实例被回收
}

单例模式导致的内存泄漏

• 场景：如果单例持有对Context的引用（特别是Activity的Context），它可能阻止Activity的内存被回收，导致泄露。

• 避免策略：确保单例不持有对Activity的长期引用。如果需要Context，考虑使用Application Context。

public class SingletonExample {
    private static SingletonExample instance;
    private Context applicationContext;

    private SingletonExample(Context context) {
        // 使用Application Context
        this.applicationContext = context.getApplicationContext();
    }

    public static synchronized SingletonExample getInstance(Context context) {
        if (instance == null) {
            instance = new SingletonExample(context);
        }
        return instance;
    }
}

Handler 导致的内存泄漏

• 场景：非静态内部类的Handler可以隐式地持有对其外部类（通常是Activity）的引用，导致Activity无法被回收。

• 避免策略：使用静态内部类并通过弱引用来引用外部类。

public class MyActivity extends AppCompatActivity {
    private static class MyHandler extends Handler {
        private final WeakReference<MyActivity> weakActivity;

        MyHandler(MyActivity activity) {
            weakActivity = new WeakReference<>(activity);
        }

        @Override
        public void handleMessage(Message msg) {
            MyActivity activity = weakActivity.get();
            if (activity != null) {
                // ... 更新UI等
            }
        }
    }

    private final MyHandler myHandler = new MyHandler(this);
}

长时间运行的后台任务

• 场景：后台任务（如线程或AsyncTask）可能持有对Activity的引用，导致Activity无法被正确回收。

• 避免策略：使用弱引用或确保在Activity销毁时取消这些任务。

public class MyActivity extends AppCompatActivity {
    private AsyncTask<Void, Void, Void> myTask;

    @Override
    protected void onDestroy() {
        super.onDestroy();
        if (myTask != null) {
            myTask.cancel(true);
        }
    }

    // 异步任务或其他后台操作
}

Context 的错误引用

• 场景：错误地持有Activity的Context而不是Application的Context。
• 避免策略：在不需要Activity的Context的情况下，使用Application Context。

使用缓存导致的内存泄漏

• 场景：缓存（如图片缓存）如果不正确管理，可能占用大量内存且不会被释放。

• 避免策略：使用合适大小的缓存策略，或者考虑使用LruCache等智能缓存。

public class ImageCache {
    private LruCache<String, Bitmap> memoryCache;

    public ImageCache() {
        final int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
        final int cacheSize = maxMemory / 8; // 使用可用内存的1/8作为缓存

        memoryCache = new LruCache<String, Bitmap>(cacheSize) {
            @Override
            protected int sizeOf(String key, Bitmap bitmap) {
                return bitmap.getByteCount() / 1024;
            }
        };
    }

    // 添加和获取缓存的方法
}

---

避免内存泄露的策略：

使用弱引用 ：例如，使用WeakReference或WeakHashMap。弱引用对象会在JVM进行GC时被回收，即使它们还是"可达的"。

import android.graphics.Bitmap;
import java.lang.ref.WeakReference;

public class ImageLoader {
    private WeakReference<Bitmap> imageCache;

    public void loadImage(ImageView imageView, String url) {
        Bitmap image = /* 加载图片 */;
        imageCache = new WeakReference<>(image);
        imageView.setImageBitmap(image);
    }

    public Bitmap getCachedImage() {
        return imageCache != null ? imageCache.get() : null;
    }
}

在这个例子中，图片被缓存在`WeakReference`中。一旦内存紧张，这些图片就可以被垃圾收集器回收。

前面提到的`WeakHashMap`，它在内部使用弱引用作为键。这意味着，即使`WeakHashMap`自身具有较长的生命周期，它的键（和相应的值）可以在不再有其他强引用时，由GC自动清理，这有助于避免内存泄露。

及时清理：比如在Activity销毁时注销监听器，清空集合中的对象等。

在Activity或Fragment的生命周期结束时，应清理资源，特别是注销监听器和广播接收器。

public class MyActivity extends AppCompatActivity {
    private BroadcastReceiver receiver;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        receiver = new MyBroadcastReceiver();
        registerReceiver(receiver, new IntentFilter("SOME_ACTION"));
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        unregisterReceiver(receiver); // 防止内存泄露
    }
}

这里在`onDestroy`中注销了广播接收器，以防止内存泄露。

谨慎使用静态变量：因为静态变量的生命周期很长，可能会导致它引用的对象无法及时回收。

public class Utils {
    private static Context appContext;

    public static void initialize(Context context) {
        appContext = context.getApplicationContext(); // 使用应用程序上下文
    }
}

在这个示例中，我们使用应用程序上下文而不是活动上下文来初始化静态变量。这可以避免持有对Activity的引用，从而减少内存泄露的风险。

避免使用匿名类和内部类

• 匿名类和非静态内部类会隐式地持有对外部类的强引用。在Activity等含有较复杂生命周期的类中使用时，可能会导致外部类实例无法被垃圾收集器回收。

• 尽量使用静态内部类并通过弱引用传递外部类的上下文。

public class MyActivity extends AppCompatActivity {
    private static class MyRunnable implements Runnable {
        private final WeakReference<MyActivity> activityReference;

        MyRunnable(MyActivity activity) {
            this.activityReference = new WeakReference<>(activity);
        }

        @Override
        public void run() {
            MyActivity activity = activityReference.get();
            if (activity != null) {
                // 操作引用的Activity
            }
        }
    }

    // 使用
    new Thread(new MyRunnable(this)).start();
}

避免使用单例模式

• 如果单例持有对Activity的引用，可能会导致整个Activity无法被回收，从而造成内存泄露。

• 确保单例不直接或间接持有Activity或View的引用。如果需要上下文，使用全局上下文（Application Context）。

public class SingletonExample {
    private static SingletonExample instance;
    private Context applicationContext;

    private SingletonExample(Context context) {
        this.applicationContext = context.getApplicationContext();
    }

    public static synchronized SingletonExample getInstance(Context context) {
        if (instance == null) {
            instance = new SingletonExample(context);
        }
        return instance;
    }
}

避免 Handler 导致的内存泄漏

• 默认的Handler是一个内部类，隐式地持有外部类（如Activity）的强引用。这可能导致Activity无法被回收，特别是当Handler延迟发送消息或在长时间运行的线程中使用时。

• 使用静态内部类加弱引用或使用View.post()方法。

public class MyActivity extends AppCompatActivity {
    private static class MyHandler extends Handler {
        private final WeakReference<MyActivity> weakActivity;

        MyHandler(MyActivity activity) {
            weakActivity = new WeakReference<>(activity);
        }

        @Override
        public void handleMessage(Message msg) {
            MyActivity activity = weakActivity.get();
            if (activity != null) {
                // 更新UI
            }
        }
    }

    private final MyHandler myHandler = new MyHandler(this);
}

---

如何处理一份存在内存泄露问题的代码？

处理一个存在内存泄露的Android应用通常包括几个步骤：初步审查代码、使用工具识别泄露、分析泄露原因，并最终修复问题。以下是这个过程的详细步骤：

1. 初步代码审查

   • 检查是否存在上文提到的常见内存泄露场景，例如静态集合类、长生命周期对象持有短生命周期对象的引用、未正确注销的监听器和广播接收器等。
   • 特别关注那些经常出现问题的部分，如Activity、Fragment、Bitmap处理、Handler等。

2. 使用内存泄露检测工具

   • LeakCanary：在Android应用中集成LeakCanary。它是一个开箱即用的内存泄露检测工具，在运行时自动检测内存泄露，并提供详细的泄露报告。
   • Android Studio Profiler：使用Android Studio的Profiler工具监控应用的内存使用情况。它可以帮助识别内存使用异常的时间点和位置。

3. 分析泄露报告和堆转储

   • 根据LeakCanary的报告或Profiler的分析结果，确定可能的内存泄露源头。
   • 使用MAT（Memory Analyzer Tool）或Android Studio自带的分析工具来分析堆转储（heap dump），以确定泄露对象的类型和它们的引用链。

4. 修复内存泄露

   • 针对确定的内存泄露点，修改代码来解决问题。这可能包括：

     • 移除不必要的静态引用。
     • 确保在合适的生命周期事件中释放资源。
     • 使用弱引用（WeakReference）来替代强引用。
     • 修改内部类（特别是Handler和Thread）的定义，使其不再隐式持有对外部类的强引用。

   • 测试修复后的代码，确保泄露已经被解决，并且修复没有引入新的问题。

5. 代码审计和重构

   • 如果内存泄露是由于设计问题造成的，考虑进行更深入的代码审计和重构。
   • 提高团队对内存泄露问题的意识，避免未来类似的问题。

6. 回归测试和监控

   • 在修复后进行全面的回归测试，以确保应用的其他部分未受影响。
   • 在随后的开发中继续使用LeakCanary或类似工具，以防止新的内存泄露问题发生。