频繁的Integer.toString（）转换导致的内存问题

Question

我目前正在将用C＃开发的游戏（用于Windows Phone）移植到Java（Android）。

我们遇到的Java版本内存问题其中，剖析后，似乎是从一个巨大的数字未来的String内存中的对象，显然是由于不可变的性质String的。 现在，我设法将其追溯到将玩家得分显示在屏幕上的方法，该方法在每次得分改变（每秒多次Integer.toString()使用Integer.toString() ）。 我不能真正使用StringBuilder （这是C＃版本中的功能），因为我们使用的框架的文本呈现方法仅接受String作为参数，因此无论如何都会发生转换。

这是Java中的常见问题吗？ 任何人都可以推荐解决方案（除了联系框架开发人员要求他们修改其方法！）？

更新：

游戏节奏非常快，得分部分取决于自当前“阶段”开始以来经过的时间。 每秒更新15次。

我们没有保留对字符串的引用，但我认为框架可能正在泄漏或复制这些字符串，因此我试图研究一下（这不是一个公共框架，据我所知尚未使用对于这种快节奏的游戏而言）。

合并是一个很好的建议，我想尝试一下，但是必须修改评分系统才能拥有固定的一组值。

Answer 1

我不确定这是否对您的特定情况有所帮助，但是通常，当您使用一组固定的字符串值进行操作时，将所有这些值添加到字符串池是有意义的。 在这种情况下，您可以强制JVM不为每个新字符串在堆上创建对象，而是利用字符串池。

您必须更改代码以从池中返回字符串，例如：

return String.valueOf(123).intern();

javadoc的一些其他说明：

调用intern方法时，如果池已经包含等于equals（Object）方法确定的此String对象的字符串，则返回池中的字符串。 否则，将此String对象添加到池中，并返回对此String对象的引用。

Answer 2

最后，我们通过创建由固定长度char数组支持的可修改字符串类来解决该问题，并在初始化后编写了零分配的文本呈现方法。

此后，一切运行得更加顺利，但是我们仍然有一些由GC引起的“冻结”。 经过分析后，发现这是由于在主游戏循环中在循环中创建了大量迭代器所致。 然后，我们编写了一个使用迭代器池的自定义数组类，现在一切运行良好！