为什么转储中有这么多 SessionFactoryImpl 对象？答案

【问题标题】：Why are there so many SessionFactoryImpl objects in the dump?为什么转储中有这么多 SessionFactoryImpl 对象？
【发布时间】：2020-04-21 11:20:27
【问题描述】：

我的转储中有大约 15,000 个相同的 SessionFactoryImpl 对象：

具有传入引用的对象之一：

具有出站引用的对象之一：

我没有配置以下参数，它们是默认设置的：

hibernate.query.plan_cache_max_size
hibernate.query.plan_parameter_metadata_max_size

问题：

版本：

【问题讨论】：

它们在那里是因为它们是被创建的，这可能意味着您正在代码中做一些一开始就不应该做的事情。错误很可能出现在您自己的代码中，或者您认为应该如何使用 Spring（以错误的方式）。
使用MAT 之类的工具，您可以有特定的报告来分析内存泄漏（从未使用过jprofiler，但它似乎提供了类似STELLAR ANALYSIS OF MEMORY LEAKS 的功能）。尝试在这些查询中查看一个共同因素，并找出代码的哪一部分可能是导致此问题的主要原因。
为什么有这么多 SessionFactoryImpl 对象，为什么不删除它们？我知道为什么但也不应该删除它们 - 应该重用单例（只要 db config 是不变）
如果这些对象是在代码中创建的，我怎样才能在 Jprofiler 中找到创建这些对象的类？ JVisualm 具有跟踪创建堆栈跟踪的选项 - 但这仅适用于分析运行时而不是“历史创建”JProfiler 可能会有类似的东西。
在堆遍历器的引用视图中尝试“合并支配引用”。

【解决方案1】：

也许你可以找到使用“Show Selection In Heap Walker”创建的SessionFactoryImpl对象所在的代码行号，并在“Allocations”中观察对象的分配树

【讨论】：

【解决方案2】：

问题在于登录到数据库的方法不正确。当某个任务完成时，总是会创建日志工厂，它引用了 SessionFactoryImpl。并且有很多这样的任务，每次创建这些工厂。我们能够在代码中找到这个地方并修复它，以便在应用程序启动时创建一次日志工厂。

【讨论】：