我有一个 Java 应用程序，它使用本机库来实现其某些功能。它使用 JNI 来控制本机库，并从库中接收异步回调。您可以将其视为相互通信的 Java 前端和本机后端。
我正面临内存泄漏。在我启动应用程序后不久，内存缓慢而稳定地增加。因此，我试图查看可能导致泄漏的原因。
首先，我尝试用一个简单的 C++ 文本界面替换 Java 前端。这样一来，应用程序就不会以任何方式使用 Java - 并且泄漏停止了。所以问题一定出在Java前端。
因此，我启动了 jvisualVM 以查看堆是否增加 - 结果并没有。Java 堆大小相当稳定。我什至用 xmx32m 启动了这个程序，但是内存一直增加到超过 100m，没有任何OutOfMemoryErrors。事实上，jvisualVM 显示 Java 堆大约为 7m。
所以我用 WinDbg 更深入地研究了这个程序。我用命令分析了堆模式，!heap -s我得到了这个：
堆在一个新运行的程序上：
0:059> !heap -s
LFH Key : 0x382288b9
Termination on corruption : ENABLED
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-----------------------------------------------------------------------------
00330000 00000002 2048 1704 2048 22 71 2 0 0 LFH
005b0000 00001002 1088 212 1088 68 3 2 0 0 LFH
00aa0000 00001002 1088 108 1088 15 7 2 0 0 LFH
004f0000 00001002 15424 12876 15424 1372 89 9 0 1 LFH
...
0:059> !heap -stat -h 004f0000
heap @ 004f0000
group-by: TOTSIZE max-display: 20
size #blocks total ( %) (percent of total busy bytes)
2b110 20 - 562200 (60.36)
98 166e - d5150 (9.33)
6cd20 1 - 6cd20 (4.77)
...
堆在一个已经运行了大约半小时的程序上：
0:046> !heap -s
LFH Key : 0x5e47ba72
Termination on corruption : ENABLED
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-----------------------------------------------------------------------------
006b0000 00000002 2048 1744 2048 46 92 2 0 0 LFH
00200000 00001002 1088 220 1088 68 3 2 0 0 LFH
00950000 00001002 1088 108 1088 15 7 2 0 0 LFH
001b0000 00001002 47808 31936 47808 1855 102 12 0 0 LFH
...
0:046> !heap -stat -h 001b0000
heap @ 001b0000
group-by: TOTSIZE max-display: 20
size #blocks total ( %) (percent of total busy bytes)
98 59d1 - 355418 (36.67)
2b110 10 - 2b1100 (29.61)
6cd20 1 - 6cd20 (4.68)
...
现在可以清楚地看到泄漏是由越来越多的大小为 98 的块引起的。但是当我尝试用 分析其中一个块时!heap -p -a，我得到：
*** 错误：找不到符号文件。默认为 jvm.dll 导出符号
没有任何堆栈跟踪。所以这些块被分配在 jvm.dll 内的某个地方，并且因为没有用于 JVM 的 pdb，我无法进一步调试泄漏。
我设法查明了代码中发生泄漏的位置。Java 前端的所有回调都通过一个函数：
void callback(JNIEnv *env, int stream, double value, char *callbackName){
jclass jni = env->FindClass("nativ/Callbacks");
jmethodID callbackMethodID = env->GetStaticMethodID(jni, callbackName, "(ID)V");
jvalue params[2];
params[0].i = (long)(stream);
params[1].d = value;
env->CallStaticVoidMethodA(jni, callbackMethodID, params); //commenting this out stops the leaks
}
当我注释掉最后一个命令时，泄漏停止了，但我没有得到前端的反馈。
这可能是JVM错误吗？我怎么知道？