我有一个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> 400或i> 450时。 因为我已经像上面的行（A）那样明确地释放了本机内存，所以我认为应该没有内存泄漏，并且java应该使用垃圾收集来撤销内存。但应用程序崩溃，我怀疑它可能是内存泄漏问题。
据我所知，可以通过调用：
来释放Java中的托管内存System.GC();
我尝试在上面的（B）中调用它，然而，应用程序更频繁地崩溃，并说当我＆gt; 60，它已经崩溃。
我的问题是：
[1]我应该明确地调用System.GC（）吗？很多人对自己打电话有不同意见，有人说这不是一个好习惯。
[2]如何优雅地释放循环中的内存以避免崩溃？
编辑：我知道在这里打印完整日志不太合适，但是为了解决问题需要全面了解。
从日志中看，它似乎不是内存泄漏问题，但我的一位同事认为如此，而且我没有强有力的证据表明这不是，:)
墓碑日志：debuggerd：2014-05-01 23:56:47
构建指纹：＆＃39; htc_asia_hk / endeavoru / endeavoru：4.1.1 / JRO03C / 128187.28：user / release-keys＆＃39;
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
（std :: _ Rb_tree＆gt;，std :: _ Select1st＆gt;＆gt;，std :: less，std :: allocator＆gt;＆gt;＆gt; :: find（std :: string const＆amp;）+ 58） bec76dc0 00000000 bec76dc4 00000108 bec76dc8 524af160 bec76dcc 003ef75c bec76dd0 00000164 bec76dd4 bec77608 [stack] bec76dd8 48ce1c44 bec76ddc 40c5b020 bec76de0 bec7761c [stack] bec76de4 4004c125 /system/lib/libc.so（malloc + 12）
#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
（osgDB :: InputStream :: readObjectFields（std :: string const＆amp;，unsigned int，osg :: Object *）+ 80）
bec76e08 bec76e34 [stack]
bec76e0c 00000009
bec76e10 bec7724c [stack]
bec76e14 53c1a70b /data/data/com.cityu.scm/lib/libjniosg.so
（BinaryInputIterator :: readUInt（unsigned int＆amp;）+ 14）
bec76e18 bec7724c [stack]
bec76e1c bec77288 [stack]
bec76e20 bec7724c [stack]
bec76e24 bec7724c [stack]
bec76e28 00000000
bec76e2c 53dc5c53 /data/data/com.cityu.scm/lib/libjniosg.so
（osgDB ::的InputStream ::的readObject（OSG ::对象*）+ 114）
记录在r0附近：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 ................
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
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
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
fp附近的记忆：
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 ..@
pc周围的代码：
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
围绕lr的代码：
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 40cdbbb0 r5 40cdbbac r6 fffffffc 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 0000000100000001 d3 b684088000080000 d4 0000000040dc8000 d5 000000000006e400 d6 00578fe000000963 d7 000000464dc0cae2 d8 0000000000000000 d9 0000000000000000 d10 0000000000000000 d11 0000000000000000 d12 0000000000000000 d13 0000000000000000 d14 0000000000000000 d15 0000000000000000 d16 4139200000000000 d17 4132d9f000000000 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 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，姓名：Signal Catcher
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 4ff62dec 00000000 4ff62df0 40827c88 /system/lib/libdvm.so 4ff62df4 52415800 4ff62df8 4bc64570 / dev / ashmem / dalvik-LinearAlloc（已删除） 4ff62dfc 4ff62e78 4ff62e00 4ff62e78 4ff62e04 40cbffc4 4ff62e08 4ce76760 /system/framework/core.odex 4ff62e0c 4ff62e78 4ff62e10 00000000 4ff62e14 407d9c21 /system/lib/libdvm.so(dvmCallMethodV（Thread *，Method const *，Object *，bool，JValue *，std :: __ va_list）+276） ＃00 4ff62e18 4ff62e58 4ff62e1c 40811cfc /system/lib/libdvm.so ＃01 4ff62e20 00000204 4ff62e24 00000000 4ff62e28 5010be38 4ff62e2c 407c8fd3 /system/lib/libdvm.so ＃02 4ff62e30 00000001 4ff62e34 40cea080 / dev / ashmem / dalvik-heap（已删除） 4ff62e38 4bc64570 / dev / ashmem / dalvik-LinearAlloc（已删除） 4ff62e3c 40003310 4ff62e40 52415b6c 4ff62e44 407c88ef /system/lib/libdvm.so(dvmRemoveFromReferenceTable（ReferenceTable *，Object **，Object *）+ 30） 4ff62e48 52415800 4ff62e4c 00042e8a 4ff62e50 410a0ec8 / dev / ashmem / dalvik-heap（已删除） 4ff62e54 00000204 4ff62e58 ffffffe0 4ff62e5c 52415800 4ff62e60 410a0ec8 / dev / ashmem / dalvik-heap（已删除） 4ff62e64 407cb485 /system/lib/libdvm.so(dvmAttachCurrentThread（JavaVMAttachArgs const *，bool）+452） 4ff62e68 40cea080 / dev / ashmem / dalvik-heap（已删除） 4ff62e6c 410a0ec8 / dev / ashmem / dalvik-heap（已删除） ........ ........ ＃03 4ff62ea8 5010be38 4ff62eac 00010002 4ff62eb0 40c6d380 4ff62eb4 40cea080 / dev / ashmem / dalvik-heap（已删除） 4ff62eb8 4ff62f00 4ff62ebc 5010be38 4ff62ec0 407cc190 /system/lib/libdvm.so(dvmDetachCurrentThread（）+ 763） 4ff62ec4 40047e4c /system/lib/libc.so(__thread_entry + 76） ＃04 4ff62ec8 00000000 4ff62ecc 00000000 4ff62ed0 00000000 4ff62ed4 00000000 4ff62ed8 00000000 4ff62edc 4ff62f00 4ff62ee0 40cce8f8 4ff62ee4 bec77780 [堆栈] 4ff62ee8 00000078 4ff62eec 407cc19d /system/lib/libdvm.so 4ff62ef0 00100000 4ff62ef4 5010be38 4ff62ef8 00000001 4ff62efc 40047580 /system/lib/libc.so(pthread_create + 212）
#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)
答案 0 :(得分：0)
[1]我应该明确地调用System.GC（）吗？因为许多人有所不同 关于自己打电话的意见，有人说这不是好事 实践。
可能不是。正如之前提到的user3580294，System.GC（）实际上只是对VM的建议，当你直接调用该方法时它的作用完全取决于实现。我永远不会使用此函数来防止程序崩溃。
[2]如何优雅地释放循环中的内存以避免崩溃？ 究竟是什么耗尽了所有的记忆？显然当MyClass是 构建了一些原生资源正在创建......这些是JNI 对象？他们是C分配内存吗？
我将在这里根据回溯进行讨论，并说占用所有内存的对象是在C / C ++中创建的JNI对象（可能在一个单独的线程上）并传递回JVM 。尝试在传递回VM的JNI对象上调用DeleteLocalRef（）。
同样，我的上述建议基于很多假设。你真的需要将一个像jvisualvm这样的内存分析器连接到JVM，以确切地查看所有内存耗尽的内容，然后确定GC没有捕获它的原因。 （提示：可能还有一个参考）