在C语言插件中调用Java代码时JNI_CreateJavaVM随机失败问题的解决方案问询

看起来你踩了JNI在动态加载插件中启动的经典坑——这个场景确实不在OpenJDK JVM的设计预期内，不过我们可以一步步拆解问题，找到可靠的修复方式：

核心原因：JVM初始化依赖进程级全局状态 #

JVM的启动过程远比表面的JNI_CreateJavaVM调用复杂，它会做大量进程级的底层操作：

• 接管全局信号处理（比如SIGSEGV、SIGBUS），如果主进程或其他组件已经修改过信号处理逻辑，会直接导致冲突
• 对线程栈的布局和大小要求极高（官方建议至少16MB），但dlopen加载的插件默认继承主进程的栈（通常只有8MB），很容易触发栈溢出或内存越界
• 依赖进程全局符号表的完整度，RTLD_GLOBAL虽然能暴露符号，但主进程和插件的符号解析顺序可能导致未定义行为

这就是为什么你的问题会随机出现——微小的代码修改会改变栈布局，刚好避开冲突区域时就成功，反之就崩溃。Valgrind能提高成功率也是因为它修改了内存分配逻辑，减少了冲突概率，但本质没解决问题。

具体修复步骤 #

1. 提前在主进程加载JVM库 #

不要等到插件里才初始化JVM，在主进程启动时就预加载libjvm.so，确保JVM的全局状态在插件加载前就完成初始化：

方式一：运行时用LD_PRELOAD

LD_PRELOAD=/usr/lib64/openjdk-25/lib/server/libjvm.so ./loader

方式二：在loader.c中主动加载

#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>

// 提前加载JVM库，确保全局状态初始化
static void preload_jvm() {
    void *jvm_lib = dlopen("/usr/lib64/openjdk-25/lib/server/libjvm.so", RTLD_NOW|RTLD_GLOBAL);
    if (!jvm_lib) {
        fprintf(stderr, "Failed to preload libjvm.so: %s\n", dlerror());
        exit(EXIT_FAILURE);
    }
}

int main(int argc, char **argv){
    preload_jvm(); // 先加载JVM库，再加载插件
    void *plugin;
    int(*entry_point)();
    
    plugin = dlopen("./plugin.so", RTLD_NOW|RTLD_GLOBAL);
    if(!plugin){
        fprintf(stderr, "dlopen() failed: %s\n", dlerror());
        return EXIT_FAILURE;
    }
    
    entry_point = dlsym(plugin, "entry_point");
    if(!entry_point){
        fprintf(stderr, "dlsym() failed\n");
        return EXIT_FAILURE;
    }
    
    entry_point();
    entry_point();
    printf("Back without crashing!\n");
    return EXIT_SUCCESS;
}

2. 给主线程分配足够大的栈空间 #

JVM初始化需要至少16MB的栈，主进程默认栈通常只有8MB，你之前的setrlimit可能没生效是因为调用时机不对——必须在主线程启动时就设置：
在loader.c的main开头添加：

#include <sys/resource.h>

int main(int argc, char **argv){
    struct rlimit rl;
    // 获取当前栈限制
    if (getrlimit(RLIMIT_STACK, &rl) == -1) {
        perror("getrlimit failed");
        return EXIT_FAILURE;
    }
    // 设置栈大小为32MB（留足够冗余）
    rl.rlim_cur = 32 * 1024 * 1024;
    if (setrlimit(RLIMIT_STACK, &rl) == -1) {
        perror("setrlimit failed");
        return EXIT_FAILURE;
    }
    
    preload_jvm(); // 后续代码不变
    // ...
}

或者运行前用ulimit临时调整：

ulimit -s 32768 # 设置栈为32MB
./loader

3. 调整Meson构建的链接参数 #

确保插件链接时能完整获取JVM的符号，避免符号丢失导致的未定义行为：
修改Meson构建文件的shared_library部分：

shared_library('plugin', 'plugin.c', 
    name_prefix: '', 
    build_rpath: java_runpath, 
    dependencies: jni_dep,
    link_args: ['-Wl,--whole-archive'] + jni_dep.get_link_args() + ['-Wl,--no-whole-archive']
)

4. 确保JVM初始化在主线程执行 #

JNI_CreateJavaVM必须在进程的主线程中调用，你的测试代码里这点是对的，但如果实际场景中插件的入口函数是在子线程调用的，一定要改到主线程执行初始化。

终极方案：换架构（如果以上方法仍不稳定） #

如果必须在C插件中调用Java，更可靠的架构是：

1. 主进程先启动JVM，保存JavaVM实例
2. 加载插件时，通过JNI_GetCreatedJavaVMs让插件获取已有的JVM实例，而不是自己创建
3. 或者把Java代码封装成独立进程，通过IPC（管道、Socket）和C插件通信，完全避开JVM在插件中初始化的问题

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