java内存碎片_在Java中分配大量数组时避免内存碎片化

我正在开发一种运行在

Windows Mobile设备上的

Java应用程序.为了实现这一点,我们一直在使用Esmertec JBed JVM,这不是完美的,但现在我们坚持下去.最近我们一直在收到客户关于OutOfMemoryErrors的投诉.在玩了很多东西之后,我发现该设备有大量的可用内存(大约4MB).

OutOfMemoryErrors总是出现在代码中的同一点上,也就是扩展StringBuffer以便向其附加一些字符.在这个区域附加了一些日志记录之后,我发现我的StringBuffer有大约290000个字符,容量约为290500.内部字符数组的扩展策略只是将其大小加倍,因此它将尝试分配一个约580000个字符.我在这个时间打印出了内存使用量,发现它总共使用大约3.8MB的大约6.8MB(虽然我已经看到总可用内存上升到12MB左右,所以有很大的扩展空间).因此,在这一点上,应用程序报告了一个OutOfMemoryError,这并没有太多的意义,因为还有多少仍然是免费的.

到目前为止,我开始考虑应用程序的运行.基本上发生了什么,我正在使用MinML(一个小型​​的XML Sax Parser)解析XML文件. XML中的一个字段中有大约30万个字符.解析器从磁盘流传输数据,默认情况下它一次只加载256个字符.所以当它到达有问题的字段时,解析器将调用处理程序的’characters()’方法超过1000次.每次都会创建一个新的char [],保存256个字符.处理程序只需将这些字符附加到StringBuffer. StringBuffer的默认初始大小只有12,因此字符被附加到缓冲区,它将不得不增长次数(每次创建一个新的char []).

我的假设是,有可能虽然有足够的可用内存,因为以前的char []可以被垃圾回收,也许没有足够大的连续内存块来适应我正在分配的新数组.也许JVM不够聪明地扩大堆大小,因为它是愚蠢的,认为没有必要,因为显然有足够的可用内存.

所以我的问题是：有没有人有这个JVM的任何经验,可能能够最终确定或反驳我关于内存分配的假设？还有,有没有人有任何想法(假设我的假设是正确的)关于如何推动数组的分配,以便内存不会分散？

注意：我已经尝试过的事情：

>我增加了StringBuffer的初始数组大小,我增加了解析器的读取大小,因此不需要创建这么多数组.

>我改变了StringBuffer的扩展策略,一旦达到一定的大小阈值,它只会扩展25％而不是100％.

做这两个事情有所帮助,但是当我增加xml数据的大小时,我仍然会以相当小的大小(约350kb)获得OutOfMemoryErrors.

另外需要补充的是：所有这些测试都是在使用JVM的设备上执行的.如果我使用Java SE 1.2 JVM在桌面上运行相同的代码,我没有任何问题,或至少我没有得到问题,直到我的数据达到大约4MB.

编辑：

我刚刚尝试过的另一件事是帮助我将Xms设置为10M.所以这样就可以解决JVM不扩展堆的问题,并且允许我在发生错误之前处理更多的数据.