有哪些工具可用于跟踪 Java 应用程序中 Opencv JNI 库分配的内存。
在我的 java dropwizard 服务器中，我使用 JNI opencv 绑定。当服务器打开时，java 堆内存似乎没有增加超过 GB，它被 GC 定期释放。但是大量（4-5 GB）内存被添加到 java 进程中，不确定它来自哪里。
如何跟踪 JNI 库中分配的内存并识别是否有泄漏。
【问题讨论】：
valgrind，但您也可以使用系统附带的工具。此处（例如）您有一个示例，该示例显示了使用 Instruments.app 的 JNI 代码内部的内存泄漏：youtu.be/0CAuWuMkKBM
标签： java opencv memory-management memory-leaks java-native-interface
@concision 的回应是正确的，对于这种需要，您确实可以依靠jemalloc 来捕获调用 malloc 的位置并将分配可视化为图片或 pdf，感谢jeprof。
当我亲自寻找一种检测本机内存泄漏的方法时，我很快找到了几篇描述这个想法的文章，但我找不到任何描述如何一步一步地做到这一点的文章，所以我会尝试在我的回答中做到这一点。
当您遇到 dropwizard 应用程序的问题时，让我们创建一个泄漏端点作为示例。
让我们在dropwizard-example 中添加我们的泄漏端点。
git clone git@github.com:dropwizard/dropwizard.git 克隆存储库
git checkout v2.0.13 切换到最后一个标签
dropwizard-example/src/main/java/com/example/helloworld/api/中添加泄漏类LeakObject
dropwizard-example/src/main/java/com/example/helloworld/resources/中添加端点类MemoryLeakTestResource
dropwizard-example/src/main/java/com/example/helloworld/HelloWorldApplication.java中注册端点
班级LeakObject
public class LeakObject {
private static final byte[] ZIP_CONTENT;
static {
try {
ZIP_CONTENT = Files.readAllBytes(
Paths.get("target/dropwizard-example-1.0.0-SNAPSHOT.jar")
);
} catch (IOException e) {
throw new RuntimeException(e);
}
}
public String buildSaying() throws IOException {
// The native memory leak is caused by the unclosed ZipInputStream
ZipInputStream inputStream = new ZipInputStream(
new ByteArrayInputStream(ZIP_CONTENT)
);
return String.format(
"Hello, I'm a leak in native memory %d !", inputStream.read()
);
}
}
班级MemoryLeakTestResource
@Path("/native-memory-leak")
@Produces(MediaType.TEXT_PLAIN)
public class MemoryLeakTestResource {
private final LeakObject leakObject = new LeakObject();
@GET
public String sayHelloWithLeakNative() throws IOException {
return leakObject.buildSaying();
}
}
班级HelloWorldApplication
public class HelloWorldApplication extends Application<HelloWorldConfiguration> {
...
@Override
public void run(HelloWorldConfiguration configuration, Environment environment) {
...
environment.jersey().register(new MemoryLeakTestResource());
}
}
在终端中：
dropwizard-example
mvn clean install -DskipTests 构建项目。这将在target 中创建一个名为dropwizard-example-1.0.0-SNAPSHOT.jar 的胖罐子
jemalloc
为了避免与目标环境紧密耦合，让我们使用 docker 来完成这项任务。
要安装jemalloc，我们需要：
./configure --enable-prof --enable-debug 配置构建以启用堆分析和泄漏检测功能make 构建它
make install安装它
对应的Dockerfile
FROM openjdk:11-slim
RUN apt-get update && \
apt-get install -y tcpflow vim htop iotop jq curl gcc make graphviz && \
curl -O -L https://github.com/jemalloc/jemalloc/releases/download/5.2.1/jemalloc-5.2.1.tar.bz2 && \
tar jxf jemalloc-*.tar.bz2 && \
rm jemalloc-*.tar.bz2 && \
cd jemalloc-* && \
./configure --enable-prof --enable-debug && \
make && \
make install && \
cd - && \
rm -rf jemalloc-*
WORKDIR /root
构建你的 docker 镜像：
Dockerfile 的目录
docker build -t native-memory-leak .
这将创建一个安装了 java 11、jemalloc 和 jeprof 的 docker 映像
jemalloc 启动应用程序
为此，您需要：
LD_PRELOAD设置为库的位置libjemalloc.so
MALLOC_CONF 设置为prof_leak:true,prof_final:true 以启用泄漏报告并使其在应用程序退出时将最终内存使用情况转储到文件（根据<prefix>.<pid>.<seq>.f.heap 命名）这些步骤可以通过以下命令完成：
LD_PRELOAD=/usr/local/lib/libjemalloc.so \
MALLOC_CONF=prof_leak:true,prof_final:true \
java ...
jmalloc 识别本机内存泄漏的策略
jeprof
我们将在 docker 容器中启动应用程序。
首先，让我们使用下一条命令启动容器：
docker run -it --rm -v $(pwd):/root \
--name native-memory-leak-test native-memory-leak /bin/bash
此命令将在名为 native-memory-leak-test 的容器中启动一个 bash，该容器基于图像 native-memory-leak 以及可从 /root 获得的当前目录的内容（我们假设为 dropwizard-example）。
从这个 bash 中，您可以使用前面描述的命令启动应用程序，在我们的例子中是这样的：
LD_PRELOAD=/usr/local/lib/libjemalloc.so \
MALLOC_CONF=prof_leak:true,prof_final:true \
java -jar target/dropwizard-example-1.0.0-SNAPSHOT.jar server example.yml
应用程序完全启动后，我们可以进入下一部分
这一步的思路是多次调用导致内存泄漏的端点，以确保泄漏会清楚地出现在最终报告中。
在这种情况下，我们将使用下一条命令从新终端调用端点 2000 次：
docker exec -it native-memory-leak-test \
/bin/bash -c "for i in {1..2000}; do curl -s localhost:8080/native-memory-leak > /dev/null; done"
此命令将使用curl 命令调用端点 2000 次
命令结束后，我们可以进入下一部分
在我们启动应用程序的容器中，我们可以使用 Ctrl+C 将内存使用量转储到类型为 jeprof.<pid>.0.f.heap 的堆文件中来停止它/p>
然后您应该在应用程序的标准输出中看到如下内容：
<jemalloc>: Leak approximation summary: ~<total-bytes> bytes, ~<total-objects> objects, >= 37 contexts
<jemalloc>: Run jeprof on "jeprof.<pid>.0.f.heap" for leak detail
这说明jemalloc已经生成了一个堆文件，名字为jeprof.<pid>.0.f.heap。
jeprof
从之前生成的堆文件中，我们将使用jeprof 在下一个命令中生成人类可读的输出。
jeprof --show_bytes --gif $(which java) jeprof.<pid>.0.f.heap > result.gif
此命令将在dropwizard-example 中从jeprof.<pid>.0.f.heap 生成一个名为result.gif 的gif 文件，感谢jeprof。
生成的 gif 应该是一棵分配树，其中树干是 "os malloc" 代表 JVM 已分配的内容。您的泄漏（如果有）将与树断开连接，如下例所示：
在这个例子中，我们可以看到我们有一个由“Java_java_util_zip_Inflater_init”引起的泄漏，但我们仍然需要识别在我们的应用程序中调用这个本地方法的 java 代码。
此时，我们知道我们有泄漏，但我们仍然需要找出它在我们的应用程序中的位置。对于这部分，我能找到的最佳方法是使用JProfiler（它是一个商业分析器，但您可以使用试用密钥）。
以下是要做的步骤：
Java_java_util_zip_Inflater_init ")使用这种方法，我可以在下一个屏幕截图中看到我的泄漏发生在方法 com.example.helloworld.api.LeakObject.buildSaying 中，正如预期的那样。
【讨论】：
查找从 JNI 库分配的内存泄漏比查找堆上的内存泄漏要痛苦得多。您可能会对工具jemalloc 感兴趣，因为它可以帮助隔离大量分配来自本机内存分配的位置。然后，您可以使用jeprof 工具生成图形，以可视化发生重大分配的堆栈。
看看这些与你的问题非常相似的文章：
他们详细说明了寻找由 JNI 库引起的内存泄漏的过程（即内存不在堆上）。
【讨论】：