企业网站托管一年多少钱,聊城优化网站建设,wordpress 页面列表显示,网址ip地址查询前言 不少人认为JAVA程序#xff0c;因为有垃圾回收机制#xff0c;应该没有内存泄露。 其实如果我们一个程序中#xff0c;已经不再使用某个对象#xff0c;但是因为仍然有引用指向它#xff0c;垃圾回收器就无法回收它#xff0c;当然该对象占用的内存就无法被使用因为有垃圾回收机制应该没有内存泄露。 其实如果我们一个程序中已经不再使用某个对象但是因为仍然有引用指向它垃圾回收器就无法回收它当然该对象占用的内存就无法被使用这就造成了内存泄露。如果我们的java运行很久,而这种内存泄露不断的发生最后就没内存可用了。当然java的内存泄漏和C/C是不一样的。如果java程序完全结束后它所有的对象就都不可达了系统就可以对他们进行垃圾回收它的内存泄露仅仅限于它本身而不会影响整个系统的。C/C的内存泄露就比较糟糕了它的内存泄露是系统级即使该C/C程序退出它的泄露的内存也无法被系统回收永远不可用了除非重启机器。 Android的一个应用程序的内存泄露对别的应用程序影响不大。为了能够使得Android应用程序安全且快速的运行Android的每个应用程序都会使用一个专有的Dalvik虚拟机实例来运行它是由Zygote服务进程孵化出来的也就是说每个应用程序都是在属于自己的进程中运行的。Android为不同类型的进程分配了不同的内存使用上限如果程序在运行过程中出现了内存泄漏的而造成应用进程使用的内存超过了这个上限则会被系统视为内存泄漏从而被kill掉这使得仅仅自己的进程被kill掉而不会影响其他进程如果是system_process等系统进程出问题的话则会引起系统重启。 一、引用没释放造成的内存泄露 1.1、注册没取消造成的内存泄露 这种Android的内存泄露比纯java的内存泄露还要严重因为其他一些Android程序可能引用我们的Anroid程序的对象比如注册机制。即使我们的Android程序已经结束了但是别的引用程序仍然还有对我们的Android程序的某个对象的引用泄露的内存依然不能被垃圾回收。 比如 假设我们希望在锁屏界面(LockScreen)中监听系统中的电话服务以获取一些信息(如信号强度等)则可以在LockScreen中定义一个PhoneStateListener的对象同时将它注册到TelephonyManager服务中。对于LockScreen对象当需要显示锁屏界面的时候就会创建一个LockScreen对象而当锁屏界面消失的时候LockScreen对象就会被释放掉。 但是如果在释放LockScreen对象的时候忘记取消我们之前注册的PhoneStateListener对象则会导致LockScreen无法被垃圾回收。如果不断的使锁屏界面显示和消失则最终会由于大量的LockScreen对象没有办法被回收而引起OutOfMemory,使得system_process进程挂掉。 虽然有些系统程序它本身好像是可以自动取消注册的当然不及时但是我们还是应该在我们的程序中明确的取消注册程序结束时应该把所有的注册都取消掉。 1.2、集合容器对象没清理造成的内存泄露 我们通常把一些对象的引用加入到了集合容器比如ArrayList中当我们不需要该对象时并没有把它的引用从集合中清理掉这样这个集合就会越来越大。如果这个集合是static的话那情况就更严重了。 1.3、Context泄漏 所谓的Context泄漏其实更多的是指Activity泄露这是一个很隐晦的OutOfMemoryError的情况。 先看一个Android官网提供的例子 private static Drawable sBackground; Override protected void onCreate(Bundle state) { super.onCreate(state); TextView label new TextView(this); label.setText(Leaks are bad); if (sBackground null) { sBackground getDrawable(R.drawable.large_bitmap); } label.setBackgroundDrawable(sBackground); setContentView(label); } 这段代码效率很快但同时又是极其错误的 在第一次屏幕方向切换时它泄露了一开始创建的Activity。当一个Drawable附加到一个 View上时 View会将其作为一个callback设定到Drawable上。上述的代码片段意味着这个静态的Drawable拥有一个TextView的引用 而TextView又拥有ActivityContext类型的引用换句话说Drawable拥有了更多的对象引用。即使Activity被 销毁内存仍然不会被释放。 另外对Context的引用超过它本身的生命周期也会导致该Context无法回收从而导致内存泄漏。所以尽量使用Application这种Context类型。 这种Context拥有和应用程序一样长的生命周期并且不依赖Activity的生命周期。如果你打算保存一个长时间的对象 并且其需要一个 Context记得使用Application对象。你可以通过调用Context.getApplicationContext()或 Activity.getApplication()轻松得到Application对象。 最近遇到一种情况引起了Context泄漏就是在Activity销毁时里面有其他线程没有停。 总结一下避免Context泄漏应该注意的问题 1.尽量使用Application这种Context类型。 2.注意对Context的引用不要超过它本身的生命周期。 3.慎重的对Context使用“static”关键字。 4.Context里如果有线程一定要在onDestroy()里及时停掉。 1.4、static关键字的滥用 当类的成员变量声明成static后它是属于类的而不是属于对象的如果我们将很大的资源对象Bitmapcontext等声明成static那么这些资源不会随着对象的回收而回收 会一直存在所以在使用static关键字定义成员变量的时候要慎重。 1.5、WebView对象没有销毁 当我们不要使用WebView对象时应该调用它的destory()函数来销毁它并释放其占用的内存否则其占用的内存长期也不能被回收从而造成内存泄露 1.6、GridView的滥用 GridView和ListView的实现方式不太一样。GridView的View不是即时创建的而是全部保存在内存中的。比如一个GridView有100项虽然我们只能看到10项但是其实整个100项都是在内存中的。 二、资源对象没关闭造成的内存泄露 资源性对象比如CursorFile文件等往往都用了一些缓冲我们在不使用的时候应该及时关闭它们以便它们的缓冲及时回收内存。它们的缓冲不仅存在于java虚拟机内还存在于java虚拟机外。如果我们仅仅是把它的引用设置为null,而不关闭它们往往会造成内存泄露。因为有些资源性对象比如SQLiteCursor在析构函数finalize,如果我们没有关闭它它自己会调close()关闭如果我们没有关闭它系统在回收它时也会关闭它但是这样的效率太低了。因此对于资源性对象在不使用的时候应该调用它的close()函数将其关闭掉然后才置为null.在我们的程序退出时一定要确保我们的资源性对象已经关闭。 程序中经常会进行查询数据库的操作但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小对内存的消耗不容易被发现只有在常时间大量操作的情况下才会复现内存问题这样就会给以后的测试和问题排查带来困难和风险。 三、一些不良代码成内存压力 有些代码并不造成内存泄露但是它们或是对没使用的内存没进行有效及时的释放或是没有有效的利用已有的对象而是频繁的申请新内存对内存的回收和分配造成很大影响的容易迫使虚拟机不得不给该应用进程分配更多的内存造成不必要的内存开支。 3.1、Bitmap没调用recycle() Bitmap对象在不使用时,我们应该先调用recycle()然后才它设置为null. 虽然Bitmap在被回收时可以通过BitmapFinalizer来回收内存。但是调用recycle()是一个良好的习惯 在Android4.0之前Bitmap的内存是分配在Native堆中调用recycle()可以立即释放Native内存。 从Android4.0开始Bitmap的内存就是分配在dalvik堆中即JAVA堆中的调用recycle()并不能立即释放Native内存。但是调用recycle()也是一个良好的习惯。 可以通过dumpsys meminfo命令查看一个进程的内存情况。 示例adb shell dumpsys meminfo com.lenovo.robin 运行结果。 Applications Memory Usage (kB): Uptime: 18696550 Realtime: 18696541 ** MEMINFO in pid 7985 [com.lenovo.robin] ** native dalvik other total size: 4828 5379 N/A 10207 allocated: 4073 2852 N/A 6925 free: 10 2527 N/A 2537 (Pss): 608 317 1603 2528 (shared dirty): 2240 1896 6056 10192 (priv dirty): 548 36 1276 1860 Objects Views: 0 ViewRoots: 0 AppContexts: 0 Activities: 0 Assets: 2 AssetManagers: 2 Local Binders: 5 Proxy Binders: 11 Death Recipients: 1 OpenSSL Sockets: 0 SQL heap: 0 MEMORY_USED: 0 PAGECACHE_OVERFLOW: 0 MALLOC_SIZE: 0 关于内存统计的更多内容请参考《Android内存泄露利器内存统计篇》 3.2、构造Adapter时没有使用缓存的 convertView 以构造ListView的BaseAdapter为例在BaseAdapter中提共了方法 public View getView(int position, View convertView, ViewGroup parent) 来向ListView提供每一个item所需要的view对象。初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的view对象同时ListView会将这些view对象缓存起来。当向上滚动ListView时原先位于最上面的list item的view对象会被回收然后被用来构造新出现的最下面的list item。这个构造过程就是由getView()方法完成的getView()的第二个形参 View convertView就是被缓存起来的list item的view对象(初始化时缓存中没有view对象则convertView是null)。 由此可以看出如果我们不去使用convertView而是每次都在getView()中重新实例化一个View对象的话即浪费时间也造成内存垃圾给垃圾回收增加压力如果垃圾回收来不及的话虚拟机将不得不给该应用进程分配更多的内存造成不必要的内存开支。ListView回收list item的view对象的过程可以查看: android.widget.AbsListView.java -- void addScrapView(View scrap) 方法。 示例代码 public View getView(int position, View convertView, ViewGroup parent) { View view new Xxx(...); ... ... return view; } 修正示例代码 public View getView(int position, View convertView, ViewGroup parent) { View view null; if (convertView ! null) { view convertView; populate(view, getItem(position)); ... } else { view new Xxx(...); ... } return view; } 3.3、ThreadLocal使用不当 如果我们粗暴的把ThreadLocal设置null,而不调用remove()方法或set(null),那么就可能造成ThreadLocal绑定的对象长期也不能被回收因而产出内存泄露。 关于此的更多内容请参考《ThreadLocal的内存泄露》 四、JNI代码的内存泄露 关于此的详细内容请参考《JNI引用与垃圾回收》转载于:https://www.cnblogs.com/sage-blog/p/4085880.html
