深入了解OOM

对于Java来说,内存泄漏就是new出来的对象放在Heap上无法被垃圾收集器回收,占据内存,导致内存越来越小进而程序崩溃。说到内存泄漏,不得不提另外一个易混淆的概念:内存溢出(OOM)。什么是内存溢出呢?内存溢出是指程序向系统请求分配的空间超出了系统能给的。比如一辆车只能坐10个人,但是硬塞了15个人上去,就会挤爆了。大量的内存泄漏会导致内存溢出。

一、Java内存

说到内存,我们就来稍微了解下JVM内存。JVM内存分为method、stack、heap。

1)method:方法区,也叫静态区,主要是存放一些静态数据和常量,在编译时就分配好,在程序整个运行期间都存在,被所有线程共享;

2)stack:栈区,主要存放基本数据类型和对象的引用(不是对象本身),遵循先进后出的原则,当方法执行时,会在栈区内存中创建方法体中的局部变量,方法执行完毕自动释放内存;

3)heap:堆区,主要存放new出来的对象和数组,存储的是对象本身。JVM中只有一个堆区被所有线程共享,由JVM的垃圾回收器自动管理。

二、内存泄漏分析

了解了Java的内存分配,那么到底是哪里的内存会导致内存泄漏呢?

在JAVA中JVM的栈记录了方法的调用,每个线程拥有一个栈。在线程的运行过程当中,执行到一个新的方法调用,就在栈中增加一个内存单元,即帧(frame)。在frame中,保存有该方法调用的参数、局部变量和返回地址。然而JAVA中的局部变量只能是基本类型变量(int),或者对象的引用。所以在栈中只存放基本类型变量和对象的引用。引用的对象保存在堆中。

当某方法运行结束时,该方法对应的frame将会从栈中删除,frame中所有局部变量和参数所占有的空间也随之释放。线程回到原方法继续执行,当所有的栈都清空的时候,程序也就随之运行结束。

而对于堆内存,堆存放着普通变量。在JAVA中堆内存不会随着方法的结束而清空,所以在方法中定义了局部变量,在方法结束后变量依然存活在堆中。

综上所述,栈(stack)可以自行清除不用的内存空间,Java的垃圾回收(简称GC)可以自动清空堆中不再使用的对象。在JAVA中对象是通过引用使用的。如果再没有引用指向该对象,那么该对象就无从处理或调用该对象,这样的对象称为不可到达,GC会将其回收,释放其所占的内存空间。实现的思想如下:

1、栈中存放对象的引用,遍历栈,根据引用找到堆中对应的对象;

2、因为栈中的对象的引用执行完毕就删除了,所以根据栈中的引用,在堆中找不到的这些对象就是不可到达的,对其进行垃圾回收。

如果持有对象的强引用,那么GC是没有办法在内存中将该对象释放的,从而导致内存泄漏。那么问题来了,其他的引用类型是否会被GC回收呢?

三、引用类型

1. 强引用(Strong reference)
实际编码中最常见的一种引用类型。常见形式如:A a = new A();等。强引用本身存储在栈内存中,其存储指向堆内存中对象的地址。一般情况下,当对内存中的对象不再有任何强引用指向它时,垃圾回收机器开始考虑可能要对此内存进行的垃圾回收。如当进行编码:a = null,此时,刚刚在堆中分配地址并新建的a对象没有其他的任何引用,当系统进行垃圾回收时,堆内存将被垃圾回收。

2. 软引用(Soft Reference)
软引用的一般使用形式如下:

A a = new A();
SoftReference<A> srA = new SoftReference<A>(a);

软引用所指示的对象进行垃圾回收需要满足如下两个条件:
1.当其指示的对象没有任何强引用对象指向它;
2.当虚拟机内存不足时。
因此,SoftReference变相的延长了其指示对象占据堆内存的时间,直到虚拟机内存不足时垃圾回收器才回收此堆内存空间。

