【问题标题】:After Text was deleted from JTextArea, heap is not empty从 JTextArea 中删除 Text 后,堆不为空
【发布时间】:2013-01-11 01:30:12
【问题描述】:

我有一个带有 AWT GUI 的应用程序,我使用 JTextArea 来记录输出。如果我用setText(null)removeAll()setText("") 擦除文本,然后运行垃圾收集器System.gc(),我注意到整个文本仍在内存中。我怎样才能真正删除文本?

我对分析器不是很熟悉,这是我在setText(null)之后在内存转储中看到的:

【问题讨论】:

  • 您可能正在处理一个已嵌入到String Pool 中的字符串。我不得不问,为什么这很重要?还有为什么 AWT GUI 使用 Swing 组件 (JTextArea)?
  • JTextArea 听起来像 Swing 而不是 AWT。
  • 另外,请理解,即使您尝试运行它,您也无法完全控制获得 GC 的内容。另外,字符串是否被任何其他变量引用?
  • 初始值是字符串常量还是动态构建的?
  • 您是否尝试过查看是否有任何对象仍在引用您的字符串?通常,分析器能够提供此类信息。顺便说一句,如果你的字符串是某个类的静态最终常量,它永远不会是 GC'eed

标签: java swing heap-memory jtextarea profiler


【解决方案1】:

请阅读:How Garbage Collection works in Java

根据the docsSystem.gc()

调用 gc 方法建议 Java 虚拟机花费精力回收未使用的对象,以使它们当前占用的内存可用于快速重用。当控制从方法调用返回时,Java 虚拟机已尽最大努力从所有丢弃的对象

中回收空间

NB - 建议。这意味着垃圾收集器只建议进行清理而不是强制它也可能完全忽略您的请求,因此我们无法知道垃圾何时会被收集,只有及时。

NB - disgarded objects:这是指不是static/final 或任何其他实例/类/字段/变量等使用/引用的所有对象。

这也是我在该主题上发现的一个有趣的问题:

最佳答案如下:

每个人都说要避免System.gc() 的原因是它是一个 从根本上破坏代码的很好的指标。任何代码 依赖于它的正确性肯定是坏的;任何依赖它的人 因为性能很可能会损坏

此外,甚至还提交了一个错误的文档措辞错误:

.

【讨论】:

    【解决方案2】:

    正如@DavidK 所指出的,System.gc() 不是检查这一点的有用方法。使用here 所描述的机制,大多数profilers 可以强制垃圾收集,这取决于一些limitations,是一个有用的调试工具。

    【讨论】:

      【解决方案3】:
      1. 如果您的客户端程序中有任何 String 对象保存此内容,请将它们也设置为 null。

      2. 另外,您不需要显式调用 System.gc() 方法。 JVM 会在需要为其他对象分配更多内存时对孤立对象进行垃圾收集。

      3. 您只需要担心是否会看到内存不足/堆内存使用量持续增加等情况。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2013-05-12
        • 1970-01-01
        • 2021-12-22
        • 2021-12-07
        • 1970-01-01
        • 2019-03-20
        相关资源
        最近更新 更多