Android中使用Handler造成内存泄露的分析和解决

最新推荐文章于 2024-05-01 20:53:11 发布
最新推荐文章于 2024-05-01 20:53:11 发布
阅读量5.1k 收藏 2
点赞数
分类专栏： 性能优化

 

        讲解一

 

原文地址：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 中的内存泄漏，主要指的是第二种情况。

 

    可能光说概念太抽象了，大家可以看一下这样的例子：

 
  1. Vector v = new  Vector( 10 );  
  2. for  ( int  i = 1 ;i < 100 ; i ++ ){  
  3. Object o = new  Object();  
  4. v.add(o);  
  5. o = null ;  
  6. } 

在这个例子中，代码栈中存在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 的内存泄露表现为一个内存对象的生命周期超出了程序需要它的时间长度。我们有时也将其称为“对象游离”。

例如：

 
  1. public class FileSearch{  
  2.       private byte [] content;  
  3.       private File mFile;  
  4.      public FileSearch(File file){  
  5.       mFile = file;  
  6.       }  
  7.      public boolean hasString(String str){  
  8.          int size = getFileSize(mFile);  
  9.         content =  new  byte [size];  
  10.          loadFile(mFile, content);  
  11.          String s =  new String(content);  
  12.          return s.contains(str);  
  13.      }  
  14. } 

在这段代码中，FileSearch 类中有一个函数 hasString ，用来判断文档中是否含有指定的字符串。流程是先将mFile 加载到内存中，然后进行判断。但是，这里的问题是，将 content 声明为了实例变量，而不是本地变量。于是，在此函数返回之后，内存中仍然存在整个文件的数据。而很明显，这些数据我们后续是不再需要的，这就造成了内存的无故浪费。

要避免这种情况下的内存泄露，要求我们以C/C++ 的内存管理思维来管理自己分配的内存。第一，是在声明对象引用之前，明确内存对象的有效作用域。在一个函数内有效的内存对象，应该声明为 local 变量，与类实例生命周期相同的要声明为实例变量……以此类推。第二，在内存对象不再需要时，记得手动将其引用置空。

复杂数据结构中的内存泄露问题

在实际的项目中，我们经常用到一些较为复杂的数据结构用于缓存程序运行过程中需要的数据信息。有时，由于数据结构过于复杂，或者我们存在一些特殊的需求（例如，在内存允许的情况下，尽可能多的缓存信息来提高程序的运行速度等情况），我们很难对数据结构中数据的生命周期作出明确的界定。这个时候，我们可以使用Java 中一种特殊的机制来达到防止内存泄露的目的。

之前我们介绍过，Java 的 GC 机制是建立在跟踪内存的引用机制上的。而在此之前，我们所使用的引用都只是定义一个“ Object o; ”这样形式的。事实上，这只是 Java 引用机制中的一种默认情况，除此之外，还有其他的一些引用方式。通过使用这些特殊的引用机制，配合 GC 机制，就可以达到一些我们需要的效果。

 

