当前位置: 首页 > 知识库问答 >
问题:

Android在不调用system.gc的情况下明确释放内存

吴鸿禧
2023-03-14

我有一个Android应用程序,在其中我有一个下面的类,其中包含用JNI包装的本机(C++)对象和其他java对象的字段:

class MyClass
{
     Node nativeNode;  // containing Native objects wrapped using NDK and JNI
     long otherVars;   // some java instances
     public void dispose()
     {
         freeNativeNode();
     } 
}

在我的应用程序中,我不断地创建MyClass的实例

for(int i=0;i<1000;i++)
{
     MyClass obj = new MyClass();
     ...
     obj.freeNativeNode();           // Here, free native resources (A)
     //System.gc();                 // Here explicitly collect memory (B) 
}

当i大于某个数字时,例如当i>400或i>450时,应用程序崩溃。由于我已经像上面的(A)行一样显式地释放了本机内存,所以我认为应该不会有内存泄漏,并且java应该使用垃圾收集来撤销内存。但应用程序崩溃了,我怀疑这可能是内存泄漏的问题。

据我所知,可以通过调用以下命令来释放Java中的托管内存:

System.GC();

我试着在上面的(B)中调用它,然而,应用程序崩溃的频率更高,并且说当我超过60时,它已经崩溃了。

我的问题是:

[1]是否应该显式调用System.gc()?因为许多人对自己这样称呼有不同的意见,有些人说这不是一个好的做法。

[2]如何优雅地释放循环中的内存以避免崩溃?

pid: 31725, tid: 31725, name: com.cityu.scm  >>> com.cityu.scm <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000003

r0 000ff7ff  r1 ffffffff  r2 00000000  r3 ffffffff
r4 00000110  r5 553b36f8  r6 00000008  r7 00000000
r8 00000000  r9 48ce1c44  sl 40c5b020  fp bec7761c
ip 00000110  sp bec76db0  lr 400491b7  pc 400497b6  cpsr a0000030
d0  0000000000000008  d1  3ddb7cdfd9d7bdbb
d2  3fece61cf8e1788d  d3  4435800000000000
d4  000002d0000002d6  d5  0000000042000000
d6  44340000435f0000  d7  0000000040000000
d8  00000000440a8000  d9  0000000000000000
d10 0000000000000000  d11 0000000000000000
d12 0000000000000000  d13 0000000000000000
d14 0000000000000000  d15 0000000000000000
d16 0000000000000000  d17 0000000000000001
d18 0000000000000000  d19 3ff0000000000000
d20 0000000000000000  d21 0000000000000000
d22 0000000000000000  d23 0000000000000000
d24 3ff0000000000000  d25 3ff0000000000000
d26 0000000000000000  d27 c053000000000000
d28 0000000000000006  d29 3ff0000000000000
d30 3ff0000000000000  d31 3ff0000000000000
scr 20000011

backtrace:

#00  pc 000147b6  /system/lib/libc.so (dlmalloc+1589)
#01  pc 00017123  /system/lib/libc.so (malloc+10)
#02  pc 003774fc  /data/data/com.cityu.scm/lib/libjniosg.so (operator new(unsigned int)+24)

stack:

     bec76d70  5516df70 
     bec76d74  bec77608  [stack]
     bec76d78  48ce1c44 
     bec76d7c  40c5b020 
     bec76d80  c0000000 
     bec76d84  0000001b 
     bec76d88  0000000e 
     bec76d8c  003ef75c 
     bec76d90  0000000e 
     bec76d94  bec77310  [stack]
     bec76d98  c0000000 
     bec76d9c  00000108 
     bec76da0  00000000 
     bec76da4  003ef75c 
     bec76da8  df0027ad 
     bec76dac  00000000 
#00  bec76db0  524af370 
     bec76db4  53dc0677  /data/data/com.cityu.scm/lib/libjniosg.so
     bec76db8  00000000 
     bec76dbc  53dc0b15  /data/data/com.cityu.scm/lib/libjniosg.so 
#01  bec76de8  53cbd8ad  /data/data/com.cityu.scm/lib/libjniosg.so
     bec76dec  53c09500  /data/data/com.cityu.scm/lib/libjniosg.so (operator new(unsigned int)+28)

