如何监视通过JNI从Java调用的本机C DLL使用的内存？使用标准的Java监视工具和选项我可以看到Java内存空间，但我无法查看C DLL使用的任何内存。 Java正在使用~70MB，但任务管理器中的任务显示200Mb +，如果可能的话，我希望看到130MB的额外内容。
答案 0 :(得分：3)
您可以使用性能监视器中的计数器监视本机堆。 （perfmon32）然而它不会在每个DLL的基础上为你分解，甚至jvm.dll也会包含在这里。
那里的大多数分析工具都可以附加到进程并捕获和跟踪内存分配和解除分配。这允许他们推测泄漏的位置。 我最近试图追踪从Java调用的本机代码中的内存泄漏时发现的一个非常好的Memory Validator
答案 1 :(得分：1)
您是否尝试过使用Process Viewer深入挖掘。
如果您拥有DLL的源代码，您可以使用调试库和可能的内存分配跟踪器进行重建 - 并使用Visual C ++调试器进行调试（您需要告诉它使用java应用程序）。
如果您还没有来源 - 则选项有限。
答案 2 :(得分：-1)
我相信即使在C DLL中执行此操作也不会那么容易。
据我所知，标准Java监控工具通过查询虚拟机来收集信息，因此即使该内存处于同一进程中，除非虚拟机知道如何检查动态链接库，否则它将无法看到什么。我相信您需要使用外部工具或对DLL进行一些大量修改才能跟踪其内存使用情况。
答案 3 :(得分：-1)
好吧，既然DLL实际上不是Java堆的一部分，我认为最准确的解读是编写一个小的分析程序（小型Java / JNI程序或C ++ / C＃等）来导入并以与您的应用程序类似的方式使用DLL并且不做任何操作 - 只需像使用DLL一样 - 此配置文件应用程序的结果内存配置文件应该是DLL的内存配置文件的良好近似值。
您还应该测试是否存在DLL的静态或动态内存形状 - 在加载DLL之前和之后直接进行内存测量以查看是否存在一次性击中~130MB，或者记忆慢慢上升。
在Solaris / Linux上，我听说Sun Studio收集器/分析器是一个很好的工具，但你被困在DLL-land（或DLL地狱，就像它）