通过JNI监视Java调用的C DLL的内存使用情况？

如何监视通过JNI从Java调用的本机C DLL所使用的内存？使用标准的Java监控工具和选项，我可以看到Java内存空间，但无法查看C DLL使用的任何内存。Java使用的是~70MB，但任务管理器中的任务显示为200Mb+，如果可能的话，我想看看这130MB额外的内存中有什么。

您是否尝试过使用它进行更深入的挖掘

如果您有DLL的源代码，您可以使用调试库和可能的MEM分配跟踪器进行重建，并且使用VisualC++调试程序调试（您需要告诉它使用java应用程序）。p>

---

如果您没有源代码，那么选项是有限的。

我相信即使在C DLL中这样做也不是很容易

---

据我所知，标准Java监控工具通过查询虚拟机来收集信息，因此，即使内存处于同一进程中，除非虚拟机知道如何检查动态链接库，否则它将无法看到任何内容。我相信您需要使用外部工具或对DLL进行一些大规模修改，以便跟踪其内存使用情况。

好吧，因为DLL实际上不是Java堆的一部分，我认为最准确的解读应该是编写一个小型分析程序（一个小型Java/JNI程序或C++/C#，等等）若要以与应用程序类似的方式导入和使用DLL，而不执行其他任何操作（只需像您一样使用DLL），则此分析应用程序生成的内存配置文件应与DLL的内存配置文件非常接近

您还应该测试DLL是否有静态或动态内存形状-在加载DLL之前和之后直接进行内存测量，以查看是否有~130MB的一次性命中，或者内存是否随时间缓慢上升

---

在Solaris/Linux上，我听说Sun Studio Collector/Analyzer是一个很好的工具，但是您陷入了DLL的困境（或者说DLL地狱）

您可以在性能监视器中使用计数器监视本机堆。（perfmon32）但是，它不会在每个DLL的基础上为您分解它，甚至jvm.DLL也将包含在这里

大多数分析工具都可以附加到进程，并捕获和跟踪内存分配和释放。这使他们能够推测泄漏的位置。

---

最近，当我试图追踪从Java调用的本机代码中的内存泄漏时，我发现了一个非常好的漏洞，这给了我更多的信息，Richard，但还不足以确定泄漏的位置。不过，对于任何基于Windows的开发人员来说，Process Viewer是工具箱中的一个优秀工具！如果你有源代码，那么你可以重建和调试从VS。。。（请参阅扩展部分以回答）Java监视工具只提供Java堆的信息，不报告Windows在进程中为本机调用附加的任何内存。感谢您的提示，Declan，我将在周一尝试此方法。监视从Java调用的JNI DLL中的内存使用