android debug的时候遇到的问题，该模式下无法自动垃圾回收无用对象吗

我在测试：在android 应用中循环多次读取大文件。android应用程序在没有debug的时候：我发现能够自动垃圾回收，可以完成循环。而通过debug模式：应用竟然没有释放无用的垃圾对象，内存不断增加，循环了几次就报错：（app bug）：globle reference table overflow（max 51200）。


麻烦哪位高手指导下，能否在debug模式下，也能垃圾回收，释放内存。

6 个解决方案

#1

这个是JNI代码的报错。
可能是因为你没有关闭doc？
垃圾回收只是内存的回收，但是并不能解决资源泄漏的问题。

#2

引用 1 楼 svenwang 的回复:

这个是JNI代码的报错。
可能是因为你没有关闭doc？
垃圾回收只是内存的回收，但是并不能解决资源泄漏的问题。

我是没有关闭document，怎么去关闭它呢，一般这个jni的报错是什么问题导致的呢？对比debug和普通run情况下，为什么会有差异呢？谢谢你了

#3

引用 2 楼 u014032607 的回复:

Quote: 引用 1 楼 svenwang 的回复:

这个是JNI代码的报错。
可能是因为你没有关闭doc？
垃圾回收只是内存的回收，但是并不能解决资源泄漏的问题。

我是没有关闭document，怎么去关闭它呢，一般这个jni的报错是什么问题导致的呢？对比debug和普通run情况下，为什么会有差异呢？谢谢你了

1.怎么关闭？有API文档说明你去看看，一般是close方法。
2.这个jni的报错是在xml解析模块里产生的，原因估计是你打开太多文件超出它允许的数量上限。
3.debug和run当然有区别，执行代码的模式都不一样。debug和run运行效果不同一般是因为多线程时序或者执行速度差异导致，但是也要具体问题具体分析。对于你的情况，我不了解你所用的xml模块的JNI实现代码，所以不好下结论。也有可能在代码实现里针对DEBUG模式，文件上限数量更小。

#4

引用 3 楼 svenwang 的回复:

Quote: 引用 2 楼 u014032607 的回复:

Quote: 引用 1 楼 svenwang 的回复:

这个是JNI代码的报错。
可能是因为你没有关闭doc？
垃圾回收只是内存的回收，但是并不能解决资源泄漏的问题。

我是没有关闭document，怎么去关闭它呢，一般这个jni的报错是什么问题导致的呢？对比debug和普通run情况下，为什么会有差异呢？谢谢你了

1.怎么关闭？有API文档说明你去看看，一般是close方法。
2.这个jni的报错是在xml解析模块里产生的，原因估计是你打开太多文件超出它允许的数量上限。
3.debug和run当然有区别，执行代码的模式都不一样。debug和run运行效果不同一般是因为多线程时序或者执行速度差异导致，但是也要具体问题具体分析。对于你的情况，我不了解你所用的xml模块的JNI实现代码，所以不好下结论。也有可能在代码实现里针对DEBUG模式，文件上限数量更小。

我开发的app需要加载大量的文件，然后内存就一直吃紧，不断地gc，我能不能修改android gc的策略呢，能不能不用从应用层修改，而直接对dalvikvm进行设置呢，

#5

引用 4 楼 u014032607 的回复:

Quote: 引用 3 楼 svenwang 的回复:

Quote: 引用 2 楼 u014032607 的回复:

Quote: 引用 1 楼 svenwang 的回复:

这个是JNI代码的报错。
可能是因为你没有关闭doc？
垃圾回收只是内存的回收，但是并不能解决资源泄漏的问题。

我是没有关闭document，怎么去关闭它呢，一般这个jni的报错是什么问题导致的呢？对比debug和普通run情况下，为什么会有差异呢？谢谢你了

1.怎么关闭？有API文档说明你去看看，一般是close方法。
2.这个jni的报错是在xml解析模块里产生的，原因估计是你打开太多文件超出它允许的数量上限。
3.debug和run当然有区别，执行代码的模式都不一样。debug和run运行效果不同一般是因为多线程时序或者执行速度差异导致，但是也要具体问题具体分析。对于你的情况，我不了解你所用的xml模块的JNI实现代码，所以不好下结论。也有可能在代码实现里针对DEBUG模式，文件上限数量更小。

我开发的app需要加载大量的文件，然后内存就一直吃紧，不断地gc，我能不能修改android gc的策略呢，能不能不用从应用层修改，而直接对dalvikvm进行设置呢，

最高不要同时加载大量文件，而是加载用完一批文件就关闭然后在加载另外一批文件。这个gc策略没有关系，你如果确实用到了那么多内存，gc也不可能把你正在使用的内存回收掉。

#6

引用 5 楼 svenwang 的回复:

Quote: 引用 4 楼 u014032607 的回复:

Quote: 引用 3 楼 svenwang 的回复:

Quote: 引用 2 楼 u014032607 的回复:

Quote: 引用 1 楼 svenwang 的回复:

这个是JNI代码的报错。
可能是因为你没有关闭doc？
垃圾回收只是内存的回收，但是并不能解决资源泄漏的问题。

我是没有关闭document，怎么去关闭它呢，一般这个jni的报错是什么问题导致的呢？对比debug和普通run情况下，为什么会有差异呢？谢谢你了

1.怎么关闭？有API文档说明你去看看，一般是close方法。
2.这个jni的报错是在xml解析模块里产生的，原因估计是你打开太多文件超出它允许的数量上限。
3.debug和run当然有区别，执行代码的模式都不一样。debug和run运行效果不同一般是因为多线程时序或者执行速度差异导致，但是也要具体问题具体分析。对于你的情况，我不了解你所用的xml模块的JNI实现代码，所以不好下结论。也有可能在代码实现里针对DEBUG模式，文件上限数量更小。

我开发的app需要加载大量的文件，然后内存就一直吃紧，不断地gc，我能不能修改android gc的策略呢，能不能不用从应用层修改，而直接对dalvikvm进行设置呢，

最高不要同时加载大量文件，而是加载用完一批文件就关闭然后在加载另外一批文件。这个gc策略没有关系，你如果确实用到了那么多内存，gc也不可能把你正在使用的内存回收掉。

可是开发的软件必须要在内存里保存那么大的数据量，这些数据在之后会频繁调用的，我现在遇到的问题就是由于我内存分配的heap很大了，每次gc的时间都很长，再加上gc很频繁，这样严重的影响了运行的效率，我能否去设置dalvikvm中的参数去减少gc的频率呢，网上说有dalvikvm.vm.heapminfree参数，可是我在应用中无法去修改，能否应用本身就去修改dalvikvm的参数