一次内存泄漏的问题记录

最新推荐文章于 2024-05-24 23:24:10 发布
最新推荐文章于 2024-05-24 23:24:10 发布
阅读量1.2w 收藏 15
点赞数 4
分类专栏： Android 应用开发 文章标签： android java android studio oom 内存泄漏
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/lucky_tom/article/details/108754572
版权

项目场景：

同事在开发一款人脸识别app时，在多次执行，打开--》人脸识别--》关闭--》打开循环测试过程中会耗尽内存导致被kill。

问题描述：

测试同学通过用monkey脚本测试，遇到内存泄漏的问题。

 

  • 日志片段1：可以看到系统一直在频繁gc，已经超过设定的512mb上限。

09-22 13:53:21.106  3052  3127 I zygote  : Waiting for a blocking GC Alloc
09-22 13:53:21.630  3052  5107 I zygote  : Clamp target GC heap from 535MB to 512MB
09-22 13:53:21.630  3052  5107 I zygote  : Alloc concurrent copying GC freed 38(1192B) AllocSpace objects, 0(0B) LOS objects, 0% free, 511MB/512MB, paused 167us total 1.441s
09-22 13:53:21.630  3052  3142 I zygote  : WaitForGcToComplete blocked Alloc on HeapTrim for 2.013s
09-22 13:53:21.630  3052  5107 W zygote  : Throwing OutOfMemoryError "Failed to allocate a 460812 byte allocation with 1192 free bytes and 1192B until OOM, max allowed footprint 536870912, growth limit 536870912"
09-22 13:53:21.630  3052  3142 I zygote  : Starting a blocking GC Alloc
09-22 13:53:21.630  3052  3142 I zygote  : Starting a blocking GC Alloc
09-22 13:53:21.630  3052  4168 I zygote  : Waiting for a blocking GC Alloc
09-22 13:53:21.630  3052  5107 I zygote  : Waiting for a blocking GC Alloc
09-22 13:53:21.630  3052  3806 I zygote  : Waiting for a blocking GC Alloc
09-22 13:53:21.630  3052  3127 I zygote  : Waiting for a blocking GC Alloc
09-22 13:53:21.630  3052  3061 I zygote  : Waiting for a blocking GC Alloc
09-22 13:53:22.103  3052  3142 I zygote  : Clamp target GC heap from 535MB to 512MB
09-22 13:53:22.103  3052  3142 I zygote  : Alloc concurrent copying GC freed 30(808B) AllocSpace objects, 0(0B) LOS objects, 0% free, 511MB/512MB, paused 145us total 472.588ms
09-22 13:53:22.103  3052  4168 I zygote  : WaitForGcToComplete blocked Alloc on HeapTrim for 2.484s
09-22 13:53:22.103  3052  4168 I zygote  : Starting a blocking GC Alloc
09-22 13:53:22.103  3052  4168 I zygote  : Starting a blocking GC Alloc
09-22 13:53:22.103  3052  3142 I zygote  : Waiting for a blocking GC Alloc
09-22 13:53:22.103  3052  3127 I zygote  : Waiting for a blocking GC Alloc
09-22 13:53:22.103  3052  3061 I zygote  : Waiting for a blocking GC Alloc
09-22 13:53:22.103  3052  3806 I zygote  : Waiting for a blocking GC Alloc
09-22 13:53:22.103  3052  5107 I zygote  : Waiting for a blocking GC Alloc
09-22 13:53:22.557  3052  4168 I zygote  : Clamp target GC heap from 535MB to 512MB
09-22 13:53:22.557  3052  4168 I zygote  : Alloc concurrent copying GC freed 0(0B) AllocSpace objects, 0(0B) LOS objects, 0% free, 511MB/512MB, paused 131us total 453.636ms
09-22 13:53:22.557  3052  3127 I zygote  : WaitForGcToComplete blocked Alloc on HeapTrim for 1.451s
09-22 13:53:22.557  3052  3127 I zygote  : Starting a blocking GC Alloc
09-22 13:53:22.557  3052  3142 I zygote  : WaitForGcToComplete blocked Alloc on HeapTrim for 454.347ms
09-22 13:53:22.558  3052  3142 I zygote  : Starting a blocking GC Alloc
09-22 13:53:22.558  3052  3061 I zygote  : WaitForGcToComplete blocked Alloc on HeapTrim for 2.941s
09-22 13:53:22.558  3052  3061 I zygote  : Starting a blocking GC Alloc
09-22 13:53:22.558  3052  3061 I zygote  : Starting a blocking GC Alloc
09-22 13:53:22.558  3052  3806 I zygote  : Waiting for a blocking GC Alloc
09-22 13:53:22.558  3052  5107 I zygote  : Waiting for a blocking GC Alloc
09-22 13:53:22.558  3052  4168 I zygote  : Waiting for a blocking GC Alloc
09-22 13:53:22.558  3052  3142 I zygote  : Waiting for a blocking GC Alloc
09-22 13:53:22.558  3052  3127 I zygote  : Waiting for a blocking GC Alloc
09-22 13:53:23.032  3052  3061 I zygote  : Clamp target GC heap from 535MB to 512MB
09-22 13:53:23.032  3052  3061 I zygote  : Alloc concurrent copying GC freed 23(552B) AllocSpace objects, 0(0B) LOS objects, 0% free, 511MB/512MB, paused 120us total 474.598ms
09-22 13:53:23.033  3052  3806 I zygote  : WaitForGcToComplete blocked Alloc on HeapTrim for 2.804s
09-22 13:53:23.033  3052  3806 I zygote  : Starting a blocking GC Alloc

  • 日志片段2：已经无法再分配新的内存空间