3. 弱引用(Weak Reference)
同样的,软引用的一般使用形式如下:

A a = new A();
WeakReference<A> wrA = new WeakReference<A>(a);

WeakReference不改变原有强引用对象的垃圾回收时机,一旦其指示对象没有任何强引用对象时,此对象即进入正常的垃圾回收流程。

4. 虚引用(Phantom Reference)
与SoftReference或WeakReference相比,PhantomReference主要差别体现在如下几点:
1.PhantomReference只有一个构造函数

PhantomReference(T referent, ReferenceQueue<? super T> q)

2.不管有无强引用指向PhantomReference的指示对象,PhantomReference的get()方法返回结果都是null。

因此,PhantomReference使用必须结合ReferenceQueue;
与WeakReference相同,PhantomReference并不会改变其指示对象的垃圾回收时机。

四、内存泄漏的场景

1)永远的Singleton

单例的使用在我们的程序中随处可见,因为使用它可以完美的解决我们在程序中重复创建对象的问题,不过可别小瞧它。由于单例的静态特性,使得它的生命周期和应用的生命周期会一样长,所以一旦使用有误,小心无限制的持有Activity的引用而导致内存泄漏。比如,下面的例子。

 1 package com.example.nanchen.anrsolutiondemo.singleton;
 2
 3 import android.content.Context;
 4
 5 /**
 6  * @author nanchen
 7  * @fileName ANRSolutionDemo
 8  * @packageName com.example.nanchen.anrsolutiondemo.singleton
 9  * @date 2016/09/23  11:27
10  */
11 public class SingletonBad {
12     private static SingletonBad singletonBad;
13     private Context context;
14
15     private SingletonBad(Context context){
16         this.context = context;
17     }
18
19     public static SingletonBad getInstance(Context context){
20         if (singletonBad == null){
21             singletonBad = new SingletonBad(context);
22         }
23         return singletonBad;
24     }
25 }

这个错误在生活中再普遍不过,很正常的一个单例模式,可就由于传入的是一个Context,而这个Context的生命周期的长短就尤为重要了。如果我们传入的是Activity的Context,当这个Context所对应的Activity退出的时候,由于该Context的引用被单例对象所持有,其生命周期等于整个应用程序的生命周期,所以当前Activity退出时它的内存并不会回收,这造成的内存泄漏就可想而知了。

正确的方式应该是把传入的Context换为和应用的生命周期一样长的Application的Context;

 1 package com.example.nanchen.anrsolutiondemo.singleton;
 2
 3 import android.content.Context;
 4
 5 /**
 6  * @author nanchen
 7  * @fileName ANRSolutionDemo
 8  * @packageName com.example.nanchen.anrsolutiondemo.singleton
 9  * @date 2016/09/23  11:29
10  */
11 public class SingletonGood {
12     private static SingletonGood singletonGood;
13     private Context context;
14
15     private SingletonGood(Context context){
16         this.context = context.getApplicationContext();//获取Application的context避免内存泄漏
17     }
18
19     public static SingletonGood getInstance(Context context){
20         if (singletonGood == null){
21             singletonGood = new SingletonGood(context);
22         }
23         return singletonGood;
24     }
25 }

当然,你也可以直接连Context都不用传入了。重写application,提供静态的getContext方法

 1 package com.example.nanchen.anrsolutiondemo.singleton;
 2
 3 import android.app.Application;
 4 import android.content.Context;
 5
 6 /**
 7  * @author nanchen
 8  * @fileName ANRSolutionDemo
 9  * @packageName com.example.nanchen.anrsolutiondemo.singleton
10  * @date 2016/09/23  11:32
11  */
12 public class DemoApplication extends Application {
13     private static DemoApplication demoApplication;
14
15     public static DemoApplication getInstance(){
16         return demoApplication;
17     }
18
19     public static Context getContext(){
20         return demoApplication.getApplicationContext();
21     }
22
23     @Override
24     public void onCreate() {
25         super.onCreate();
26         demoApplication = this;
27     }
28 }

