Profiler 下的 Hibernate 性能和内存泄漏问题答案

【问题标题】：Hibernate performance and memory leakage issues under profilerProfiler 下的 Hibernate 性能和内存泄漏问题
【发布时间】：2011-04-26 09:39:09
【问题描述】：

我已经使用 jprofiler 分析了我的 J2EE Web 应用程序。通过查看 vm 遥测图和记录的对象，我发现存在巨大的内存泄漏。使用 heap walker 我得出结论，由于休眠条件、query.list、template.find、over-redid hashCode 和 equals 方法以及某些自定义请求处理器，存在大量内存泄漏。我无法理解的是内存泄漏是如何发生的。

我在谷歌上查了很多，可以理解的是，标准比 HQL 慢，显然比 SQL 慢，但内存泄漏非常有趣。有内存泄漏的可能性吗？

在记录的对象屏幕下，hashmap 对象增加到接近 100%，内存泄漏图向上平滑。

我也给你看我的hashcode和equalsmethol，请看一下：

public boolean equals(Object other) {
    if ( !(other instanceof Associate) ) return false;
    Associate castOther = (Associate) other;
    return new EqualsBuilder()
        .append(this.getAssociateId(), castOther.getAssociateId())
        .isEquals();
}

public int hashCode() {
    return new HashCodeBuilder()
        .append(getAssociateId())
        .toHashCode();
}

非常感谢。

【问题讨论】：

标签： java hibernate memory-leaks hibernate-criteria jprofiler

【解决方案1】：

EqualsBuilder 使用反射，它可以有一个impact on perm gen space。

为什么要依赖这些？为什么不自己写呢？如果您使用 IntelliJ，它会生成完美运行的方法而无需重新设计。关注Joshua Bloch's recipe，你也会少一点依赖。

【讨论】：

Eclipse 还生成了 equals 和 hashCode 的非常有用的实现 :)
@duffymo，谢谢我阅读了这个主题，是的，我发现 EqualsBuider 存在一些性能问题。您对休眠列表、查找和条件有任何想法吗？

【解决方案2】：

好吧，每次调用 equals 或 hashCode 时都会创建一个新对象。如果 GC 不运行或不收集这些对象，这可能会导致更高的内存消耗。您是否因此而出现记忆问题？

【讨论】：

不，我不这么认为，内存泄漏与内存消耗不同。如果您的应用程序存在内存泄漏问题，则意味着即使在 GC 完成工作后您也无法释放内存。这是因为在一些使用过的对象中留下了一些引用，限制了 GC 完成其工作。
@Kuri 是的。但是，我不太确定 OP 是否真的发现了内存泄漏（未使用的对象仍以某种方式被引用，因此无法收集）或只是高内存消耗。
我也不太确定，但它写道，如果 vm 遥测图向上移动，则意味着存在内存泄漏。即使您调用 GC，它也不确定 GC 是否执行其工作。该对象可能会保留在内存中，稍后它会被释放。
但是新对象在方法范围内，每次代码退出equals和hashCode时都应该有资格进行GC。返回的项目是来自流式接口的链接调用的产物，而不是新对象本身。这确实是一个严重的问题。