如何释放内存？

Question

我们的应用服务器一直面临着内存溢出错误。我们看到已使用堆大小逐渐增加，最终达到可用堆大小。这种情况每3周发生一次，此后需要重启服务器才能解决问题。 通过对堆转储的分析，我们发现问题是由JSP中使用的对象引起的。

JSP对象可能是应用服务器内存问题的真正原因吗？如何释放JSP对象（使用usebean或其他标记实例化的对象）？

我们有一个带有2个节点和一个IHS的集群WebSphere应用服务器。

编辑：上述结果基于以下使用IBM支持助手进行的堆转储和nativestderr日志分析。

nativestd err日志分析：

alt text http://saregos.com/wp-content/uploads/2010/03/chart.jpg

堆转储分析：

！[alt text] [2]

堆转储分析显示立即支配者（图像上方哈希表条目的2级）

！[alt text] [3]

最后一张图表明，立即支配者实际上是在JSP中使用的对象。

编辑2：更多信息请访问http://saregos.com/?p=43

- sarego

---

我记得一个与JSP部署相关的旧内存泄漏问题。Sun编译器存在内存泄漏，JSP在被引用时会即时编译，最终导致内存溢出错误。解决方案是在部署之前预编译JSP。 - crowne

3周 - 不管应用程序做了什么？您使用任何与计时器相关的内容吗？听起来像是一个周期性的操作没有被正确释放。 - Daniel Bleisteiner

如果您正在使用最新版本的Java，请确保使用包含的VisualVM进行分析。您可以对正在创建的对象进行快照，这在调试这些问题时非常有用。 - Uri

我们已经从Java代码中消除了一些可能的泄漏，但是在JSP层面上还没有确定任何实际泄漏。我们数据bean的初始化（来自上图的嫌疑人）都具有页面范围，因此实际上不应该存在泄漏。 - sarego

啊啊啊...http://www-01.ibm.com/support/docview.wss?uid=swg1PK38940出现内存泄漏...堆使用随时间增长，导致OutOfMemory异常。对堆转储的分析显示， 以下对象占用了越来越多的空间：40,543,128 [304] 47类 com/ibm/wsspi/rasdiag/DiagnosticConfigHome 40,539,056 [56] 2个java/util/Hashtable 0xa8089170 40,539,000 [2,064] 511个java/util/Hashtable$Entry的数组 0xaac7ef20 6,300,888 [40] 3个java/util/Hashtable$HashtableCacheHashEntry - jeff porter

Answer 1

首先，我会附加一个配置工具来告诉您这些“对象”占用了所有内存。

Eclipse有TPTP， 或者有JProfiler 或JProbe。

任何一个都应该显示对象堆栈正在增加，并允许您检查它以查看堆栈上的内容。

然后搜索代码库以找出是谁创建了这些对象。

也许您有一个缓存或树/映射对象，其中包含元素，您只实现了这些对象的“equals()”方法，而您需要实现“hashcode()”。 这将导致映射/缓存/树变得越来越大，直到它崩溃为止。 不过这只是猜测。

JProfiler将是我的第一选择

Javaworld有一个内存中的示例截图...

_{(来源：javaworld.com)}

还有一个对象堆栈构建和清理的截图（因此有锯齿状）

_{(来源：javaworld.com)}

更新*************************************************

好的，我会看看...

http://www-01.ibm.com/support/docview.wss?uid=swg1PK38940

堆使用随时间增加，导致OutOfMemory 条件。 堆转储分析显示以下 对象占用了越来越多的空间：

40,543,128 [304] 47 class

com/ibm/wsspi/rasdiag/DiagnosticConfigHome 40,539,056 [56] 2 java/util/Hashtable 0xa8089170 40,539,000 [2,064] 511 array of java/util/Hashtable$Entry 6,300,888 [40] 3 java/util/Hashtable$HashtableCacheHashEntry

- jeff porter

---

我已经分析了堆转储、核心转储和原生错误日志，并列出了对象列表。然而问题是如何解决这个问题... - sarego

哇，堆大小不错！:-)好的，我会搜索JSP中是否有任何map/hashmap/treemaps等。我猜想在某个地方，有人使用String作为键将对象放入了hashmap中，而该键并不够唯一。或者作为键的对象没有实现equals和hashcode方法。 - jeff porter

Answer 2

手动触发垃圾回收并不能解决您的问题——它不会释放仍在使用中的资源。您应该使用性能分析工具（如jProfiler）来查找内存泄漏。您可能使用了将引用存储在列表或映射中的代码，在运行时没有释放这些引用，很可能是静态引用。

- Daniel Bleisteiner

Answer 3

如果您使用Sun 6 JVM，请强烈考虑使用JDK中的jvisualvm程序，以获取程序内部实际运行情况的初始概述。快照比较非常有帮助，可以帮助您进一步了解哪些对象会出现问题。

如果Sun 6 JVM不可用，则请调查您拥有的性能分析工具。试验可以让您走得更远。

有时候可能只是一个简单的巨大字符数组作为您在列表中收集的子字符串的底层，例如清理工作。

- Thorbjørn Ravn Andersen

Answer 4

我建议阅读Effective Java, 第2章。跟着这本书，再配合使用分析工具，可以帮助您找出应用程序产生内存泄漏的地方。

释放内存并不是解决大量内存消耗的方法。广泛的内存消耗可能是以下两种情况之一：

• 代码编写不正确 - 解决方法是正确编写代码，使其不会消耗超过所需的内存 - Effective Java 在这方面会有所帮助。
• 应用程序确实需要这么多内存。那么您应该使用 Xmx、Xms、XX:MaxHeapSize 等方式增加 VM 内存。

- Bozho

Answer 5

据我所知，没有特定的方法来释放在JSP中分配的对象。与其研究这些选项，不如专注于找到应用程序代码中的实际问题并解决它。

以下是一些可能有帮助的提示：

• 检查您的bean的范围。您是否错误地将某些用户或请求特定的内容存储到“应用程序”范围中？
• 检查您的Web应用程序和应用服务器设置中的Web会话超时设置。
• 您提到堆消耗逐渐增长。如果确实如此，请尝试查看堆大小随各种用户场景增长了多少：获取堆转储，运行测试，让会话数据超时，再获取另一个转储，比较两者。这可能会让您知道堆上的对象来自哪里。
• 当然，检查您的bean是否存在任何明显的内存泄漏。

编辑：像Daniel提到的检查未释放的静态资源也是值得做的事情 :)

- david a.

Answer 6

据我所知，那些占用顶层内存的是缓存存储和其中存储的对象。你应该确保当它占用太多内存时，你的缓存会释放对象。如果你只需要缓存活动对象，你可能想使用弱引用（weak-ref）。

- ony