自然就可以直接不用传入Context

 1 package com.example.nanchen.anrsolutiondemo.singleton;
 2
 3 import android.content.Context;
 4
 5 /**
 6  * @author nanchen
 7  * @fileName ANRSolutionDemo
 8  * @packageName com.example.nanchen.anrsolutiondemo.singleton
 9  * @date 2016/09/23  11:32
10  */
11 public class SingletonGoodNew {
12     private static SingletonGoodNew singletonGoodNew;
13
14     private Context context;
15
16     private SingletonGoodNew(){
17         this.context = DemoApplication.getContext();
18     }
19
20     public static SingletonGoodNew getInstance(){
21         if (singletonGoodNew == null){
22             singletonGoodNew = new SingletonGoodNew();
23         }
24         return singletonGoodNew;
25     }
26 }

2)令人心塞的Handler

这个东西在我最近遇到的最多了,而它也是我们在内存泄漏中最为常见的,也许你的一个小忽略就会导致内存泄漏。在android的新版本中,我们被要求必须把网络任务等耗时操作置于新线程来处理,我们通常会采用Handler。但Handler不是万能的,若是我们的编写不规范就有可能会造成内存泄漏。另外,我们知道,Handler、Message和MessageQueue都是相互关联在一起的,万一Handler发送的Message尚未被处理,则该Message及发送它的Handler对象将会被线程MessageQueue一直持有。

由于Handler属于TLS(Thread Local Storage)变量,生命周期和Activity是不一致的。因此这种实现方式一般很难保证跟View或者Activity的生命周期一致,故很容易导致无法正确释放。比如:

 1 package com.example.nanchen.anrsolutiondemo.handler;
 2
 3 import android.os.Bundle;
 4 import android.os.Handler;
 5 import android.os.Message;
 6 import android.support.v7.app.AppCompatActivity;
 7
 8 import com.example.nanchen.anrsolutiondemo.R;
 9
10 public class HandlerBadActivity extends AppCompatActivity {
11
12     private final Handler handler = new Handler(){
13         @Override
14         public void handleMessage(Message msg) {
15             super.handleMessage(msg);
16         }
17     };
18
19     @Override
20     protected void onCreate(Bundle savedInstanceState) {
21         super.onCreate(savedInstanceState);
22         setContentView(R.layout.activity_handler_bad);
23
24         // 延迟10s发送一个消息
25         handler.postDelayed(new Runnable() {
26             @Override
27             public void run() {
28                 // write something
29             }
30         },1000*60*5);
31
32         this.finish();
33     }
34 }

在例子中,我们申明了一个延迟5分钟执行的消息Message。当该Activity被finish的时候,延迟任务的Message还存在于主线程中,它持有该Activity的Handler引用,所以此时Finish掉的Activity就不会回收了,所以造成了内存泄漏(因handler为非静态内部类,它会持有外部类的引用,在这里就是当前的Activity)。

修复:这个解决也是可以通过把其声明为static的,则其存活期就跟activity的生命周期无关了。不过倘若用到Context等外部类的非static对象,还是应该通过弱引用传入。比如:

 1 package com.example.nanchen.anrsolutiondemo.handler;
 2
 3 import android.os.Bundle;
 4 import android.os.Handler;
 5 import android.os.Message;
 6 import android.support.v7.app.AppCompatActivity;
 7
 8 import com.example.nanchen.anrsolutiondemo.R;
 9
