1

在我的 J2ME 代码中，我有一个看起来像这样的循环，

 Enumeration jsonEnumerator = someJSONObject.keys();

while(jsonEnumerator.hasMoreElements()){

String key = (String) jsonEnumerator.nextElement();
String value = someJSONObject.getJSONObject(key);
someOtherJson.put(value,key);
}

考虑到上述代码中的字符串分配

String key = (String) jsonEnumerator.nextElement();

这是使用字符串池而不是实例化新对象的正确方法，还是分配字符串以避免内存泄漏的其他方法是什么？

4

4 回答 4

2

字符串分配不会导致内存泄漏。

该代码中的其他地方是否存在字符串泄漏取决于从该代码中无法辨别的几件事：

  • JSON 实现如何创建键和值字符串。（如果它String.substring()在更大的字符串上使用，您可能会通过共享字符串支持数组泄漏存储。）
  • 是否someOtherJson被泄露。

正常的方法（在 Java SE 中）是不用担心它......直到您从内存分析中获得证据表明存在泄漏。在 Java ME 实现中，内存通常更受限制，而 GC 实现可能相对较慢。因此有必要减少对象（包括字符串）的数量和大小。但这不是内存泄漏问题......我仍然建议先进行分析，而不是跳入可能浪费精力的内存效率活动。

这是使用字符串池而不是实例化新对象的正确方法，还是分配字符串以避免内存泄漏的其他方法是什么？

正如我所说，上面的代码没有泄漏。

字符串池不会消除泄漏，也不一定会降低垃圾对象的创建率。他们可以在任何给定时间减少活动的 String 对象的数量，但这是有代价的。

如果您想尝试这种方法，使用它String.intern()来管理您的字符串池是最简单的。但这不一定有帮助。而且实际上会使事情变得更糟。（如果没有足够的共享潜力，interned string pool 的空间开销可能会超过节省的空间。此外，interned string pool 为 GC 创造了更多的工作 - 更多的跟踪，以及更有效的弱引用处理。 )

于 2013-01-21T11:33:16.957 回答
1

No, String assignment, by itself does not create anything. The only thing resembling a "leak" in Java is when you put a whole bunch of references into some array or other structure and then forget about it -- leave the structure "live" (accessible) but don't use it.

于 2013-01-21T13:07:32.033 回答
0

如果您在谈论实习字符串，那么这里就不会发生。只有在源代码中找到的常量字符串才会自动发生。

任何其他字符串都将被垃圾收集，就像任何其他对象一样。

于 2013-01-21T11:35:32.930 回答
-2

我的建议是：

Enumeration jsonEnumerator = someJSONObject.keys();

while(jsonEnumerator.hasMoreElements()) {
    String key = (String) jsonEnumerator.nextElement();
    someOtherJson.put(someJSONObject.getJSONObject(key), key);
}

字符串实例化会导致 J2ME 中的内存泄漏，因为 J2ME 使用不良的垃圾收集方法来减少资源使用。

当您尝试开发 J2ME 应用程序时，请注意内存和 CPU 使用情况。

于 2013-01-21T11:17:35.330 回答