堆栈内存溢出
  简体   繁体   English

Android显式释放内存，而无需调用System.GC

[英]Android explictly free memory without calling System.GC

 原文  2014-05-04 03:07:35  1   1    java/ c++/ android-ndk/ garbage-collection/ java-native-interface

问题描述

I have an Android App, in which I have below class containing fields of both native (C++) objects wrapped with JNI, and other java objects: 我有一个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();
     } 
}

In my app, I continuously create instances of MyClass: 在我的应用程序中，我不断创建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) 
}

The app crashes when i is bigger than some number, eg when i>400 or i>450. 当我大于某个数字时，例如当i> 400或i> 450时，应用程序崩溃。 Since I have freed the native memory explicitly as in line (A) above, so I think there should be no memory leak, and java shall use garbage collection to revoke the memory. 由于我已经按照上面的（A）行显式释放了本机内存，因此我认为应该没有内存泄漏，并且Java将使用垃圾回收来撤消内存。 But the app crashes, and I suspect it might be a memory leak problem. 但是该应用程序崩溃了，我怀疑这可能是内存泄漏问题。

As I know, it is possible to free the managed memory in Java by calling: 据我所知，可以通过调用以下命令来释放Java中的托管内存： 

System.GC();

I tried to call this in (B) above, however, the app crashes more often, and say when i > 60, it already crashes. 我尝试在上面的（B）中调用它，但是该应用程序崩溃的频率更高，并且说当我> 60时，它已经崩溃了。

My questions are: 我的问题是：

[1] Should I call System.GC() explicitly? [1]我应该显式调用System.GC（）吗？ As many have different opinions on calling this ourselves, and some say this is not a good practice. 由于许多人对自己称呼它有不同的意见，有人说这不是一个好习惯。

[2] How do I elegantly free the memory in the loop to avoid crash? [2]如何优雅地释放循环中的内存以避免崩溃？

Edit: I understand it is less appropriate to print full log here, but it might be useful to get the whole picture for troubleshooting the problem. 编辑：我知道在这里打印完整日志不太合适，但是获取整个图片以解决问题可能很有用。

From the log, it seems to be not a memory leak problem, but one of my colleague believes so, and I have no strong evidence showing this is NOT, :) 从日志来看，这似乎不是内存泄漏问题，但是我的一位同事认为如此，并且我没有有力的证据表明这不是，:)

The tombstone log: debuggerd: 2014-05-01 23:56:47 墓碑日志：debuggerd：2014-05-01 23:56:47

Build fingerprint: 'htc_asia_hk/endeavoru/endeavoru:4.1.1/JRO03C/128187.28:user/release-keys' 构建指纹：'htc_asia_hk / endeavoru / endeavoru：4.1.1 / JRO03C / 128187.28：user / release-keys' 

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 >, std::_Select1st > >, std::less, std::allocator > > >::find(std::string const&)+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) （std :: _ Rb_tree>，std :: _ Select1st>>，std :: less，std :: allocator>>> :: find（std :: string const＆）+ 58）bec76dc0 00000000 bec76dc4 00000108 bec76dc8 524af160 bec76dcc 003ef75c bec76dd0 400000 bec77608 [堆栈] bec76dd8 48ce1c44 bec76ddc 40c5b020 bec76de0 bec7761c [堆栈] 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&, unsigned int, osg::Object*)+80) （osgDB :: InputStream :: readObjectFields（std :: string const＆，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&)+14) （BinaryInputIterator :: readUInt（unsigned int＆）+ 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::Object*)+114) （osgDB :: InputStream :: readObject（osg :: Object *）+ 114）

memory near r0: 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  ................

memory near r5: 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

memory near r9: 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

memory near sl: 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

memory near fp: 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.@...@

memory near sp: sp附近的内存： 

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 ..@

code around pc: 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

code around lr: 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, name: 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 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 ip0000000000 l 4cad10c0r1 0a00r80a001 0a0020a1 0a0020a1 0a0020a1 0b00r80a1 0a0020a1 0a0020a1a00c00a1a 0b0020a1a00a001a 000001a ip0000000028a1 0a0020a1a 0b0020a1a1a 00000001 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 41392000亿D17 4132d9f000000000 D18 0033003200310030 D19 0000000000000000 D20 40080000亿D21 3fbc71c71c71c71c D22 3fcc7288e957b53b D23 3fd24998d6307188 D24 3fd99a27ad32ddf5 D25 3fe555b0aaeac752 D26 0000000000000000 D27 0000000000000000 d28 0000000000000005 d29 0000000000000000 d30 0000000000000000 d31 0000000000000000 scr 80000010

backtrace: 回溯： 

#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)

stack: 堆： 

     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, name: Signal Catcher 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

backtrace: 回溯： 

#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)