奔跑的平头哥
关注
  • 0
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
详解Android使用Handler造成内存泄露的分析及解决方法
08-26
主要介绍了详解Android使用Handler造成内存泄露的分析及解决方法，小编觉得挺不错的，现在分享给大家，也给大家做个参考。一起跟随小编过来看看吧
android中handler内存泄漏解决方法,Handler内存泄漏原因及解决方案
weixin_31570865的博客
05-25 1051
Handler内存泄漏原因及解决方案目录：1.须知：主线程Looper生命周期和Activity的生命周期一致。非静态内部类，或者匿名内部类。默认持有外部类引用。2.原因：Handler造成内存泄露的原因。非静态内部类，或者匿名内部类。使得Handler默认持有外部类的引用。在Activity销毁时，由于Handler可能有未执行完/正在执行的Message。导致Handler持有Activity...
关于Android中使用Handler造成内存泄露的分析和解决
2401_84149496的博客
04-19 1014
上面是一段简单的Handler的使用。当使用内部类（包括匿名类）来创建Handler的时候，Handler对象会隐式地持有一个外部类对象（通常是一个Activity）的引用（不然你怎么可能通过Handler来操作Activity中的View？而Handler通常会伴随着一个耗时的后台线程（例如从网络拉取图片）一起出现，这个后台线程在任务执行完毕（例如图片下载完毕）之后，通过消息机制通知Handler，然后Handler把图片更新到界面。
关于Android中使用Handler造成内存泄露的分析和解决(1)
最新发布
2401_84538510的博客
05-01 13
【Android 详细知识点思维脑图（技能树）】我个人是做Android开发，已经有十来年了，目前在某创业公司任职CTO兼系统架构师。虽然 Android 没有前几年火热了，已经过去了会四大组件就能找到高薪职位的时代了。这只能说明 Android 中级以下的岗位饱和了，现在高级工程师还是比较缺少的，很多高级职位给的薪资真的特别高（钱多也不一定能找到合适的），所以努力让自己成为高级工程师才是最重要的。这里附上上述的面试题相关的几十套字节跳动，京东，小米，腾讯、头条、阿里、美团等公司19年的面试题。
面试官：Handler内存泄露的原因是什么？我，一个小例子彻底搞懂Android的MVP模式到底是什么
m0_v648374的博客
03-22 650
Java虚拟机中使用的算法来决定对象是否可以被回收。即通过GCRoot对象为起始点，向下搜索走过的路径（引用链），如果发现某个对象或者对象组为不可达状态，则将其进行回收。而内存泄漏指的就是有些对象（短周期对象）没有用了，但是却被其他有用的类（长周期对象）所引用，从而导致无用对象占据了内存空间，形成内存泄漏。所以上面的问题，如果仅仅回答，没有指出内部类被谁所引用，那么按道理来说是不会发生内存泄漏的，因为内部类和外部类都是无用对象了，是可以被正常回收的。所以这一题的关键在于，内部类被谁引用了？
Android使用Handler造成内存泄露的分析及解决方法
dengduoya4019的博客
12-07 191
一、什么是内存泄露？ 　　Java使用有向图机制，通过GC自动检查内存中的对象（什么时候检查由虚拟机决定），如果GC发现一个或一组对象为不可到达状态，则将该对象从内存中回收。也就是说，一个对象不被任何引用所指向，则该对象会在被GC发现的时候被回收；另外，如果一组对象中只包含互相的引用，而没有来自它们外部的引用（例如有两个对象A和B互相持有引用，但没有任何外部对象持有指向A或B的引用），...
解决Android使用Handler造成内存泄露问题
08-29
Android中使用Handler可能会造成内存泄露的问题，这是因为Handler对象会隐式地持有一个外部类对象的引用，使得Activity无法被回收。这种情况下，出现了内存泄露的问题，可能会导致OOM（内存溢出），程序出错。 一、...
Android中Handler引起的内存泄露问题解决办法
09-03
总结起来，防止Android中Handler引发的内存泄露，关键在于正确管理Handler与Activity之间的引用关系，使用静态内部类并结合WeakReference，确保当Activity不再使用时能够被正确地释放。同时，使用Lint等工具进行代码...
Handler杂谈【二】Handler的用法及解析
AfinalStone的专栏
12-22 668
原文地址：https://www.jianshu.com/p/7cdf2c2ed354 在Handler机制中，每一个线程有一个Looper，Looper.loop()一直无限循环，为什么没有造成ANR呢？ 首先要知道造成ANR的基本原因是： 1.在5秒内没有响应输入的事件（例如，按键按下，屏幕触摸） 2.BroadcastReceiver在10秒内没有执行完毕 造成以上两点的原因有很多，比如在主...
Android开发-Handler引起的内存泄漏-实验、分析、总结。
李可乐的专栏
05-24 4405
介绍最近在恶补Handler的知识，其中就涉及到了Handler引起的内存泄露问题，网络上有很多的分析文章。我就按照这些文章的思路，写代码验证，主要是验证和记录。 使用的内存检测工具是：LeakCanary 中文使用说明 英文原文： http://www.androiddesignpatterns.com/2013/01/inner-class-handler-memory-leak.h
Handler引起的内存泄漏详解及解决方案
左大侠的博客
09-28 3723
       本文已在我的公众号CodeFire上优先发布,装载请注明出处.        在日常的开发中，我们经常遇到的异常里内存泄漏算是出现频率不低的一种，也常常是最令人崩溃的一种，当查询数据量比较大而调用数据库cursor没有关闭、在页面退出前某些注册了的事件没有取消、加载图片过大没做特殊处理的时候等等，这些都是造成OOM的原因。但是在我们最熟悉且最经常使用的Handler身上，也会“不经...
Handler造成Activity泄漏，用弱引用真的有用么?
阳光下的小树
09-07 1万+
网上很多教程，解决Handler造成的内存泄漏问题，基本上是使用弱引用来解决的，但是使用弱引用真的有效么?直接写代码演示，以及分析。 下面分析过程分为4种，第一种是Handler声明成静态的并且弱引用Activity。第二种是handler声明成成员变量的，使用弱引用。第三种是将handler声明成静态的。第四种是声明成普通成员变量，但是在onDestory中移除未执行完的任务。
Handler使用引起的内存泄漏原因以及解决办法
qwli7
10-28 7480
问题来源在之前我的一篇文章中我就指出了我在项目中如何会出现 内存泄漏的问题的，有兴趣的小伙伴可以点击获取原文看看这个问题出现的来龙去脉，在这里我就不过多做说明了。下面我们用最简单直接粗暴的方式进入主题。在我们开发android应用程序的时候，通常会写出如下代码 private Handler mHandler = new Handler(){ @Override
Android 中 Handler 引起的内存泄露
路卫杰的专栏
01-16 627
原文出处：http://mobile.51cto.com/aprogram-463978.htm 在Android常用编程中，Handler在进行异步操作并处理返回结果时经常被使用。通常我们的代码会这样实现。 public class SampleActivity extends Activity {    private final Handler mLeakyHan
Android性能优化之handler的正确使用与解析
LQ的博客
04-14 3980
1.什么是Handler    是Android消息机制的上层接口，是一种更新ui的机制。   （Android是线程不安全的，所以能在子线程更新ui，只能执行耗时操作 ，所以要通过handler发送消息更新）2.Handler实现原理ThreadLocal：通过不同的线程访问同一个ThreadLocal，无论是ThreadLocal的get或set方法，它们对ThreadLocal的读写操作都仅...
Android使用FileInputStream和FileOutputStream进行文件I/O操作
热门推荐
Singleton1900的专栏
02-26 4万+
在文件I/O操作上，除了标准的Java I/O类和方法外，Android系统本身提供了两个方法用于文件的读/写操作，以简化使用标准I/O的步骤。    openFileInput(String name)方法：用于读取当前应用文件夹下的文件，并返回FileInputStream输入流。    openFileOutput(String name,int mode)方法：用于向当前应用文件夹下输
Handler 内存泄漏和优化
茶卡y的专栏
07-02 1162
在之前的项目中，Handler也使用，但往往是这么用的： private Handler mHandler = new Handler() { @Override public void handleMessage(Message msg) { super.handleMessage(msg); } }; @...
android中handler内存泄漏解决方法,Android 中 Handler 导致的内存泄漏
weixin_39605296的博客
05-25 242
问题介绍在Android开发过程中，我们经常用Handler来处理异步操作的返回结果，却没注意到很容易发生内存泄漏，代码通常如下：12345678public class MainActivity extends Activity{private Handler myHandler = new Handler() {@Overridepublic void handleMessage(Messag...
Handler会不会造成内存泄漏，如何解决？
06-13
3. 原因：如果在 Activity 或 Fragment 中使用了非静态内部类的 Handler 对象，并且该对象持有了外部 Activity 或 Fragment 的引用，就会导致内存泄漏。 解决方法：可以使用静态内部类来避免内存泄漏，或者使用弱...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值