是否可以在不进入代码的情况下检查内存泄漏。我有我的应用程序，我想检查是否有内存泄漏。
在我目前的组织中，我检查运行应用程序之前和之后的cpu使用情况以及应用程序进程的cpu使用情况。但我不认为这是正确的方法。
请在这方面告诉我。
答案 0 :(得分：8)
如果使用以下标志运行Java应用程序：
-Dcom.sun.management.jmxremote
您可以使用jconsole与其建立联系。 jconsole是Java附带的工具，位于找到bin程序的java目录中。您可以运行它并观察内存使用情况（它不是很好，但可以帮助发现泄漏）。在最新版本的Java（1.6的后期版本）中，您还可以运行类似于jvisualvm的{{1}}，但也会告诉您实例化每个类的数量，这更有用。
答案 1 :(得分：4)
答案 2 :(得分：1)
你是正确的，因为它涉及一个垃圾收集器并且会有一种锯模式，因此只用Java来观察内存并不容易。然而，长时间记录整个应用程序的内存消耗是有用的。
如果您有一些自动意味着“远程控制”应用程序（如Windows下的SendKeys），您可以制作美好的时间内存消耗图表。使用您喜欢的表格计算程序绘制数据的线性插值。如果这显示出常规的向上趋势，则可以表示存在泄漏。只有在应用程序不应该在内存中增长的状态下才能执行此操作，这也可以通过健康的人类思考应用程序需要存储哪些信息来显示/处理数据。
当然，需要其他工具来深入到线程或类（请参阅其他响应）。
答案 3 :(得分：1)
使用OS工具，恕我直言，不应该分析Java应用程序的内存消耗。正在运行的JVM将分配一定量的内存，并且不太可能释放它，即使JVM在给定的时间点实际上并不需要它。操作系统工具仅报告JVM分配的内存量，而不是JVM中实际提交的内存量。
随JDK（jstat，jconsole，jvisualvm）提供的工具更加可靠。在解释内存使用时，最重要的是实际堆的大小。 Java应用程序通常会显示锯齿图案。随着时间的推移，堆中使用的堆将逐渐增加，并且当GC通过删除不再需要的所有对象来释放堆空间时，堆将急剧下降。
一个明确的警告信号是一个缓慢上升的锯齿：由GC引起的急剧下降每次都会结束一点点。如果应用程序运行很长时间（通常用于服务器应用程序），从长远来看，这很可能会导致OutOfMemory错误。
另一件要做的事是锯齿，其中'牙齿'越来越尖锐。这也表明应用程序需要越来越多的内存。
如果您想分析感知问题的根源，您需要分析创建的对象数量并查看它们存在多长时间。这不是一件小事。
答案 4 :(得分：0)
如果其unix c代码则使用valgrind
答案 5 :(得分：0)
是的，可以检查内存泄漏。 使用性能工具检查泄漏。
使用perf的探针的示例用法可能是检查libc的malloc（）和free（）调用：
$ perf探针-x /lib64/libc.so.6 malloc
$ perf探针-x /lib64/libc.so.6免费
添加了新事件： probe_libc：malloc（在0x7eac0上）
探针已创建。现在，让我们记录一下4秒钟内malloc和free在全球所有系统中的全局使用情况：
$性能记录-e probe_libc：malloc -agR sleep 4
$性能记录-e probe_libc：free -agR sleep 4
让我们在4秒钟内记录所有进程中malloc和free的使用情况：
$ perf stat -e probe_libc：free -e probe_libc：malloc -ag -p $ {pgrep $ process_name $）sleep4
输出：
进程ID'1153'的性能计数器统计信息：
11,312 probe_libc：免费
11,644́probe_libc：malloc
4.001091828秒的时间
如果每次执行perf命令时malloc和可用计数之间的差值增加，则表明存在内存泄漏。