我有一个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]是否应该显式调用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