Java 层面的多线程调用会直接传递到 DLL 层面，DLL 不是为多线程设计的，那么直接在多个 Java 线程中调用它会导致不可预测的后果，如数据损坏、程序崩溃或死锁。
下面我们来详细分解这个问题,并提供最佳实践。
- Java 不提供线程安全保护：当你的 Java 代码通过 JNI (Java Native Interface) 调用一个本地方法（即 DLL 中的函数）时，JVM 不会对该调用做任何特殊的线程同步处理，它就像一个直接的函数调用。
- 线程安全的责任在 DLL：这个本地函数是否可以被多个线程安全地并发调用，完全取决于该函数的编写者（通常是 C/C++ 开发者），如果该函数是“线程安全”的，那么你就可以在多个 Java 线程中调用它；如果不是，你就必须自己在外部进行同步控制。
深入分析：不同情况下的多线程行为
我们可以将 DLL 中的函数分为以下几种情况来讨论：
纯函数
- 定义：这种函数只依赖于输入参数，不修改任何外部状态（全局变量、静态变量、文件等），并且对于相同的输入总是返回相同的输出。
- 多线程安全性：绝对安全。
- 示例：一个数学计算函数
double calculateSquare(double num)。 - 说明：每个线程调用它时，都像在独立的世界里工作，不会相互干扰，这是最理想、最易于在多线程环境中使用的函数。
访问共享可变状态的函数
-
定义：函数会读取或修改全局变量、静态变量、或者指向堆上共享内存的指针。
-
多线程安全性：通常不安全。
（图片来源网络，侵删） -
示例：一个简单的计数器。
// Counter.dll int counter = 0; JNIEXPORT void JNICALL Java_MyClass_increment(JNIEnv *, jobject) { counter++; // 这是一个“读-改-写”操作，不是原子的 } -
问题：当两个 Java 线程几乎同时调用
increment()方法时，可能会发生“竞态条件”（Race Condition）。- 线程 A 读取
counter(值为 0)。 - 线程 B 也读取
counter(值也为 0)。 - 线程 A 将
counter加 1，并写回 (值为 1)。 - 线程 B 也将
counter加 1，并写回 (值也为 1)。 - 结果：
counter的值是 1，而不是预期的 2，数据被破坏了。
- 线程 A 读取
使用线程本地存储的函数
-
定义：函数使用操作系统提供的“线程本地存储”（Thread-Local Storage, TLS）来存储数据，每个线程都有自己独立的数据副本。
-
多线程安全性：通常安全。
（图片来源网络，侵删） -
示例：C++ 中的
thread_local关键字或 Windows API 中的TlsAlloc。// 在 Windows 上使用 TLS DWORD g_tlsIndex; BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) { if (fdwReason == DLL_PROCESS_ATTACH) { g_tlsIndex = TlsAlloc(); } return TRUE; } JNIEXPORT void JNICALL Java_MyClass_setThreadValue(JNIEnv *, jobject, jint value) { TlsSetValue(g_tlsIndex, (LPVOID)value); } -
说明：每个线程调用
setThreadValue时，操作的都是自己私有的内存空间，不会影响其他线程，这是一种在 C/C++ 中实现线程安全常用且高效的方法。
函数内部使用自己的同步机制
-
定义：函数内部已经实现了互斥锁（如
std::mutex,CRITICAL_SECTION）来保护共享资源的访问。 -
多线程安全性：安全。
-
示例：
#include <mutex> std::mutex mtx; int shared_counter = 0; JNIEXPORT void JNICALL Java_MyClass_incrementSafe(JNIEnv *, jobject) { mtx.lock(); // 加锁 shared_counter++; // 安全操作 mtx.unlock(); // 解锁 } -
说明：虽然函数本身是线程安全的，但这种性能开销较大，因为它会强制所有调用该函数的线程串行化执行，Java 层面再进行同步，就会造成“双重加锁”，严重影响性能。
Java 层面的解决方案
如果你无法修改 DLL 的源代码（比如它是一个第三方库），并且它不是线程安全的，那么你必须在 Java 代码中进行同步控制。
使用 synchronized 关键字（最简单）
这是最直接的方法,确保在任何时刻只有一个 Java 线程可以进入 JNI 调用。
public class MyClass {
// 假设这个 native 方法调用的是非线程安全的 DLL 函数
private native void unsafeIncrement();
// 使用 synchronized 包装 native 调用
public synchronized void safeIncrement() {
unsafeIncrement();
}
}
缺点：粒度太大，会使得所有调用 safeIncrement() 的线程排队等待，即使它们可能操作的是不同的资源，导致性能瓶颈。
使用 ReentrantLock（更灵活）
ReentrantLock 提供了比 synchronized 更多的功能，例如可中断的锁、尝试获取锁（tryLock）和公平锁等。
import java.util.concurrent.locks.ReentrantLock;
public class MyClass {
private native void unsafeIncrement();
private final ReentrantLock lock = new ReentrantLock();
public void safeIncrement() {
lock.lock(); // 获取锁
try {
unsafeIncrement();
} finally {
lock.unlock(); // 确保锁一定会被释放
}
}
}
优点：灵活性更高，可以实现更精细的并发控制。
使用并发集合（特定场景）
DLL 函数的目的是操作一个共享的数据结构，而你希望将这个数据结构也放在 Java 管理下，可以考虑使用 Java 的并发集合（如 ConcurrentHashMap），但请注意，DLL 函数需要一次性操作整个数据结构，这个方案可能不适用。
- 优先使用纯函数：在设计或选择 DLL 时，优先选择那些不依赖共享状态的纯函数，它们天生就是线程安全的。
- 咨询 DLL 文档：在使用第三方 DLL 之前，务必查阅其文档，了解其是否支持多线程调用，文档通常会明确说明其线程安全级别。
- Java 层同步：DLL 不是线程安全的，且你无法修改它，那么必须在 Java 层面进行同步，选择
synchronized或ReentrantLock来保护对 JNI 方法的调用。 - 避免双重加锁：DLL 内部已经有锁，而 Java 层面也加了锁，这会造成严重的性能问题，尽量让锁的层级清晰，要么在 DLL 内部处理，要么在 Java 外部处理。
- 注意资源生命周期：在多线程环境中，确保 native 方法分配的资源（如内存、文件句柄）被正确释放，避免内存泄漏或资源耗尽。
一个完整的代码示例
下面是一个简单的例子,展示了非线程安全的 DLL 函数以及如何在 Java 中使用 synchronized 来使其安全。
Java 代码 (MyClass.java)
public class MyClass {
// 加载 DLL
static {
System.loadLibrary("MyNativeLib");
}
// 声明 native 方法
private native void incrementCounter();
// 一个共享的计数器，用于演示
private int javaCounter = 0;
public static void main(String[] args) throws InterruptedException {
MyClass instance = new MyClass();
// 创建多个线程来并发调用 native 方法
Runnable task = () -> {
for (int i = 0; i < 1000; i++) {
// 调用 synchronized 方法来保证线程安全
instance.safeIncrement();
}
};
Thread t1 = new Thread(task);
Thread t2 = new Thread(task);
t1.start();
t2.start();
t1.join();
t2.join();
// 预期结果是 2000
System.out.println("Final Java Counter: " + instance.javaCounter);
}
// 使用 synchronized 包装 native 调用
public synchronized void safeIncrement() {
incrementCounter();
javaCounter++;
}
}
C/C++ 代码 (MyNativeLib.c)
#include <stdio.h>
// 这是一个全局变量，所有线程共享，是竞态条件的根源
int native_counter = 0;
JNIEXPORT void JNICALL Java_MyClass_incrementCounter(JNIEnv *env, jobject obj) {
// 模拟一个“读-改-写”操作
int temp = native_counter;
temp++;
native_counter = temp;
// 在实际应用中，这里可能会有更复杂的操作
// printf("Native counter is now: %d\n", native_counter); // 如果取消打印，会看到输出混乱
}
如何运行：
- 将
MyNativeLib.c编译成MyNativeLib.dll(Windows) 或libMyNativeLib.so(Linux)。 - 将生成的库文件放在 Java 的
java.library.path中（与MyClass.class同级目录）。 - 运行
MyClass。
结果分析：
- 如果直接调用
incrementCounter()而不通过safeIncrement()，由于存在竞态条件，javaCounter的最终值很可能小于 2000，native_counter的值也是不可预测的。 - 通过
synchronized保护的safeIncrement()方法，javaCounter的最终结果会是正确的 2000，因为synchronized确保了对incrementCounter()和javaCounter++这两个操作的原子性（在单个线程视角下）。
重要提示：这个例子中的 synchronized 保证了 javaCounter++ 的安全，同时也间接保护了对 incrementCounter() 的调用，但请注意，native_counter 本身在 DLL 内部，其值依然会因为竞态条件而不准确，这再次说明了 JNI 调用的线程安全责任在于 DLL 本身，Java 的同步只能保护 Java 代码部分。