10 import java.lang.ref.WeakReference;
11
12 public class HandlerGoodActivity extends AppCompatActivity {
13
14     private static final class MyHandler extends Handler{
15         private final WeakReference<HandlerGoodActivity> mActivity;
16
17         public MyHandler(HandlerGoodActivity activity){
18             this.mActivity = new WeakReference<HandlerGoodActivity>(activity);//使用弱引用
19         }
20
21         @Override
22         public void handleMessage(Message msg) {
23             super.handleMessage(msg);
24             HandlerGoodActivity activity = mActivity.get();
25             if (activity != null){
26                 // write something
27             }
28         }
29     }
30
31     private final MyHandler myHandler = new MyHandler(this);
32
33     // 匿名内部类在static的时候绝对不会持有外部类的引用
34     private static final Runnable RUNNABLE = new Runnable() {
35         @Override
36         public void run() {
37
38         }
39     };
40
41     @Override
42     protected void onCreate(Bundle savedInstanceState) {
43         super.onCreate(savedInstanceState);
44         setContentView(R.layout.activity_handler_good);
45
46         myHandler.postDelayed(RUNNABLE,1000*60*5);
47     }
48 }

综述:推荐使用静态内部类+弱引用WeakReference这种方式,但要注意每次使用前判空。

说到若引用,这里再提下java的几种引用类型:Strong reference,SoftReference,WeakReference和PhatomReference

在android开发中,为了防止内存溢出,在处理一些占用内存大并且生命周期较长的对象的时候,可以尽量地使用软引用和弱引用技术。

比如,保存Bitmap的软引用到HashMap。

 1 package com.example.nanchen.anrsolutiondemo.photo;
 2
 3 import android.graphics.Bitmap;
 4 import android.graphics.BitmapFactory;
 5
 6 import java.lang.ref.SoftReference;
 7 import java.util.HashMap;
 8
 9 /**
10  * @author nanchen
11  * @fileName ANRSolutionDemo
12  * @packageName com.example.nanchen.anrsolutiondemo.photo
13  * @date 2016/09/23  11:58
14  */
15 public class CacheBySoftRef {
16
17     // 首先定义一个HashMap,保存软应用对象
18     private HashMap<String,SoftReference<Bitmap>> imageCache =  new HashMap<>();
19     // 再来定义一个方法,保存Bitmap的软引用到HashMap
20     public void addBitmapToCache(String path){
21         // 强引用的Bitmap对象
22         Bitmap bitmap = BitmapFactory.decodeFile(path);
23         // 软引用的Bitmap对象
24         SoftReference<Bitmap> softBitmap = new SoftReference<Bitmap>(bitmap);
25         // 添加该对象到Map使其缓存
26         imageCache.put(path,softBitmap);
27     }
28
29     // 获取的时候,可以通过SoftReference的get()的方法得到Bitmap对象
30     public Bitmap getBitmapByPath(String path){
31         // 从缓存中取软引用的Bitmap对象
32         SoftReference<Bitmap> softBitmap = imageCache.get(path);
33         // 判断是否存在软引用
34         if (softBitmap == null){
35             return null;
36         }
37         // 通过软引用取出Bitmap对象,如果由于内存不足Bitmap被回收,则取得空;
38         // 如果未被回收,则可重复使用,提高速度
39         Bitmap bitmap = softBitmap.get();
40         return bitmap;
41     }
42 }

使用软引用以后,在OutOfMemory异常发生之前,这些缓存的图片资源的内存空间可以被释放掉的,从而避免内存达到上限,避免Crash发生。

如果只是想避免OutOfMemory异常的发生,则可以使用软引用。如果对于应用的性能更在意,想尽快回收一些占用内存比较大的对象,则可以使用弱引用。

另外可以根据对象是否经常使用来判断选择软引用还是弱引用。如果该对象可能会经常使用的,就尽量用软引用。如果该对象不被使用的可能性更大些,就可以用弱引用。

ok,继续回到主题。前面所说的,创建一个静态Handler内部类,然后对 Handler 持有的对象使用弱引用,这样在回收时也可以回收 Handler 持有的对象,但是这样做虽然避免了 Activity 泄漏,不过 Looper 线程的消息队列中还是可能会有待处理的消息,所以我们在 Activity 的 Destroy 时或者 Stop 时应该移除消息队列 MessageQueue 中的消息。