stack: 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 (deleted) 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 (deleted) 4ff62e38 4bc64570 /dev/ashmem/dalvik-LinearAlloc (deleted) 4ff62e3c 40003310 4ff62e40 52415b6c 4ff62e44 407c88ef /system/lib/libdvm.so (dvmRemoveFromReferenceTable(ReferenceTable*, Object**, Object*)+30) 4ff62e48 52415800 4ff62e4c 00042e8a 4ff62e50 410a0ec8 /dev/ashmem/dal 堆栈：4ff62dd8 00000000 00000000 4ff62ddc 00000000 4ff62de0 00000000 4ff62de4 00000000 4ff62de8 00000000 4ff62dec 4ff62df0 40827c88 /system/lib/libdvm.so 4ff62df4 52415800 4ff62df8 4bc64570的/ dev / ashmem /达尔维克LinearAlloc（删除）4ff62dfc 4ff62e78 4ff62e00 4ff62e78 4ff62e04 40cbffc4 4ff62e08 4ce76760 /系统/ 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 4ff62 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 / dalff-heb4570（delet） / dalvik-LinearAlloc（已删除）4ff62e3c 40003310 4ff62e40 52415b6c 4ff62e44 407c88ef /system/lib/libdvm.so（dvmRemoveFromReferenceTable（ReferenceTable *，Object **，Object *）+ 30）4ff62e48 52415800 4ff62e4c 00042e8a410 vik-heap (deleted) 4ff62e54 00000204 4ff62e58 ffffffe0 4ff62e5c 52415800 4ff62e60 410a0ec8 /dev/ashmem/dalvik-heap (deleted) 4ff62e64 407cb485 /system/lib/libdvm.so (dvmAttachCurrentThread(JavaVMAttachArgs const*, bool)+452) 4ff62e68 40cea080 /dev/ashmem/dalvik-heap (deleted) 4ff62e6c 410a0ec8 /dev/ashmem/dalvik-heap (deleted) ........ ........ #03 4ff62ea8 5010be38 4ff62eac 00010002 4ff62eb0 40c6d380 4ff62eb4 40cea080 /dev/ashmem/dalvik-heap (deleted) 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 [stack] 4ff62ee8 00000078 4ff62eec 407cc19d /system/lib/libdvm.so 4ff62ef0 00100000 4ff62ef4 5010be38 4ff62ef8 00000001 4ff62efc 40047580 /system/lib/libc.so (pthread_create+212) vik-heap（已删除）4ff62e54 00000204 4ff62e58 ffffffe0 4ff62e5c 52415800 4ff62e60 410a0ec8 / dev / ashmem / dalvik-heap（已删除）4ff62e64 407cb485 /system/lib/libdvm.so（dvmAttachCurrentThread（dvmAttachCurrentThread）（JavaVM）（4） 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 + ec8 000 4） 4ff62ecc 00000000 4ff62ed0 00000000 4ff62ed4 00000000 4ff62ed8 00000000 4ff62edc 4ff62f00 4ff62ee0 40cce8f8 4ff62ee4 bec77780 [stack] 4ff62ee8 00000078 4ff62eec 407cc19d /system/lib/libdlib.vm 4so54ff62ef0 4001（4ff62ef04 00100000） 

#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, name: JDWP 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

backtrace: 回溯： 

#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 个解决方案

解决方案1
 0  2014-05-05 17:23:11

[1] Should I call System.GC() explicitly? [1]我应该显式调用System.GC（）吗？ As many have different opinions on calling this ourselves, and some say this is not a good practice. 由于许多人对自己称呼它有不同的意见，有人说这不是一个好习惯。

Probably not. 可能不是。 As previously mentioned by user3580294, System.GC() is really only a suggestion to the VM and what it does when you call that method directly is totally up to the implementation. 如user3580294先前所述，System.GC（）实际上仅是对VM的建议，当您直接调用该方法时，它的作用完全取决于实现。 I would never use this function to prevent a program from crashing. 我永远不会使用此功能来防止程序崩溃。

[2] How do I elegantly free the memory in the loop to avoid crash? [2]如何优雅地释放循环中的内存以避免崩溃？ What exactly is using up all the memory? 究竟用尽了所有内存？ Clearly when MyClass is constructed some native resouces are being created... Are these JNI objects? 显然，在构造MyClass时，正在创建一些本机资源...这些JNI对象吗？ Are they C alloced memory? 它们是C分配的内存吗？

I am going to go out on a limb here based on the backtrace and say that the objects eating up all your memory are JNI objects that were created in C/C++ (probably on a separate thread) and passed back to the JVM. 我将根据回溯来分析一下，说占用所有内存的对象是在C / C ++中创建的JNI对象（可能在单独的线程上），然后传递回JVM。 Try calling DeleteLocalRef() on the JNI object(s) that are passed back to the VM. 尝试在传递回VM的JNI对象上调用DeleteLocalRef（）。

Again, my above suggestion is based on a lot of assumption. 同样，我的上述建议基于很多假设。 You really need to attach a memory profiler like jvisualvm to the JVM to see exactly what is using up all the memory and then determine why the GC didn't catch it. 您确实需要将诸如jvisualvm的内存分析器附加到JVM，以查看确切的内存消耗了所有内存，然后确定为什么GC无法捕获它。 (Hint: there is probably still a reference to it) （提示：可能仍然有引用）

暂无
暂无

声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 如何在不调用System.gc（）的情况下优化内存 - How to optimize memory without calling System.gc(); 显式调用System.gc（）？ - Calling System.gc( ) explicitly? 在手机中调用System.gc（） - Calling System.gc() in mobile 调用`System.gc（）`是一种在Java应用程序中管理内存的好方法吗？ - Is calling `System.gc()` a good way to manage memory in a Java application? Java System.GC（）和内存泄漏 - Java System.GC() and Memory Leakage 在Android中，不应该使用System.gc（）吗？ - In Android, Should not be use System.gc()? System.gc将在android（Andengine）中工作 - System.gc will work in android(Andengine) 调用System.gc（）与系统杀死的进程之间的区别 - difference between calling System.gc() and process killed by system System.gc问题 - System.gc problem 调用System.gc（）后，WeakReferenced对象不是垃圾回收 - WeakReferenced object is not garbage collected after calling System.gc()
相关标签
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM