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

我正在开发一个在Windows移动设备上运行的Java应用程序。为了实现这一点,我们一直在使用esmertec jbed jvm,这并不完美,但我们现在仍然坚持使用它。最近我们收到了客户关于内存不足的投诉。在玩了很多东西之后,我发现这个设备有足够的空闲内存(大约4MB)。

OutOfMemoryErrors总是发生在代码中的同一点上,也就是在扩展StringBuffer以便向其追加一些字符时。在这个区域添加了一些日志之后,我发现我的StringBuffer中有大约29万个字符,容量约为29.05万。内部字符数组的扩展策略只是将大小增加一倍,因此它将尝试分配大约580000个字符的数组。我也打印出了这次的内存使用情况,发现它使用了大约3.8MB的总容量约为6.8MB(尽管我曾看到总可用内存有时会增加到12MB左右,所以有足够的扩展空间)。所以现在应用程序报告了一个内存不足的错误,考虑到还有多少可用内存,这个错误没有多大意义。

到目前为止,我开始考虑应用程序的操作。基本上,我正在使用minml(一个小型的XML SAX解析器)解析一个XML文件。XML中的一个字段包含大约30万个字符。解析器从磁盘流式传输数据,默认情况下,一次只加载256个字符。所以当它到达有问题的字段时,解析器将调用处理程序的“characters()”方法1000多次。每次它都会创建一个包含256个字符的新字符[]。处理程序只是将这些字符附加到StringBuffer。StringBuffer的默认初始大小仅为12,因此当字符附加到缓冲区后,它将不得不增长若干次(每次创建新的char[])。

我的假设是,虽然有足够的可用内存,因为以前的char[]s可以被垃圾收集,但可能没有足够大的连续内存块来容纳我要分配的新数组。也许JVM不够聪明,无法扩展堆大小,因为它很愚蠢,认为没有必要,因为显然有足够的空闲内存。

所以我的问题是:是否有人有这个JVM的经验,并且能够最终确认或反驳我关于内存分配的假设?另外,对于如何修改数组的分配以使内存不被分割,有人有什么想法吗(假设我的假设是正确的)?

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

• 我增加了StringBuffer的初始数组大小,并增加了解析器的读取大小,这样它就不需要创建这么多的数组。
• 我改变了StringBuffer的扩展策略,这样一旦它达到某个大小阈值,它将只扩展25%,而不是100%。

做这两件事都有一点帮助,但是当我增加进入的XML数据的大小时,我仍然会以一个相当小的大小(大约350KB)从内存中得到错误。

还有一件事要补充:所有这些测试都是在使用相关JVM的设备上执行的。如果我使用Java SE 1.2 JVM在桌面上运行相同的代码,我就不会有任何问题,或者至少在我的数据达到4MB的大小之前我不会有问题。

编辑:

另一件我刚刚尝试过的有点帮助的事情是,我将XMS设置为10M,这样就克服了JVM不在应该的时候扩展堆的问题,并且允许我在错误发生之前处理更多的数据。