Android中使用Handler造成内存泄露的分析和解决
讲解一 原文地址：http://www.linuxidc.com/Linux/2013-12/94065.htm什么是内存泄露？Java使用有向图机制，通过GC自动检查内存中的对象（什么时候检查由虚拟机决定），如果GC发现一个或一组对象为不可到达状态，则将该对象从内存中回收。也就是说，一个对象不被任何引用所指向，则该对象会在被GC发现的时候被回收；另外，如果一...
讲解一
原文地址：http://www.linuxidc.com/Linux/2013-12/94065.htm
什么是内存泄露？
Java使用有向图机制，通过GC自动检查内存中的对象（什么时候检查由虚拟机决定），如果GC发现一个或一组对象为不可到达状态，则将该对象从内存中回收。也就是说，一个对象不被任何引用所指向，则该对象会在被GC发现的时候被回收；另外，如果一组对象中只包含互相的引用，而没有来自它们外部的引用（例如有两个对象A和B互相持有引用，但没有任何外部对象持有指向A或B的引用），这仍然属于不可到达，同样会被GC回收。
Android中使用Handler造成内存泄露的原因
Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
mImageView.setImageBitmap(mBitmap);
}
}
上面是一段简单的Handler的使用。当使用内部类（包括匿名类）来创建Handler的时候，Handler对象会隐式地持有一个外部类对象（通常是一个Activity）的引用（不然你怎么可能通过Handler来操作Activity中的View？）。而Handler通常会伴随着一个耗时的后台线程（例如从网络拉取图片）一起出现，这个后台线程在任务执行完毕（例如图片下载完毕）之后，通过消息机制通知Handler，然后Handler把图片更新到界面。然而，如果用户在网络请求过程中关闭了Activity，正常情况下，Activity不再被使用，它就有可能在GC检查时被回收掉，但由于这时线程尚未执行完，而该线程持有Handler的引用（不然它怎么发消息给Handler？），这个Handler又持有Activity的引用，就导致该Activity无法被回收（即内存泄露），直到网络请求结束（例如图片下载完毕）。另外，如果你执行了Handler的postDelayed()方法，该方法会将你的Handler装入一个Message，并把这条Message推到MessageQueue中，那么在你设定的delay到达之前，会有一条MessageQueue -> Message -> Handler -> Activity的链，导致你的Activity被持有引用而无法被回收。
内存泄露的危害
只有一个，那就是虚拟机占用内存过高，导致OOM（内存溢出），程序出错。对于Android应用来说，就是你的用户打开一个Activity，使用完之后关闭它，内存泄露；又打开，又关闭，又泄露；几次之后，程序占用内存超过系统限制，FC。
使用Handler导致内存泄露的解决方法
方法一：通过程序逻辑来进行保护。
1.在关闭Activity的时候停掉你的后台线程。线程停掉了，就相当于切断了Handler和外部连接的线，Activity自然会在合适的时候被回收。
2.如果你的Handler是被delay的Message持有了引用，那么使用相应的Handler的removeCallbacks()方法，把消息对象从消息队列移除就行了。
方法二：将Handler声明为静态类。
静态类不持有外部类的对象，所以你的Activity可以随意被回收。代码如下：
static class MyHandler extends Handler {
@Override
public void handleMessage(Message msg) {
mImageView.setImageBitmap(mBitmap);
}
}
但其实没这么简单。使用了以上代码之后，你会发现，由于Handler不再持有外部类对象的引用，导致程序不允许你在Handler中操作Activity中的对象了。所以你需要在Handler中增加一个对Activity的弱引用（WeakReference）：
static class MyHandler extends Handler {
WeakReference<Activity > mActivityReference;
MyHandler(Activity activity) {
mActivityReference= new WeakReference<Activity>(activity);
}
@Override
public void handleMessage(Message msg) {
final Activity activity = mActivityReference.get();
if (activity != null) {
mImageView.setImageBitmap(mBitmap);
}
}
}
将代码改为以上形式之后，就算完成了。
延伸：什么是WeakReference？
WeakReference弱引用，与强引用（即我们常说的引用）相对，它的特点是，GC在回收时会忽略掉弱引用，即就算有弱引用指向某对象，但只要该对象没有被强引用指向（实际上多数时候还要求没有软引用，但此处软引用的概念可以忽略），该对象就会在被GC检查到时回收掉。对于上面的代码，用户在关闭Activity之后，就算后台线程还没结束，但由于仅有一条来自Handler的弱引用指向Activity，所以GC仍然会在检查的时候把Activity回收掉。这样，内存泄露的问题就不会出现了。
讲解二
原文地址：http://www.cnblogs.com/manuosex/p/3661762.html
Android oom 有时出现很频繁，这一般不是Android设计的问题，一般是我们的问题。
就我的经验而言，出现oom，无非主要是以下几个方面：
一、加载对象过大
二、相应资源过多，没有来不及释放。
解决这样的问题，也有一下几个方面：
一：在内存引用上做些处理，常用的有软引用、强化引用、弱引用
二：在内存中加载图片时直接在内存中做处理，如：边界压缩.
三：动态回收内存
四：优化Dalvik虚拟机的堆内存分配
五：自定义堆内存大小
可真有这么简单吗，不见得，看我娓娓道来：
软引用(SoftReference)、虚引用(PhantomRefrence)、弱引用(WeakReference),这三个类是对heap中java对象的应用，通过这个三个类可以和gc做简单的交互，除了这三个以外还有一个是最常用的强引用.
强引用，例如下面代码：
Object o=new Object();
Object o1=o;
上面代码中第一句是在heap堆中创建新的Object对象通过o引用这个对象，第二句是通过o建立o1到new Object()这个heap堆中的对象的引用，这两个引用都是强引用.只要存在对heap中对象的引用，gc就不会收集该对象.如果通过如下代码：
o=null;
o1=null;
heap中对象有强可及对象、软可及对象、弱可及对象、虚可及对象和不可到达对象。应用的强弱顺序是强、软、弱、和虚。对于对象是属于哪种可及的对象，由他的最强的引用决定。如下:
String abc=new String("abc"); //1
SoftReference<String> abcSoftRef=new SoftReference<String>(abc); //2
WeakReference<String> abcWeakRef = new WeakReference<String>(abc); //3
abc=null; //4
abcSoftRef.clear();//5在此例中，透过 get() 可以取得此 Reference 的所指到的对象，如果返回值为 null 的话，代表此对象已经被清除。这类的技巧，在设计 Optimizer 或 Debugger 这类的程序时常会用到，因为这类程序需要取得某对象的信息，但是不可以 影响此对象的垃圾收集。
虚引用
就是没有的意思，建立虚引用之后通过get方法返回结果始终为null,通过源代码你会发现,虚引用通向会把引用的对象写进referent,只是get方法返回结果为null.先看一下和gc交互的过程在说一下他的作用.
不把referent设置为null, 直接把heap中的new String("abc")对象设置为可结束的(finalizable).
与软引用和弱引用不同, 先把PhantomRefrence对象添加到它的ReferenceQueue中.然后在释放虚可及的对象. 你会发现在收集heap中的new String("abc")对象之前,你就可以做一些其他的事情.通过以下代码可以了解他的作用.
虽然这些常见引用，能够使其gc回收，但是gc又不是非常的智能了，因而oom乱免。
二：在内存中加载图片时直接在内存中做处理。
尽量不要使用setImageBitmap或setImageResource或BitmapFactory.decodeResource来设置一张大图，因为这些函数在完成decode后，最终都是通过java层的createBitmap来完成的，需要消耗更多内存。
因此，改用先通过BitmapFactory.decodeStream方法，创建出一个bitmap，再将其设为ImageView的 source，decodeStream最大的秘密在于其直接调用JNI>>nativeDecodeAsset()来完成decode，无需再使用java层的createBitmap，从而节省了java层的空间。
如果在读取时加上图片的Config参数，可以跟有效减少加载的内存，从而跟有效阻止抛out of Memory异常，另外，decodeStream直接拿的图片来读取字节码了， 不会根据机器的各种分辨率来自动适应， 使用了decodeStream之后，需要在hdpi和mdpi，ldpi中配置相应的图片资源， 否则在不同分辨率机器上都是同样大小（像素点数量），显示出来的大小就不对了。
另外，以下方式也大有帮助：
InputStream is = this.getResources().openRawResource(R.drawable.pic1);
BitmapFactory.Options options=new BitmapFactory.Options();
options.inJustDecodeBounds = false;
options.inSampleSize = 10; //width，hight设为原来的十分一
Bitmap btp =BitmapFactory.decodeStream(is,null,options);
if(!bmp.isRecycle() ){
bmp.recycle() //回收图片所占的内存
system.gc() //提醒系统及时回收
}
以下奉上一个方法,以最省内存的方式读取本地资源的图片
/**
*
* @param context
* @param resId
* @return
*/
public static Bitmap readBitMap(Context context, int resId){
BitmapFactory.Options opt = new BitmapFactory.Options();
opt.inPreferredConfig = Bitmap.Config.RGB_565;
opt.inPurgeable = true;
opt.inInputShareable = true;
//获取资源图片
InputStream is = context.getResources().openRawResource(resId);
return BitmapFactory.decodeStream(is,null,opt);
}
昨天在模拟器上给gallery放入图片的时候，出现java.lang.OutOfMemoryError: bitmap size exceeds VM budget 异常，图像大小超过了RAM内存。
模拟器RAM比较小，只有8M内存，当我放入的大量的图片（每个100多K左右），就出现上面的原因。
由于每张图片先前是压缩的情况，放入到Bitmap的时候，大小会变大，导致超出RAM内存，具体解决办法如下：
```java
//解决加载图片 内存溢出的问题
//Options 只保存图片尺寸大小，不保存图片到内存
BitmapFactory.Options opts = new BitmapFactory.Options();
//缩放的比例，缩放是很难按准备的比例进行缩放的，其值表明缩放的倍数，SDK中建议其值是2的指数值,值越大会导致图片不清晰
opts.inSampleSize = 4;
Bitmap bmp = null;
bmp = BitmapFactory.decodeResource(getResources(), mImageIds[position],opts);
...
//回收
bmp.recycle();
通过上面的方式解决了，但是这并不是最完美的解决方式。
通过一些了解，得知如下：
优化Dalvik虚拟机的堆内存分配
对于Android平台来说，其托管层使用的Dalvik JavaVM从目前的表现来看还有很多地方可以优化处理，比如我们在开发一些大型游戏或耗资源的应用中可能考虑手动干涉GC处理，使用dalvik.system.VMRuntime类提供的setTargetHeapUtilization方法可以增强程序堆内存的处理效率。当然具体原理我们可以参考开源工程，这里我们仅说下使用方法: private final static floatTARGET_HEAP_UTILIZATION = 0.75f; 在程序onCreate时就可以调用VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION);即可。
Android堆内存也可自己定义大小
对于一些Android项目，影响性能瓶颈的主要是Android自己内存管理机制问题，目前手机厂商对RAM都比较吝啬，对于软件的流畅性来说RAM对性能的影响十分敏感，除了 优化Dalvik虚拟机的堆内存分配外，我们还可以强制定义自己软件的对内存大小，我们使用Dalvik提供的dalvik.system.VMRuntime类来设置最小堆内存为例:
private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ;
VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE); //设置最小heap内存为6MB大小。当然对于内存吃紧来说还可以通过手动干涉GC去处理
bitmap 设置图片尺寸，避免 内存溢出 OutOfMemoryError的优化方法
★android 中用bitmap 时很容易内存溢出，报如下错误：Java.lang.OutOfMemoryError : bitmap size exceeds VM budget
● 主要是加上这段：
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 2;
● eg1：(通过Uri取图片)
private ImageView preview;
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 2;//图片宽高都为原来的二分之一，即图片为原来的四分之一
Bitmap bitmap = BitmapFactory.decodeStream(cr
.openInputStream(uri), null, options);
preview.setImageBitmap(bitmap);
以上代码可以优化内存溢出，但它只是改变图片大小，并不能彻底解决内存溢出。
● eg2:（通过路径去图片）
private ImageView preview;
private String fileName= "/sdcard/DCIM/Camera/2010-05-14 16.01.44.jpg";
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 2;//图片宽高都为原来的二分之一，即图片为原来的四分之一
Bitmap b = BitmapFactory.decodeFile(fileName, options);
preview.setImageBitmap(b);
filePath.setText(fileName);
这样，能够压缩足够的比例，但是对于小内存手机，特别是那种16mheap的手机是避免不了了。
三.动态分配内存
动态内存管理DMM（Dynamic Memory Management）是从Heap中直接分配内存和回收内存。
有两种方法实现动态内存管理。
一是显示内存管理EMM（Explicit Memory Management）。
在EMM方式，内存从Heap中进行分配，用完后手动回收。程序使用malloc()函数分配整数数组，并使用free()函数释放分配的内存。
二是自动内存管理AMM（Automatic Memory Management）。
AMM也可叫垃圾回收器（Garbage Collection）。Java编程语言实现了AMM，与EMM不同，Run-time system关注已分配的内存空间，一旦不再使用，立即回收。
无论是EMM还是AMM，所有的Heap管理计划都面临一些共同的问题和前在的缺陷：
1）内部碎片（Internal Fragmentation）
当内存有浪费时，内部碎片出现。因为内存请求可导致分配的内存块过大。比如请求128字节的存储空间，结果Run-time system分配了512字节。
2）外部碎片（External Fragmentation）
当一系列的内存请求留下了数个有效的内存块，但这些内存块的大小均不能满足新请求服务，此时出现外部碎片。
3）基于定位的延迟（Location-based Latency）
延迟问题出现在两个数据值存储得相隔很远，导致访问时间增加。
EMM往往比AMM更快。
EMM与AMM比较表：
——————————————————————————————————————
EMM AMM
——————————————————————————————————————
Benefits 尺寸更小、速度更快、易控制 stay focused on domain issues
Costs 复杂、记账、内存泄露、指针悬空 不错的性能
——————————————————————————————————————
早期的垃圾回收器非常慢，往往占用50%的执行时间。
垃圾回收器理论产生于1959年，Dan Edwards在Lisp编程语言的开发时实现了第一个垃圾回收器。
垃圾回收器有三种基本的经典算法：
1）Reference counting（引用计数）
基本思想是：当对象创建并赋值时该对象的引用计数器置1，每当对象给任意变量赋值时，引用记数＋1；一旦退出作用域则引用记数－1。一旦引用记数变为0，则该对象可以被垃圾回收。
引用记数有其相应的优势：对程序的执行来说，每次操作只需要花费很小块的时间。这对于不能被过长中断的实时系统来说有着天然的优势。
但也有其不足：不能够检测到环（两个对象的互相引用）；同时在每次增加或者减少引用记数的时候比较费时间。
在现代的垃圾回收算法中，引用记数已经不再使用。
2）Mark-sweep（标记清理）
基本思想是：每次从根集出发寻找所有的引用（称为活对象），每找到一个，则对其做出标记，当追踪完成之后，所有的未标记对象便是需要回收的垃圾。
也叫追踪算法，基于标记并清除。这个垃圾回收步骤分为两个阶段：在标记阶段，垃圾回收器遍历整棵引用树并标记每一个遇到的对象。在清除阶段，未标记的对象被释放，并使其在内存中可用。
3）Copying collection（复制收集）
基本思想是：将内存划分为两块，一块是当前正在使用；另一块是当前未用。每次分配时使用当前正在使用内存，当无可用内存时，对该区域内存进行标记，并将标记的对象全部拷贝到当前未用内存区，这是反转两区域，即当前可用区域变为当前未用，而当前未用变为当前可用，继续执行该算法。
拷贝算法需要停止所有的程序活动，然后开始冗长而繁忙的copy工作。这点是其不利的地方。
近年来还有两种算法：
1）Generational garbage collection（分代）
其思想依据是：
(1) 被大多数程序创建的大多数对象有着非常短的生存期。
(2) 被大多数程序创建的部分对象有着非常长的生存期。
简单拷贝算法的主要不足是它们花费了更多的时间去拷贝了一些长期生存的对象。
而分代算法的基本思想是：将内存区域分两块（或更多），其中一块代表年轻代，另一块代表老的一代。针对不同的特点，对年轻一代的垃圾收集更为频繁，对老代的收集则较少，每次经过年轻一代的垃圾回收总会有未被收集的活对象，这些活对象经过收集之后会增加成熟度，当成熟度到达一定程度，则将其放进老代内存块中。
分代算法很好的实现了垃圾回收的动态性，同时避免了内存碎片，是目前许多JVM使用的垃圾回收算法。
2）Conservative garbage collection（保守）
哪一种算法最好？答案是没有最好。
EMM作为很常用的垃圾回收算法，有5种基本方法：
1）Table-driven algorithms
表驱动算法把内存分为固定尺寸的块集合。这些块使用抽象数据结构进行索引。比如一个bit对应一个块，用0和1表示是否分配。不利因素：位映射依赖于内存块的尺寸；另外，搜索一系列的空闲内存块可能需要搜索整个bit映射表，这影响性能。
2）Sequential fit
顺序适应算法允许内存分为不同的尺寸。此算法跟踪已分配和空闲的Heap，标记空闲块的起始地址和结束地址。它有三种子分类：
(1) First fit（首次适应）——分配找到的第一个适合内存请求的块
(2) Best fit（最佳适应）——分配最适合内存请求的块
(3) Worst fit（最不适应）——分配最大的块给内存请求
3）Buddy systems
Buddy systems算法的主要目的是加速已分配内存在释放后的合并速度。显示内存管理EMM使用Buddy systems算法可能导致内部碎片。
4）Segregated storage
隔离存储技术涉及到把Heap分成多个区域（zone），并为每个区域采用不同的内存管理计划。这是很有效的方法。
5）Sub-allocators
子配置技术尝试解决在Run-time System下分配大块内存并单独管理的内存分配问题。换句话说，程序完全负责自己的私有存储堆（stockpile）的内存分配和回收，无需run-time System的帮助。它可能带来额外的复杂性，但是你可以显著地提高性能。在1990年的《C Compiler Design》一书中，Allen Holub就极好地利用了Sub-allocators来加速其编译器的实现。
注意，显示内存管理EMM必须是灵活的，能够响应数种不同类型的请求。
最后，使用EMM还是使用AMM？这是一个Religious question，凭个人喜好。EMM在复杂的开销下实现了速度和控制。AMM牺牲了性能，但换来了简单性。
无论是emm，amm分配内存，出现了oom的问题，由于加载内存过大也是在所难免。
四。优化Dalvik虚拟机的堆内存分配
对于Android平台来说，其托管层使用的Dalvik Java VM从目前的表现来看还有很多地方可以优化处理，比如我们在开发一些大型游戏或耗资源的应用中可能考虑手动干涉GC处理，使用dalvik.system.VMRuntime类提供的setTargetHeapUtilization方法可以增强程序堆内存的处理效率。当然具体原理我们可以参考开源工程，这里我们仅说下使用方法:private final static float TARGET_HEAP_UTILIZATION = 0.75f;在程序onCreate时就可以调用VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION);即可。
Android堆内存也可自己定义大小
对于一些Android项目，影响性能瓶颈的主要是Android自己内存管理机制问题，目前手机厂商对RAM都比较吝啬，对于软件的流畅性来说RAM对性能的影响十分敏感，除了 优化Dalvik虚拟机的堆内存分配外，我们还可以强制定义自己软件的堆内存大小，我们使用Dalvik提供的 dalvik.system.VMRuntime类来设置最小堆内存为例:
private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ;
VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE); //设置最小heap内存为6MB大小。当然对于内存吃紧来说还可以通过手动干涉GC去处理
注意了，这个设置dalvik虚拟机的配置的方法对Android4.0 设置无效。
这就是我对Android的oom的一点看法.
讲解三
原文地址http://www.jb51.net/article/38162.htm
Java内存管理机制
在C++ 语言中，如果需要动态分配一块内存，程序员需要负责这块内存的整个生命周期。从申请分配、到使用、再到最后的释放。这样的过程非常灵活，但是却十分繁琐，程序员很容易由于疏忽而忘记释放内存，从而导致内存的泄露。 Java 语言对内存管理做了自己的优化，这就是垃圾回收机制。 Java 的几乎所有内存对象都是在堆内存上分配（基本数据类型除外），然后由 GC （ garbage collection）负责自动回收不再使用的内存。
上面是Java 内存管理机制的基本情况。但是如果仅仅理解到这里，我们在实际的项目开发中仍然会遇到内存泄漏的问题。也许有人表示怀疑，既然 Java 的垃圾回收机制能够自动的回收内存，怎么还会出现内存泄漏的情况呢？这个问题，我们需要知道 GC 在什么时候回收内存对象，什么样的内存对象会被 GC 认为是“不再使用”的。
Java中对内存对象的访问，使用的是引用的方式。在 Java 代码中我们维护一个内存对象的引用变量，通过这个引用变量的值，我们可以访问到对应的内存地址中的内存对象空间。在 Java 程序中，这个引用变量本身既可以存放堆内存中，又可以放在代码栈的内存中（与基本数据类型相同）。 GC 线程会从代码栈中的引用变量开始跟踪，从而判定哪些内存是正在使用的。如果 GC 线程通过这种方式，无法跟踪到某一块堆内存，那么 GC 就认为这块内存将不再使用了（因为代码中已经无法访问这块内存了）。
通过这种有向图的内存管理方式，当一个内存对象失去了所有的引用之后，GC 就可以将其回收。反过来说，如果这个对象还存在引用，那么它将不会被 GC 回收，哪怕是 Java 虚拟机抛出 OutOfMemoryError 。
Java内存泄露
一般来说内存泄漏有两种情况。一种情况如在C/C++ 语言中的，在堆中的分配的内存，在没有将其释放掉的时候，就将所有能访问这块内存的方式都删掉（如指针重新赋值）；另一种情况则是在内存对象明明已经不需要的时候，还仍然保留着这块内存和它的访问方式（引用）。第一种情况，在 Java 中已经由于垃圾回收机制的引入，得到了很好的解决。所以， Java 中的内存泄漏，主要指的是第二种情况。
可能光说概念太抽象了，大家可以看一下这样的例子：
- Vector v = new Vector( 10 );
- for ( int i = 1 ;i < 100 ; i ++ ){
- Object o = new Object();
- v.add(o);
- o = null ;
- }
在这个例子中，代码栈中存在Vector 对象的引用 v 和 Object 对象的引用 o 。在 For 循环中，我们不断的生成新的对象，然后将其添加到 Vector 对象中，之后将 o 引用置空。问题是当 o 引用被置空后，如果发生 GC ，我们创建的 Object 对象是否能够被 GC 回收呢？答案是否定的。因为， GC 在跟踪代码栈中的引用时，会发现 v 引用，而继续往下跟踪，就会发现 v 引用指向的内存空间中又存在指向 Object 对象的引用。也就是说尽管 o 引用已经被置空，但是 Object 对象仍然存在其他的引用，是可以被访问到的，所以 GC 无法将其释放掉。如果在此循环之后， Object 对象对程序已经没有任何作用，那么我们就认为此 Java 程序发生了内存泄漏。
尽管对于C/C++ 中的内存泄露情况来说， Java 内存泄露导致的破坏性小，除了少数情况会出现程序崩溃的情况外，大多数情况下程序仍然能正常运行。但是，在移动设备对于内存和 CPU都有较严格的限制的情况下， Java 的内存溢出会导致程序效率低下、占用大量不需要的内存等问题。这将导致整个机器性能变差，严重的也会引起抛出 OutOfMemoryError ，导致程序崩溃。
一般情况下内存泄漏的避免
在不涉及复杂数据结构的一般情况下，Java 的内存泄露表现为一个内存对象的生命周期超出了程序需要它的时间长度。我们有时也将其称为“对象游离”。
例如：
- public class FileSearch{
- private byte [] content;
- private File mFile;
- public FileSearch(File file){
- mFile = file;
- }
- public boolean hasString(String str){
- int size = getFileSize(mFile);
- content = new byte [size];
- loadFile(mFile, content);
- String s = new String(content);
- return s.contains(str);
- }
- }
在这段代码中，FileSearch 类中有一个函数 hasString ，用来判断文档中是否含有指定的字符串。流程是先将mFile 加载到内存中，然后进行判断。但是，这里的问题是，将 content 声明为了实例变量，而不是本地变量。于是，在此函数返回之后，内存中仍然存在整个文件的数据。而很明显，这些数据我们后续是不再需要的，这就造成了内存的无故浪费。
要避免这种情况下的内存泄露，要求我们以C/C++ 的内存管理思维来管理自己分配的内存。第一，是在声明对象引用之前，明确内存对象的有效作用域。在一个函数内有效的内存对象，应该声明为 local 变量，与类实例生命周期相同的要声明为实例变量……以此类推。第二，在内存对象不再需要时，记得手动将其引用置空。
复杂数据结构中的内存泄露问题
在实际的项目中，我们经常用到一些较为复杂的数据结构用于缓存程序运行过程中需要的数据信息。有时，由于数据结构过于复杂，或者我们存在一些特殊的需求（例如，在内存允许的情况下，尽可能多的缓存信息来提高程序的运行速度等情况），我们很难对数据结构中数据的生命周期作出明确的界定。这个时候，我们可以使用Java 中一种特殊的机制来达到防止内存泄露的目的。
之前我们介绍过，Java 的 GC 机制是建立在跟踪内存的引用机制上的。而在此之前，我们所使用的引用都只是定义一个“ Object o; ”这样形式的。事实上，这只是 Java 引用机制中的一种默认情况，除此之外，还有其他的一些引用方式。通过使用这些特殊的引用机制，配合 GC 机制，就可以达到一些我们需要的效果。
华为开发者空间，是为全球开发者打造的专属开发空间，汇聚了华为优质开发资源及工具，致力于让每一位开发者拥有一台云主机，基于华为根生态开发、创新。
更多推荐
0
0- 0
已为社区贡献2条内容
免费领云主机
华为云 x DeepSeek：AI驱动云上应用创新
DTT年度收官盛典：华为开发者空间大咖汇，共探云端开发创新
华为云数字人，助力行业数字化业务创新
企业数据治理一站式解决方案及应用实践
轻松构建AIoT智能场景应用
所有评论(0)