09-22 13:53:30.408  3052  3142 W System.err: java.lang.RuntimeException: Exception while computing database live data.
09-22 13:53:30.409  3052  3142 W System.err:     at androidx.room.RoomTrackingLiveData$1.run(RoomTrackingLiveData.java:92)
09-22 13:53:30.409  3052  3142 W System.err:     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
09-22 13:53:30.409  3052  3142 W System.err:     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
09-22 13:53:30.409  3052  3142 W System.err:     at java.lang.Thread.run(Thread.java:764)
09-22 13:53:30.409  3052  3142 W System.err: Caused by: android.database.sqlite.SQLiteException: unknown error (code 0): Native could not create new byte[]
09-22 13:53:30.409  3052  3142 W System.err:     at android.database.CursorWindow.nativeGetBlob(Native Method)
09-22 13:53:30.410  3052  3142 W System.err:     at android.database.CursorWindow.getBlob(CursorWindow.java:403)
09-22 13:53:30.410  3052  3142 W System.err:     at android.database.AbstractWindowedCursor.getBlob(AbstractWindowedCursor.java:45)
09-22 13:53:30.410  3052  3142 W System.err:     at com.decard.facediscernoffline.module_base_offline.bean.db.FaceDataDao_Impl$10.call(FaceDataDao_Impl.java:1032)
09-22 13:53:30.410  3052  3142 W System.err:     at com.decard.facediscernoffline.module_base_offline.bean.db.FaceDataDao_Impl$10.call(FaceDataDao_Impl.java:1016)
09-22 13:53:30.410  3052  3142 W System.err:     at androidx.room.RoomTrackingLiveData$1.run(RoomTrackingLiveData.java:90)
09-22 13:53:30.410  3052  3142 W System.err:     ... 3 more

原因分析：

  • 1，查询此设备的DVM分配的heap上限

adb shell getprop | grep heap  

[dalvik.vm.heapsize]: [512m]

  • 2，重复复现步骤，抓取内存申请快照hprof文件

adb shell am dumpheap com.xxx.xxx  /data/local/tmp/14_54.hprof

hprof-conv 14_54.hprof 14_54_R.hprof  

hprof-conv在sdk的platform-tools目录中

 

  • 3，使用Memory Analyzer Tool进行分析