下面几个方法都可以移除 Message:

3)匿名内部类/非静态内部类,它们方便却暗藏杀机

android开发经常会继承实现Activity或者Fragment或者View。如果你使用了匿名类,而又被异步线程所引用,那得小心,如果没有任何措施同样会导致内存泄漏的

 1 package com.example.nanchen.anrsolutiondemo.innerClass;
 2
 3 import android.os.Bundle;
 4 import android.support.v7.app.AppCompatActivity;
 5
 6 import com.example.nanchen.anrsolutiondemo.R;
 7
 8 public class MainActivity extends AppCompatActivity {
 9
10     private static TestInnerBad testInnerBad = null;
11
12     class TestInnerBad{
13
14     }
15
16     @Override
17     protected void onCreate(Bundle savedInstanceState) {
18         super.onCreate(savedInstanceState);
19         setContentView(R.layout.activity_inner_bad);
20
21         if (testInnerBad == null){
22             testInnerBad = new TestInnerBad();
23         }
24
25         Runnable runnable1 = new MyRunnable();
26         Runnable runnable2 = new Runnable() {
27             @Override
28             public void run() {
29
30             }
31         };
32     }
33
34     private static class MyRunnable implements Runnable{
35
36         @Override
37         public void run() {
38
39         }
40     }
41
42 }

runnable1 和 runnable2的区别就是,runnable2使用了匿名内部类,我们看看引用时的引用内存

可以看到,runnable1是没有什么特别的。但runnable2多出了一个MainActivity的引用,若是这个引用再传入到一个异步线程,此线程在和Activity生命周期不一致的时候,也就造成了Activity的泄露。

4)前辈箴言——善用static成员变量

前面就很明显,当我们的成员变量是static的时候,那么它的生命周期将和整个app的生命周期一致。

这必然会导致一系列问题,如果你的app进程设计上是长驻内存的,那即使app切到后台,这部分内存也不会被释放。按照现在手机app内存管理机制,占内存较大的后台进程将优先回收,因为如果此app做过进程互保保活,那会造成app在后台频繁重启。当手机安装了你参与开发的app以后一夜时间手机被消耗空了电量、流量,你的app不得不被用户卸载或者静默。

这里修复的方法是:

不要在类初始时初始化静态成员。可以考虑lazy初始化(延迟加载)。架构设计上要思考是否真的有必要这样做,尽量避免。如果架构需要这么设计,那么此对象的生命周期你有责任管理起来。

5)远离非静态内部类和匿名类,多用private static class。

在我们的日常代码中,这样的情况似乎很常见,及直接写一个class就这么光秃秃的情况。

   

这样就在Activity内部创建了一个非静态内部类的单例,每次启动Activity时都会使用该单例的数据,这样虽然避免了资源的重复创建,不过这种写法却会造成内存泄漏,因为非静态内部类默认会持有外部类的引用,而该非静态内部类又创建了一个静态的实例,该实例的生命周期和应用的一样长,这就导致了该静态实例一直会持有该Activity的引用,导致Activity的内存资源不能正常回收。正确的做法为:

将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例,如果需要使用Context,请按照上面推荐的使用Application 的 Context。当然,Application 的 context 不是万能的,所以也不能随便乱用,对于有些地方则必须使用 Activity 的 Context,对于Application,Service,Activity三者的Context的应用场景如下:

其中: NO1表示 Application 和 Service 可以启动一个 Activity,不过需要创建一个新的 task 任务队列。而对于 Dialog 而言,只有在 Activity 中才能创建