#02  bec76df0  00000000 
     bec76df4  524af160 
     bec76df8  bec7724c  [stack]
     bec76dfc  53cbd8b7  /data/data/com.cityu.scm/lib/libjniosg.so
     bec76e00  00000000 
     bec76e04  53dc5af9  /data/data/com.cityu.scm/lib/libjniosg.so 
     bec76e08  bec76e34  [stack]
     bec76e0c  00000009 
     bec76e10  bec7724c  [stack]
     bec76e14  53c1a70b  /data/data/com.cityu.scm/lib/libjniosg.so 
     bec76e18  bec7724c  [stack]
     bec76e1c  bec77288  [stack]
     bec76e20  bec7724c  [stack]
     bec76e24  bec7724c  [stack]
     bec76e28  00000000 

     bec76e2c  53dc5c53  /data/data/com.cityu.scm/lib/libjniosg.so 
000ff7dc ffffffff ffffffff ffffffff ffffffff  ................
000ff7ec ffffffff ffffffff ffffffff ffffffff  ................
000ff7fc ffffffff ffffffff ffffffff ffffffff  ................
000ff80c ffffffff ffffffff ffffffff ffffffff  ................
000ff81c ffffffff ffffffff ffffffff ffffffff  ................

r5附近的内存:

553b36d8 00000000 00000000 53ffa940 553b3701  ........@..S.7;U
553b36e8 00000000 00000000 00000000 00000000  ................
553b36f8 00000000 00000111 553b15f0 553b0b68  ..........;Uh.;U
553b3708 ffffffff 00000000 524133b8 00000000  .........3AR....
553b3718 00000020 000000f1 552da1d0 552fd620   .........-U ./U

r9附近的内存:

