java.lang.OutOfMemoryError异常解决方法

引言

java.lang.OutOfMemoryError简称OOM内存溢出，这是一种很常见的导致的程序崩溃的问题，但也是很容易被开发者忽视的一个问题，因为它不像java.lang.NullPointerException这样的错误，程序一运行就能被发现，它不是每次运行或每台手机都出现，有时可能要等到项目上线，后台产生了大量数据之后才能被发现。
最近做了一个新闻类的项目，和商城类的项目相比，由于涉及更多的图片和视频，很明显数据量要大得多，所以更容易产生OOM的问题。如何解决这个异常呢，首先我们来看看它是怎么产生的。

产生原因

常见原因有以下几种：
1.内存中加载的数据量过于庞大，如一次从数据库取出过多数据；
2.集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；
3.代码中存在死循环或循环产生过多重复的对象实体；
4.使用的第三方软件中的BUG；
5.启动参数内存值设定的过小；

对应的Log显示的错误提示如下：
1.tomcat:java.lang.OutOfMemoryError: PermGen space
2.tomcat:java.lang.OutOfMemoryError: Java heap space
3.weblogic:Root cause of ServletException java.lang.OutOfMemoryError
4.resin:java.lang.OutOfMemoryError
5.java:java.lang.OutOfMemoryError

解决方案

1.避免循环产生过多重复的对象实体

个人觉得对于这个问题开发程序时应该是可以避免的，即使写程序时没有考虑到，发现是这个原因造成的，应该也是很容易解决的；
例如,对复杂的listview进行合理设计与编码,注意重用Adapter里面的convertView，以及holder机制的运用

2.自定义内存大小和优化Dalvik虚拟机的堆内存

在Android2.2之前，有这样一个类dalvik.system.VMRuntime，它提供的setTargetHeapUtilization()方法可以增强程序堆内存的处理效率，代码如下：

//在程序onCreate时就可以调用即可

private final static floatTARGET_HEAP_UTILIZATION = 0.75f;  
VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION); 

还有setMinimumHeapSize()方法可以自定义应用需要多大的内存，强行设置最小内存大小,
//设置最小heap内存为6MB大小

private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ; 
VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE); 

但是上面说了这种方法只适用于Android2.2以下，否则编译是通不过的，既然取消了这个方法，肯定有能够代替这个方法，且比这个方法更完美的解决方案，这就是下面我要重点说的几种方法；

3.Fragment的懒加载

现在大多数程序一个Activity里面可能会以viewpager（或其他容器）与多个Fragment来组合使用，而如果每个fragment都需要去加载数据，或从本地加载，或从网络加载，那么在这个activity刚创建的时候就变成需要初始化大量资源。那么，能不能做到当切换到这个fragment的时候，它才去初始化呢？

答案就在Fragment里的setUserVisibleHint这个方法里,该方法用于告诉系统，这个Fragment的UI是否是可见的。所以我们只需要继承Fragment并重写该方法，即可实现在fragment可见时才进行数据加载操作，即Fragment的懒加载。

代码如下：

    public abstract class LazyFragment extends Fragment {  
        protected boolean isVisible;
    @Override  
    public void setUserVisibleHint(boolean isVisibleToUser) {  
        super.setUserVisibleHint(isVisibleToUser);  
        if(getUserVisibleHint()) {  
            isVisible = true;  
            onVisible();  
        } else {  
            isVisible = false;  
            onInvisible();  
        }  
    }  
  
    protected void onVisible(){  
        lazyLoad();  
    }  
  
    protected abstract void lazyLoad();  
  
    protected void onInvisible(){}  
}

在LazyFragment，我增加了三个方法，一个是onVisiable，即fragment被设置为可见时调用，一个是onInvisible，即fragment被设置为不可见时调用。另外再写了一个lazyLoad的抽象方法，该方法在onVisible里面调用。

你可能会想，为什么不在getUserVisibleHint里面就直接调用呢？我这么写是为了代码的复用。因为在fragment中，我们还需要创建视图（onCreateView()方法），可能还需要在它不可见时就进行其他小量的初始化操作（比如初始化需要通过AIDL调用的远程服务）等。

而setUserVisibleHint是在onCreateView之前调用的，那么在视图未初始化的时候，在lazyLoad当中就使用的话，就会有空指针的异常。而把lazyLoad抽离成一个方法，那么它的子类就可以这样做：

public class OpenResultFragment extends LazyFragment{  
    // 标志位，标志已经初始化完成。  
    private boolean isPrepared;  
  
    @Override  
    public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {  
        Log.d(LOG_TAG, "onCreateView");  
        View view = inflater.inflate(R.layout.fragment_open_result, container, false);  
        //XXX初始化view的各控件  
    isPrepared = true;  
        lazyLoad();  
        return view;  
    }  
  
    @Override  
    protected void lazyLoad() {  
        if(!isPrepared || !isVisible) {  
            return;  
        }  
        //填充各控件的数据  
    }  
  
}  

在上面的类当中，我们增加了一个标志位isPrepared，用于标志是否初始化完成。然后在我们所需要的初始化操作完成之后调用，如上面的例子当中，在初始化view之后，设置 isPrepared为true，同时调用lazyLoad()方法。而在lazyLoad()当中，判断isPrepared和isVisible只要有一个不为true就不往下执行。也就是仅当初始化完成，并且可见的时候才继续加载，这样的避免了未初始化完成就使用而带来的问题。

4.利用BitmapFactory.Options限制图片的大小

有时加载数据量并不是很大时也会产生OOM异常，一般是由于加载图片造成的，Bitmap加载图片最终都是通过java层的createBitmap来完成的，需要消耗大量内存,我们可以利用BitmapFactory.Options限制图片的大小，降低图片质量，减少图片所占内存

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); 
 

5.及时对图片进行recyle()操作

if(!bmp.isRecycle() ){ 
         bmp.recycle()   //回收图片所占的内存 
         system.gc()  //提醒系统及时回收 
} 

总结

以上是OOM的常见的几种产生原因和解决方案，还有很多方法，例如，
还有看看页面布局当中有没有大的图片，比如背景图之类的。去除xml中相关设置，改在程序中设置背景图（放在onCreate()方法中）；
尽量不使用静态的图片和全局性的图片；
在Activity destory时注意，bg.setCallback(null); 防止Activity得不到及时的释放。
等等，还需要进一步地研究