6) 集合对象善清除,以免内存泄漏触不及防

  我们通常会把一些对象的引用加入到集合容器(比如ArrayList)中,当我们不再需要该对象时,并没有把它的引用从集合中清理掉,这样这个集合就会越来越大。如果这个集合是static的话,那情况就更严重了。

  所以在退出程序之前,将集合里面的东西clear,然后置为null,再退出程序,如下:

 1 private List<String> nameList;
 2     private List<Fragment> list;
 3
 4     @Override
 5     public void onDestroy() {
 6         super.onDestroy();
 7         if (nameList != null){
 8             nameList.clear();
 9             nameList = null;
10         }
11         if (list != null){
12             list.clear();
13             list = null;
14         }
15     }

7)webView虽火,内存泄漏却也火的其所

  当我们不再需要使用webView的时候,应该调用它的destory()方法来销毁它,并释放其占用的内存,否则其占用的内存长期也不能回收,从而造成内存泄漏。

  解决方案:

    为webView开启另外一个进程,通过AIDL与主线程进行通信,webView所在的进程可以根据业务的需要选择合适的时机进行销毁,从而达到内存的完整释放。

  而另外一些诸如listView的Adapter没有缓存之类的这里就不再多提了。

8)做一个小的总结

  • 构造Adapter时,没有使用缓存的 convertView
  • Bitmap对象不在使用时调用recycle()释放内存
  • Context使用不当造成内存泄露:不要对一个Activity Context保持长生命周期的引用。尽量在一切可以使用应用ApplicationContext代替Context的地方进行替换。
  • 非静态内部类的静态实例容易造成内存泄漏:即一个类中如果你不能够控制它其中内部类的生命周期(譬如Activity中的一些特殊Handler等),则尽量使用静态类和弱引用来处理(譬如ViewRoot的实现)。
  • 警惕线程未终止造成的内存泄露;譬如在Activity中关联了一个生命周期超过Activity的Thread,在退出Activity时切记结束线程。一个典型的例子就是HandlerThread的run方法是一个死循环,它不会自己结束,线程的生命周期超过了Activity生命周期,我们必须手动在Activity的销毁方法中中调运thread.getLooper().quit();才不会泄露。
  • 对象的注册与反注册没有成对出现造成的内存泄露;譬如注册广播接收器、注册观察者(典型的譬如数据库的监听)等。
  • 创建与关闭没有成对出现造成的泄露;譬如Cursor资源必须手动关闭,WebView必须手动销毁,流等对象必须手动关闭等。
  • 不要在执行频率很高的方法或者循环中创建对象(比如onmeasure),可以使用HashTable等创建一组对象容器从容器中取那些对象,而不用每次new与释放。
  • 避免代码设计模式的错误造成内存泄露;譬如循环引用,A持有B,B持有C,C持有A,这样的设计谁都得不到释放。

五、内存泄漏检测工具

MAT(Memory Analyzer Tool):点我下载~

强大的开源内存检测工具LeakCanary:官方文档

参考链接:

Android内存泄漏的八种可能(上)

[译]Android防止内存泄漏的八种方法(下)

时间: 2024-10-05 04:58:18

深入了解OOM的相关文章

ViewPager做图片浏览器,加载大量图片OOM的问题修正

1 /** 2 * @author CHQ 3 * @version 1.0 4 * @date 创建时间: 2016/7/26 17:18 5 * @parameter 6 * @return 7 * 图片查看器 8 * //可以查看网络图片 9 * //可以查看本地图片 10 */ 11 public class PhotoScan extends Activity { 12 private PhotoViewPager mViewPager; 13 private List<View>

Android 防止OOM优化

1. Android2.x及以下的系统优化: Bitmap被解码后的像素被存储在Native Heap中, Dalvik Heap有个external计数,记录了Bitmap所占用的内存. 当 Dalvik Allocated + External Allocated + new Allocated>= 允许分配最大值时,就会引发OutOfMemoryError异常, 销毁的时候必须要调用recycle().BitmapFactory.Options参数,隐藏了inNativeAlloc属性,

Android高效加载大图、多图解决方案,有效避免程序OOM

我们可以通过下面的代码看出每个应用程序最高可用内存是多少 int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);   Log.d("TAG", "Max memory is " + maxMemory + "KB"); BitmapFactory这个类提供了多个解析方法(decodeByteArray, decodeFile, decodeResource等)用于创建Bit

