我的问题不同于this我已经对我的应用程序进行了分析，它太慢了。
完成一个过程后，我在堆 walker 中看到了一些 Activity 对象。
虽然我们将一些数据从数据库缓存到 HashMap，但是堆 walker 向我显示了一些 Activity 对象，例如 Resultset.getString 和 Statement.getString 不应该在那里。
HashMap.put() 比上述两种方法占用更少的内存。
我做的一切都很好吗？这个分析是否正确？或者我遗漏了任何东西，内存被 HashMap 本身占用，而 HeapWalker 只是向我展示了 JDBC 的方法(getString 和 executeQuery )。
最佳答案
既然你在谈论方法，我猜你正在查看堆遍历器的“分配” View 。该 View 显示对象的创建位置，而不是对象被引用的位置。有一个截屏 explains allocation recording in JProfiler .
HashMap.put 不会分配大量内存，它只会创建用于存储键值对的小型“Entry”对象。占用大量内存的对象是在将它们放入 HashMap 之前创建的。
Resultset.getString 和 Statement.getString 创建您从数据库中读取的 String 对象。因此，有理由假设其中一些对象的生命周期更长。
要找出对象仍在堆上的原因，您应该转到引用 View ，选择传入引用并搜索“到 GC 根的路径”。 “最大对象” View 对于跟踪过度内存使用也非常有帮助。
关于java - 通过 JProfiler 查找内存泄漏，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9409824/