48ce1c24 4cdbee30 4bc88be8 00000006 48ce1c5c  0..L...K....\..H
48ce1c34 5270279c 4bff8370 00000006 00000000  .'pRp..K........
48ce1c44 4390001d 48ce1c84 526f0310 4bff83a8  ...C...H..oR...K
48ce1c54 5270279c 00000000 48ce1c84 526f0308  .'pR.......H..oR
48ce1c64 4bc81c28 00000006 410ace98 48ce1cbc  (..K.......A...H

SL附近的内存:

40c5b000 00000000 00000000 00000000 00000453  ............S...
40c5b010 4cd06328 48ce1c44 4bff83a8 52486000  (c.LD..H...K.`HR
40c5b020 8b300dd1 00001d30 bec77730 00000000  ..0.0...0w......
40c5b030 bec77764 00000001 00000000 40791380  dw............y@
40c5b040 00000000 00000000 402e0570 48cdc300  ........p..@...H
bec775fc 54f4c024 4bff8370 407911f4 48ce1c44  $..Tp..K..y@D..H
bec7760c 00000001 4119d1f8 52722f8f 0000003b  .......A./rR;...
bec7761c 407c3c87 48ce1c44 52722f8d 53bc6a01  .<|@D..H./rR.j.S
bec7762c 40c5b020 a3a00019 00000000 4082c238   ..@........8..@
bec7763c 40085a98 00000022 40103033 40cdbb10  .Z.@"...30.@...@
bec76d90 0000000e bec77310 c0000000 00000108  .....s..........
bec76da0 00000000 003ef75c df0027ad 00000000  ....\.>..'......
bec76db0 524af370 53dc0677 00000000 53dc0b15  p.JRw..S.......S
bec76dc0 00000000 00000108 524af160 003ef75c  ........`.JR\.>.
bec76dd0 00000164 bec77608 48ce1c44 40c5b020  d....v..D..H ..@
40049794 0240f3c0 66a8f8df f102fa30 0c02eb03  ..@....f0.......
400497a4 0501eb0c eb06447e 25000085 312cf8d0  ....~D.....%..,1
400497b4 685ae00d f0226919 ebc40c03 4542020c  ..Zh.i".......BE
400497c4 4642bf2c b901461d 460b6959 2b004690  ,.BF.F..Yi.F.F.+
400497d4 2d00d1ef 818ff000 2668f8df 6890447a  ...-......h&zD.h
40049194 b930fd11 2becf8df f8d2447a 078b11b4  ..0....+zD......
400491a4 f8dfd50a 447d5be4 70dcf505 f7fe2500  .....[}D...p.%..
400491b4 2800e886 8249f041 f2002cf4 2c0a823f  ...(A.I..,..?..,
400491c4 340bd903 0407f024 2410e000 7bbcf8df  ...4$......$...{
400491d4 447f08e2 fa36683e 079df302 f003d042  ...D>h6.....B...

PID:31725,TID:31727,姓名:GC r0 fffffffc r1 00000080 r2 fffffffc r3 4FE62E30 r4 40CDBB0 r5 40CDBBAC r6 FFFFFFC r7 000000F0 r8 00001388 r9 00000000 sl 4082DF98 fp 00000001 ip 00000000 sp 4FE62E10 lr 40047F80 pc 40042CA4 cpsr 60000010 d0 42C80000428CEA01 d1 3FF00000003DB190 d2 000000010000000001 d3 b684088000080000 d4 0000000040DC8000 d5 000000000006E400 d6 00578FE000000963 d7 00000080000010

回溯:

#00  pc 0000dca4  /system/lib/libc.so (__futex_syscall3+12)
#01  pc 00012f7c  /system/lib/libc.so (__pthread_cond_timedwait_relative+48)
#02  pc 00012fd8  /system/lib/libc.so (__pthread_cond_timedwait+60)
#03  pc 00057029  /system/lib/libdvm.so (dvmRelativeCondWait(pthread_cond_t*, pthread_mutex_t*, long long, int)+112)

#04  pc 00078655  /system/lib/libdvm.so
#05  pc 000591e7  /system/lib/libdvm.so
#06  pc 00012e48  /system/lib/libc.so (__thread_entry+72)
#07  pc 0001257c  /system/lib/libc.so (pthread_create+208)

堆栈:

     4fe62dd0  01e9b4a6 
     4fe62dd4  7fffffff 
     4fe62dd8  01e9b50c 
     4fe62ddc  0004e200 
     4fe62de0  0000fa00 
     4fe62de4  40046314  /system/lib/libc.so (__divdi3+244)
     4fe62de8  01e9b517 
     4fe62dec  4082c238  /system/lib/libdvm.so
     4fe62df0  40cdbab0  [heap]
     4fe62df4  00000000 
     4fe62df8  4fe62e00 
     4fe62dfc  000003e8 
     4fe62e00  00000000 
     4fe62e04  00001388 
     4fe62e08  00000000 
     4fe62e0c  00001388 
#00  4fe62e10  40cdbbb0  [heap]
     4fe62e14  4fe62e30 
#01  4fe62e18  00000001 
     4fe62e1c  40cdbbac  [heap]
     4fe62e20  40cdbbb0  [heap]
     4fe62e24  40cdbbb0  [heap]
     4fe62e28  40cdbbac  [heap]
     4fe62e2c  40047fdc  /system/lib/libc.so (__pthread_cond_timedwait+64)

#02  4fe62e30  00000004 
     4fe62e34  3b9ac618 
     4fe62e38  4fe62e40 
     4fe62e3c  1c09ac61 
     4fe62e40  00007d62 
     4fe62e44  407ca02d  /system/lib/libdvm.so (dvmRelativeCondWait(pthread_cond_t*, pthread_mutex_t*, long long, int)+116)

#03  4fe62e48  00007d62 
     4fe62e4c  1c09ac61 
     4fe62e50  00001388 
     4fe62e54  407eb765  /system/lib/libdvm.so
     4fe62e58  4082df98 
     4fe62e5c  00000000 
     4fe62e60  00000001 
     4fe62e64  407cc19d  /system/lib/libdvm.so
     4fe62e68  00100000 
     4fe62e6c  407eb659  /system/lib/libdvm.so

#04  4fe62e70  00000000 
     4fe62e74  00000001 
     4fe62e78  00000001 
     4fe62e7c  00000000 
     4fe62e80  00000008 
     4fe62e84  40c725e0 
     4fe62e88  4082c238  /system/lib/libdvm.so
     4fe62e8c  bec77768  [stack]
     4fe62e90  00000078 
     4fe62e94  407cc19d  /system/lib/libdvm.so
     4fe62e98  00100000 
     4fe62e9c  40c725e0 
     4fe62ea0  00000001 
     4fe62ea4  407cc1e9  /system/lib/libdvm.so
#05  4fe62ea8  40c725e0 
     4fe62eac  00010002 
     4fe62eb0  40ccbc80 
     4fe62eb4  40cea080  /dev/ashmem/dalvik-heap (deleted)
     4fe62eb8  4fe62f00 
     4fe62ebc  40c725e0 
     4fe62ec0  407cc190  /system/lib/libdvm.so (dvmDetachCurrentThread()+763)
     4fe62ec4  40047e4c  /system/lib/libc.so (__thread_entry+76)
#06  4fe62ec8  00000000 
     4fe62ecc  00000000 
     4fe62ed0  00000000 
     4fe62ed4  00000000 
     4fe62ed8  00000000 
     4fe62edc  4fe62f00 
     4fe62ee0  40cce0a0 
     4fe62ee4  bec77770  [stack]
     4fe62ee8  00000078 
     4fe62eec  407cc19d  /system/lib/libdvm.so
     4fe62ef0  00100000 
     4fe62ef4  40c725e0 
     4fe62ef8  00000001 
     4fe62efc  40047580  /system/lib/libc.so (pthread_create+212)

#07  4fe62f00  4fe62f00 
     4fe62f04  40cce0a0 
     4fe62f08  00000000 
     4fe62f0c  00000000 
     4fe62f10  00000000 
     4fe62f14  00000000 
     4fe62f18  4e68a460 
     4fe62f1c  00000000 
     4fe62f20  00000000 
     4fe62f24  00000000 
     4fe62f28  00000000 
     4fe62f2c  00000000 
     4fe62f30  00000000 
     4fe62f34  00000000 
     4fe62f38  00000000 
     4fe62f3c  00000000 

PID:31725,TID:31729,名称:信号捕捉器

r0 fffffffc  r1 00000000  r2 00000000  r3 00000008
r4 4ff62e58  r5 40828261  r6 bec77778  r7 000000b1
r8 407cc19d  r9 52415800  sl 5010be38  fp 00042e74
ip 40827e6c  sp 4ff62e18  lr 4004f453  pc 40042554  cpsr 20000010
d0  42c800004266db5b  d1  3ff00000002aff38
d2  0000000100000001  d3  b684088000080000
d4  0000000040dc8000  d5  000000000006e400
d6  004a7ff000000963  d7  000000394d865d8f
d8  0000000000000000  d9  0000000000000000
d10 0000000000000000  d11 0000000000000000
d12 0000000000000000  d13 0000000000000000
d14 0000000000000000  d15 0000000000000000
d16 40d3000000000000  d17 40c3cc0000000000
d18 0033003200310030  d19 0000000000000000
d20 4008000000000000  d21 3fbc71c71c71c71c
d22 3fcc7288e957b53b  d23 3fd24998d6307188
d24 3fd99a27ad32ddf5  d25 3fe555b0aaeac752
d26 0000000000000000  d27 0000000000000000
d28 0000000000000005  d29 0000000000000000
d30 0000000000000000  d31 0000000000000000
scr 80000010

回溯:

#00  pc 0000d554  /system/lib/libc.so (__rt_sigtimedwait+12)
#01  pc 0001a44f  /system/lib/libc.so (sigwait+20)
#02  pc 00055fcf  /system/lib/libdvm.so
#03  pc 000591e7  /system/lib/libdvm.so
#04  pc 00012e48  /system/lib/libc.so (__thread_entry+72)
#05  pc 0001257c  /system/lib/libc.so (pthread_create+208)

堆栈:4FF62DD8 00000000 4FF62DDC 00000000 4FF62DE0 00000000 4FF62DE4 00000000 4FF62DE8 00000000 4FF62DE8 00000000 4FF62DF0 40827C88/System/Lib/libdvm.so 4FF62DF4 52415800 4FF62DF8 4BC64570/Dev/Ashmem/Dalvik-LinearAlloc(已删除)4FF62DFC 4FF62E78 4FF62E00 4FF62E00 4FF62E00 4FF62E04 40CBFFC4vik-heap(已删除)4FF62E54 00000204 4FF62E58 ffffffe0 4FF62E5C 52415800 4FF62E60 410A0EC8/dev/ashmem/dalvik-heap(已删除)4FF62E64 407CB485/system/libdvm.so(dvmAttachCurrentThread(JavaVMAttachArgs const*,bool)+452)4FF62E68 40cea080/dev/ashmem/dalvik-heap(已删除)4FF62E6C........#03 4FF62EA8 5010BE38 4FF62EAC 00010002 4FF62EB0 40C6D380 4FF62EB4 40CEA080/dev/ashmem/dalvik-堆(已删除)4FF62EB8 4FF62EBC 5010BE38 4FF62EBC 5010BE38 4FF62EBC 5010BE38 4FF62EBC 407CC190/System/lib/libdvm.so(dvmDetachCurrentThread()+763)4FF62EC4

#05  4ff62f00  4ff62f00 
     4ff62f04  40cce8f8 
     4ff62f08  00000000 
     4ff62f0c  00000000 
     4ff62f10  00000000 
     4ff62f14  00000000 
     4ff62f18  52415800 
     4ff62f1c  00000000 
     4ff62f20  00000000 
     4ff62f24  00000000 
     4ff62f28  00000000 
     4ff62f2c  00000000 
     4ff62f30  00000000 
     4ff62f34  00000000 
     4ff62f38  00000000 
     4ff62f3c  00000000 

PID:31725,TID:31730,名称:JDWP

r0 00000031  r1 50062de0  r2 00000000  r3 00000000
r4 00000000  r5 00000000  r6 00000000  r7 0000008e
r8 501011b0  r9 00000030  sl 0003b777  fp 00000001
ip 50062dc0  sp 50062db0  lr 407dad43  pc 40041cb4  cpsr 40000010

d0  42c800004266db5b  d1  3ff00000002aff38
d2  0000000100000001  d3  b684088000080000
d4  0000000040dc8000  d5  000000000006e400
d6  004a7ff000000963  d7  000000394d865d8f
d8  0000000000000000  d9  0000000000000000
d10 0000000000000000  d11 0000000000000000
d12 0000000000000000  d13 0000000000000000
d14 0000000000000000  d15 0000000000000000
d16 40d3000000000000  d17 40c3cc0000000000
d18 0033003200310030  d19 0000000000000000
d20 4008000000000000  d21 3fbc71c71c71c71c
d22 3fcc7288e957b53b  d23 3fd24998d6307188
d24 3fd99a27ad32ddf5  d25 3fe555b0aaeac752
d26 0000000000000000  d27 0000000000000000
d28 0000000000000005  d29 0000000000000000
d30 0000000000000000  d31 0000000000000000
scr 80000010

回溯:

#00  pc 0000ccb4  /system/lib/libc.so (select+16)
#01  pc 00067d3f  /system/lib/libdvm.so
#02  pc 0006acd1  /system/lib/libdvm.so
#03  pc 000591e7  /system/lib/libdvm.so
#04  pc 00012e48  /system/lib/libc.so (__thread_entry+72)
#05  pc 0001257c  /system/lib/libc.so (pthread_create+208)

共有1个答案

阎晗日
2023-03-14

[1]是否应该显式调用System.gc()?因为许多人对自己这样称呼有不同的意见,有些人说这不是一个好的做法。

大概不会吧。正如user3580294前面提到的,system.gc()实际上只是对VM的一个建议,当您直接调用该方法时,它的操作完全取决于实现。我绝不会使用这个函数来防止程序崩溃。

[2]如何优雅地释放循环中的内存以避免崩溃?究竟是什么在耗尽所有的内存?很明显,当MyClass被构建时,一些本地资源正在被创建...这些是JNI对象吗?它们是C分配的内存吗?

在这里,我将根据回溯来讨论一下,并指出消耗所有内存的对象是在C/C++中创建的JNI对象(可能是在一个单独的线程上),并传递回JVM。尝试对传递回VM的JNI对象调用DeleteLocalRef()。

同样,我的上述建议是基于大量的假设。您确实需要将一个内存探查器(如jvisualvm)附加到JVM上,以便确切地看到什么正在消耗所有内存,然后确定GC为什么没有捕获到它。(提示:大概还是有参考的)

 类似资料:
  • 问题内容: 我正在开发一个文档测试框架-基本上是PDF的单元测试。测试是框架定义的类的实例的(修饰)方法,并且在运行时定位并实例化这些实例,并调用这些方法以执行测试。 我的目标是减少将要编写测试的人员所关心的古怪的Python语法,因为这些人可能是也可能不是Python程序员,甚至根本不是很多程序员。因此,我希望他们能够为方法编写“ def foo():”而不是“ def foo(self):”,

  • 到目前为止,我运行的是一台视窗8.1电脑,它没有像Android Studio或Eclipse这样的IDE的存储或内存。我想下载Android SDK工具,没有IDE。如何才能做到这一点?

  • 我想使用try with resource来切换上下文,但try()似乎无法在不声明变量的情况下使用资源,这使得代码不那么优雅。例如 和用法: 但是我在try()上得到了Syntext错误。只有当我这样写的时候:它通过编译。最优雅的方法是什么? 最新消息 因为在一些答案中,人们不明白我想做什么,所以我会尝试更好地解释。我试图以一种更优雅的方式实现以下逻辑:

  • 问题内容: 如果要使用Linq-SQL,还必须将DB Table拖到设计器表面以创建实体类。 我一直喜欢我的应用程序中的完全控制权,并且不喜欢dotnet创建的类。 是否可以使用我自己的数据访问层实体类在Linq和DB之间提供此连接? 我该如何完成? 问题答案: 您可以使用Linq-to-SQL非常轻松地编写自己的类-只需使用一些属性绘制类即可。 例如,这是我的一个项目中有一个非常简单的表,它可以

  • 我有一个带有按钮的简单页面,当按下时,使用异步剪贴板API写入剪贴板。 这适用于Chrome和Firefox、桌面和移动设备。但是在Android Webview上,它会抛出以下错误: 我想我需要重写来授予权限,但是奇怪的是似乎没有被调用,并且仍然抛出相同的错误。 我仍然得到同样的错误: Logcat也没有记录任何信息。 我怀疑可能我的Android应用程序需要额外的权限才能访问剪贴板,但根据ht