打开14_54_R.hprof 文件后，

竟然有多个activity实例，基本断定是发生了上下文的强引用导致Activity无法被回收。

 

  • 4，点击右键Paths to GC Roots-->exclude all phantom/weak/soft etc reference

发现引用的代码位置，进行排查，发现使用的都是activity的context。

解决方案：

重构代码，把需要引用上下文对象的类，都用ApplicationContext 来代替。

 

参考博客

https://blog.csdn.net/zxm317122667/article/details/52162764?utm_medium=distribute.pc_relevant_ask_down.none-task-blog-baidujs-1.nonecase&depth_1-utm_source=distribute.pc_relevant_ask_down.none-task-blog-baidujs-1.nonecase

lucky_tom
关注
  • 4
    点赞
  • 踩
  • 15
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Android ANR的trace文件基本信息解读
郑海波(莫川)的CSDN博客
07-12 5375
Android ANR的trace文件基本信息解读
应用内存泄露问题分析实例
hehui1860的专栏
09-05 3万+
内存泄露，这个应用开发中比较容易出现的问题，由于短时间内难以测出来一般都比较难以发现，只能靠开发者的警觉性来避免，长时间的Monkey测试就成为一个可行的手段。 Monkey测试能给出一个直观的内存变化曲线和日志，GC日志在内存紧张时都会打印出测试进程的内存信息，需要结合几个方面的数据才能定位到问题的准确位置。
Android Framework开发系统问题分析
allen_xu_2012_new的博客
05-10 581
造成GC压力过大，Finalize对象累积太多，导致FinalizerDaemon线程来不及处理。ANR即（application not responding），即应用无响应，程序会弹出一个dialog提示用户程序无响应，而这对于用户体验无疑是很不好的。原文链接：https://blog.csdn.net/u010871962/article/details/109857386。不必要的对象创建造成GC压力过大，Finalize对象累积太多，导致FinalizerDaemon线程来不及处理。
Android日志：Background concurrent mark compact GC freed xxx(xxMB) AllocSpace objects, 0(0B) LOS object
最新发布
Zhang Phil
05-24 418
android8.0后，Bitmap从Java层转移到native层，此举虽然缓解了JVM的内存压力，也提升了图形的加载速度，但不恰当的Bitmap分配/释放逻辑，将导致内存问题深藏到native层，更加隐蔽不易排查定位。Android Activity / Fragment内存泄露引论Android发生OOM（OutOfMemoryError）问题的重要因素是编程设计不佳的代码出现内存泄露（Leak）造成Android分配的内存紧张。
记一次Android OOM问题
z9722的博客
04-02 6486
问题背景： 新平台固件测试后，反馈一个OOM的问题。问题日志如下： 3944 3959 I: Clamp target GC heap from 280MB to 256MB 3944 3959 I: Alloc concurrent copying GC freed 0(0B) AllocSpace objects, 0(0B) LOS objects, 0% free, 256MB/256MB, paused 173us total 383.632ms 3944 3944 I: WaitFo
Android系统问题及日志分析
gqg_guan的博客
04-03 4703
android 系统问题及日志分析
W/System: A resource failed to call close. ******: Waiting for a blocking GC ProfileSaverFlattened
PeaceZhy的博客
08-23 4595
Android运行好好的突然报错 W/System: A resource failed to call close. ******: Waiting for a blocking GC ProfileSaver Flattened final assist data: 176 bytes, containing 1 windows, 1 views
android 18 footjob,Android 8/9 default trust manager: OOM when getting "https://icloud.com"
热门推荐
weixin_39927508的博客
05-28 27万+
When using okhttp (which uses the platform default custom manager, which seems to be provided by Conscrypt) to GET (or PROPFIND) https://icloud.com (without www) with code like that:// compileSdkVersi...
第一次脚本监测内存泄露记录
12-22
测试某C++产品B，对发布的API自己写代码封装，每个API循环10000次，查看客户端的程序以及Server端的服务器进程是否有内存泄露。对于某个API C 循环9999999次的时候，在Window Task Manager看到内存不断在增长： ...
一次 Java 内存泄漏的排查解决过程详解
08-25
本文将详细介绍一次 Java 内存泄漏的排查解决过程，通过示例代码和实际案例，帮助读者更好地理解和排查 Java 内存泄漏。 一、问题描述 在本次值班中，我们的探测服务突然出现了大量的超时报警邮件，多数执行栈都在...
记一次django内存异常排查及解决方法
09-16
本文作者分享了一次处理此类问题的经验。 首先，当遇到Django应用的内存问题时，我们需要了解内存异常的一般来源。通常，内存异常是由于代码中存在内存泄漏、过度使用内存或数据结构管理不当造成的。在Python中，...
一次关于Redis内存诡异增长的排查过程实战记录
09-09
在本文中，我们将深入探讨一次关于Redis内存异常增长的排查过程。这通常是一个棘手的问题，因为内存管理是Redis性能的关键因素。通过这次实战记录，我们可以了解到如何分析和解决此类问题。 首先，我们关注到的现象...
windows 内存泄漏检查
05-26
内存泄漏是指程序在申请内存后，无法释放已申请的内存空间，一次小的内存泄漏可能看似无害，但如果长时间运行或频繁发生，就可能导致严重的性能问题。 在C++中，`malloc`和`free`是基本的动态内存分配和释放函数，...
Background sticky concurrent mark sweep GC freed 842(58KB) AllocSpace objects
鲁迷那的专栏—坚持实践后再写出来！
05-01 1万+
Background sticky concurrent mark sweep GC freed 842(58KB) AllocSpace objects, 5(11MB) LOS objects, 14% free, 44MB/51MB, paused 6.929ms total 45.948ms 参考博文 https://blog.csdn.net/dipolar/article/d...
Android优化
黑夜的触手
12-25 494
一、布局优化 布局优化就是删除布局中无用的控件和层级，可以用Hierarchy Viewer工具来检测，其次有选择地使用性能较低的ViewGroup。 include标签 include标签只支持以android:layout开头的属性，比如android:layout_width;android:layout_height等，其他属性不支持，比如android:back...
ThreadLocal中的内存泄露问题：
08-30
在ThreadLocal中，内存泄露问题通常是由于没有正确地清理ThreadLocal对象造成的。当一个线程调用ThreadLocal的set方法设置变量时，当前线程的ThreadLocalMap里面就会存放一个Entry对象，这个记录的key为ThreadLocal的引用，value则为设置的值。如果当前线程一直存在而没有调用ThreadLocal的remove方法，并且这时候其它地方还是有对ThreadLocal的引用，则当前线程的ThreadLocalMap变量里面会存在ThreadLocal变量的引用和value对象的引用是不会被释放的，这就会造成内存泄露的。即使ThreadLocal变量没有了其他强依赖，而当前线程还存在，由于线程的ThreadLocalMap里面的key是弱依赖，那么在垃圾回收时，当前线程的ThreadLocalMap里面的ThreadLocal变量的弱引用会被回收，但是对应的value还是会造成内存泄露。因此，在使用ThreadLocal时，需要确保及时调用remove方法来清理ThreadLocal引用，以避免内存泄露的问题。另外，使用线程池的情况下，使用完ThreadLocal一定要使用remove方法即时清理，因为ThreadLocal是属于某个线程的，而在使用线程池的情况下，这些线程都是可重复利用、存活时间长的线程，如果在使用过程中不及时remove，就会造成内存泄露的问题，并且可能引发一些功能逻辑问题，比如多个请求可能获取到了线程池中同一个线程的ThreadLocal值。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* *2* [ThreadLocal的内存泄露问题](https://blog.csdn.net/sunao1106/article/details/127133911)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 50%"] - *3* [记一次ThreadLocal引发的内存泄露](https://blog.csdn.net/kshzhaohui/article/details/111244981)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 50%"] [ .reference_list ]
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值