JVM总内存常为64MB偶尔降至2MB的原因排查求助

首先得给你点个赞，能精准定位到是总内存而不是空闲内存的问题，这已经排除了大部分常见的GC导致的空闲内存波动情况。结合你的场景——长期运行的C# GUI多次调用JNI DLL，偶发totalMemory()从64MB掉到2MB触发OOM，之后又恢复，我梳理了几个最可能的原因，以及对应的排查修复思路：

1. 线程附着/分离的操作不规范，导致JVM内部状态混乱 #

你的精简JNI代码里没展示调用后的清理逻辑，但我猜大概率是这里出了问题。在JNI中，当一个原生线程附着到JVM后，如果没有显式调用DetachCurrentThread()，JVM会认为这个线程一直处于关联状态。

当C# GUI的多个线程频繁调用你的JNI函数时，可能会出现：

• 某个线程附着后没分离，后续新线程再附着时，JVM可能错误地为其分配了一块极小的临时堆空间（就是你看到的2MB）；
• 等这个异常线程的关联状态被JVM清理后，后续的附着操作又回到正常的64MB堆。

修复建议：在JNI函数执行完所有Java调用后，务必调用jvm->DetachCurrentThread()，同时记得释放本地引用（比如env->DeleteLocalRef(jObj)），避免内存泄漏和状态混乱。

2. 未显式指定JVM堆参数，动态调整触发异常 #

你创建JVM时只设置了类路径，没有指定堆的初始大小（-Xms）和最大大小（-Xmx）。JVM默认会根据系统内存情况动态调整堆大小，但在跨语言（C#调用JNI）的复杂场景下，这种动态调整可能出现bug：

比如当C#应用本身占用大量内存时，JVM可能误判系统内存不足，强行把堆收缩到极小值；等C#释放部分内存后，JVM又把堆调回正常的64MB。这种偶发性的误判就会导致你看到的现象。

修复建议：显式固定堆大小，比如在JVM启动参数里加上-Xms64m -Xmx64m，强制堆保持在64MB：

JavaVMOption* options = new JavaVMOption[2];
options[0].optionString = "-Djava.class.path=jni_test.jar";
options[1].optionString = "-Xms64m -Xmx64m"; // 新增堆参数
vm_args.nOptions = 2; // 记得修改选项数量

3. JVM实例被意外销毁，重建时堆参数异常 #

你用JNI_GetCreatedJavaVMs来复用现有VM，但某些边缘情况可能导致VM被意外销毁：

• 比如某个附着JVM的C#线程崩溃，导致JVM内部状态损坏，触发JVM自行退出；
• 当下一次调用JNI函数时，JNI_GetCreatedJavaVMs找不到有效VM，就会重新创建一个。而新创建的VM可能因为当时系统内存紧张，或者环境变量异常，默认堆只有2MB；等系统状态恢复后，再次创建（如果又销毁的话）就回到64MB。

排查建议：在JNI代码里加日志，记录每次JNI_GetCreatedJavaVMs的返回结果（比如找到几个VM实例），确认是否存在VM被意外销毁的情况：

jint numVMs = 0;
jint rslt = JNI_GetCreatedJavaVMs(&jvm, 1, &numVMs);
if (numVMs > 0) {
    printf("[JNI] Reusing existing JVM instance\n");
} else {
    printf("[JNI] Creating new JVM instance\n");
    rslt = JNI_CreateJavaVM(&jvm, (void**)&env, &vm_args);
}

4. OOM触发后的JVM堆调整异常（可能性较低） #

虽然你捕获了Throwable，但OOM发生时JVM可能正在进行堆调整或GC，极端情况下可能导致堆元数据异常，临时收缩堆到极小值。不过这种情况一般影响的是空闲内存，而非总内存，所以优先级相对低一些，但可以通过GC日志排查。

排查建议：添加-XX:+PrintHeapAtGC -XX:+PrintGCDetails到JVM参数，打印堆的变化日志，看看totalMemory跳水时JVM的GC和堆调整行为。

内容的提问来源于stack exchange，提问作者Abra