Android LruCache 压缩图片 有效避免程序OOM

转载请注明出处:http://blog.csdn.net/guolin_blog/article/details/9316683 本篇文章主要内容来自于Android Doc,我翻译之后又做了些加工,英文好的朋友也可以直接去读原文. http://developer.android.com/training/displaying-bitmaps/index.html 压缩加载大图片 我们在编写Android程序的时候经常要用到许多图片,不同图片总是会有不同的形状.不同的大小,但在大多数情况下,这

OOM异常产生的原因和处理方法

一般而言,android中常见的原因主要有以下几个: 1.数据库的cursor没有关闭. 2.构造adapter没有使用缓存contentview. 3.调用registerReceiver()后未调用unregisterReceiver(). 4.未关闭InputStream/OutputStream. 5.Bitmap使用后未调用recycle(). 6.Context泄漏. 7.static关键字等. 接下来分别对这些溢出情况说出解决的思路: 1.针对数据库cursor没有关闭的情况,如果

OOM总结

本文主要信息是来自互联网,我只是自己做了一点总结和摘要. OOM发生的原因 简单的说通过不同的内存分配方式对不同的对象进行操作,会因为android系统版本的差异而产生不同的行为.主要是2.0和4.0有较大的变化. 在2.x系统中,dalvik allocated  + external allocated + 新分配的大小>= getMemoryClass() 就会发生OOM. 在4.x系统中,废除了external计数器,类似Bitmap的分配改到了Dalvik的java Heap 中申请,

JVM OOM处理

一般OOM可能情况如下: 1.OutOfMemoryError: Java heap space: 2.OutOfMemoryError: PermGen space: 3.OutOfMemoryError: unable to create new native thread 对于第1及第2种情况可以通过设置JVM参数(Xms -Xmx -XX:PermSize -XX:MaxPermSize)来进行调节处理: 问题3产生的原因是由于我们创建了太多的线程,而能创建的线程数是有限制的,导致了异常

(转)根据ImageView的大小来压缩Bitmap,避免OOM

本文转载于:http://www.cnblogs.com/tianzhijiexian/p/4254110.html Bitmap是引起OOM的罪魁祸首之一,当我们从网络上下载图片的时候无法知道网络图片的准确大小,所以为了节约内存,一般会在服务器上缓存一个缩略图,提升下载速度.除此之外,我们还可以在本地显示图片前将图片进行压缩,使其完全符合imageview的大小,这样就不会浪费内存了. 一.思路 思路:计算出要显示bitmap的imageview大小,根据imageview的大小压缩bitma

android 图片加载优化,避免oom问题产生

1,及时回收bitmap,在activity的onstop()和onDestory()里面调用如下代码进行bitmap的回收: // 先判断是否已经回收 if(bitmap != null && !bitmap.isRecycled()){ // 回收并且置为null bitmap.recycle(); bitmap = null; } System.gc(); 2,对oom异常的捕获:出现异常不能让程序就那么崩掉吧,所以对程序中中设计bitmap的操作都要检测oom异常进而进行处理: B

Linux OOM killer 机制

Linux中的Out Of Memory(OOM) Killer功能是一种确保系统内存足够的最终手段,可以在耗尽系统内存或交换区后,按某种算法判断占用系统最多资源的进程,向进程发送信号,强制终止该进程. 简单来说该机制会监控那些占用内存过大,尤其是瞬间很快消耗大量内存的进程,为了防止内存耗尽而内核会把该进程杀掉. 这个功能即使在无法释放内存的情况下,也能够重复进行确保内存的处理过程,防止系统停滞,还可以找出过度消耗内存的进程. 典型的情况是:某天一台机器突然ssh远程登录不了,但能ping通,说