Java调用C++本地方法触发pthread_mutex断言错误的排查求助

错误信息 #

java: ../nptl/pthread_mutex_lock.c:81: __pthread_mutex_cond_lock: Assertion `mutex->__data.__owner == 0' failed.
Aborted (core dumped)

场景背景 #

Java代码调用C++开发的数据提取器，核心调用逻辑如下：

public int run() {
    while(this.TSbfr.canAdd() && this.hasMore())
        extractNext();
    return !hasMore() ? 1:0;
}

本地方法调用位于extractNext()中，该方法会被循环多次调用。

• 用numactl --physcpubind=+1强制JVM单核心运行时程序正常；
• 多核心运行时不定期触发上述断言错误；
• 未显式用多线程调用extractNext()，但推测JVM可能因本地调用耗时久，为后续调用创建新线程；
• 尝试Java层synchronized锁无效。

常见诱因 #

• C++本地代码线程安全缺陷：本地代码中的互斥锁未适配多线程场景，比如：
  • 锁被同一线程重复获取但未使用可重入锁；
  • 锁在未释放时被其他线程尝试获取；
  • 锁的初始化、销毁逻辑存在竞态条件。
• JVM隐式线程调度：即使Java层未显式开启线程，JNI调用耗时过长时，JVM可能触发后台线程（如GC、JIT编译线程）或切换JNI调用的执行线程，导致本地代码被不同Java线程调用。
• NUMA架构内存一致性问题：多核心运行时，不同核心的缓存一致性差异可能导致本地代码读取锁状态时出现异常，触发断言失败。

排查思路 #

1. 检查C++本地锁实现：
   • 确认互斥锁是否为可重入类型（比如用PTHREAD_MUTEX_RECURSIVE属性初始化）；
   • 核对锁的获取与释放逻辑是否严格配对，避免漏释放或重复释放；
   • 排查是否存在多线程非法修改锁状态的情况。
2. 追踪JNI调用的线程上下文：
   • 在本地代码中用pthread_self()打印当前线程ID，确认是否有不同线程进入同一临界区；
   • 若发现多线程调用，需在本地代码层添加线程安全保护（如全局锁、线程本地存储），Java层synchronized无法约束本地代码的线程执行逻辑。
3. 验证NUMA相关影响：
   • 尝试用numactl --interleave=all关闭NUMA节点绑定，观察是否还会触发错误；
   • 检查本地代码中是否有内存绑定逻辑，导致多核心下锁状态异常。
4. 分析核心转储文件：
   • 用gdb加载core文件，查看断言失败时的调用栈，确认锁的当前所有者、调用线程信息，明确触发断言的具体场景。

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