java - 使用 JNI : Is this an issue with my code, 或已知问题从 Java 调用 native (C++) 函数的访问冲突？

Question

我有一个在我的 C++ 代码中定义的 native 函数，它在 Java 中调用(在 C++ 调用 Java 代码之后)。

(1) C++中native函数的声明/定义:

// C++ declaration/definition of the native function:

JNIEXPORT void JNICALL setEncoderProgressStatus (JNIEnv * env, jobject theClass, jlong jEncoderDecoderDlg, jstring status)
{
    // Do nothing.  Obviously, the real function does something.
    // But an access violation is reported even in the do-nothing case.
}

(2) C++中native函数的注册

// Registration of this function with JNI in the C++ code

JNINativeMethod commandLineEncoderMethods[] =
{
    {"setEncoderProgressStatus","(JLjava/lang/String;)V", (void*)setEncoderProgressStatus}
};

// pEnv is a valid JNIEnv *
// jCommandLineEncoderClass has already been initialized
pEnv->RegisterNatives(jCommandLineEncoderClass, commandLineEncoderMethods, sizeof(commandLineEncoderMethods)/sizeof(JNINativeMethod))

(3) Java中native函数的声明:

// The Java code, in turn, declares the native function as follows:

public static native void setEncoderProgressStatus(long EncoderDecoderDlg, String status);

(4) 在Java代码中调用native函数:

// Finally, the Java code calls the native function as follows:

// The real code passes different args,
// but an access violation is reported even in the do-nothing case.
// Commenting out the following line of code makes the access violation disappear.

setEncoderProgressStatus(0, "");

请注意，此代码 100% 成功运行，并且已经运行了很长时间。刚注意到在Visual Studio 2010的调试器中运行时，报访问冲突。只需在 Java 中注释掉对 native 函数的调用，就会导致访问冲突消失。

如果我知道这是在 VS 2010 中以 Debug模式运行应用程序时 JNI 的已知“侥幸”，并且它不代表我的代码有问题，那么我会感到满意。

但是，我想确认我的代码没有任何问题。

...

* 附录 *

访问冲突不会导致程序执行停止。相反，访问冲突的唯一指示是“输出”窗口中的一行。我不确定这是否意味着访问冲突已得到处理；但是，我猜这意味着它已被处理。然而，即使它被处理了，我想知道它是否一定表明我的代码存在问题。

这是输出窗口中的消息:

First-chance exception at 0x03fbb256 in EncoderDecoder.exe: 0xC0000005: Access violation reading location 0x003d0100

...

* 第二个附录 *

我发现当 C++ 应用程序保持连接到 JVM 时，我再次从 C++ 应用程序执行相同的代码(导致调用相同的 Java 代码，这反过来又导致 Java 代码调用相同的 JNI 函数)，访问冲突不会出现。

(在我的实际程序中，在许多不同的类中调用了许多不同的 native 函数，因此要准确地隔离报告访问冲突的时间和停止报告的时间并不简单 - 但在第三个在不退出 C++ 应用程序的情况下运行相同的功能，使用相同的加载 JVM，没有第一次机会访问冲突错误(也没有普通的访问冲突错误)。

这让我相信，结合下面 Ben Voigt 的回答(和相关评论)，JVM 代码确实导致第一次机会异常(访问冲突) 作为其正常处理的一部分发生，这不是我的代码的问题。

...

* 附录 3 *

来自 http://blogs.msdn.com/b/davidklinems/archive/2005/07/12/438061.aspx :

First chance exception messages most often do not mean there is a problem in the code.

仍然有可能碰巧是访问冲突的第一次异常更有可能代表一个真正的问题，在这种情况下我的问题仍然悬而未决；但是 - 我认为证据表明这可能就是 JVM 的工作方式，并不代表我的代码存在问题。

Answer 1

这是未处理的访问冲突，还是如果您继续(让异常处理程序运行)调用是否继续？

JIT 编译器有一大堆技巧来为函数生成 native 代码，而无需在每次调用时都付出条件成本来查看函数是否已进行 JIT 处理。一种这样的技术是拦截第一次调用，因为它会生成访问冲突来触发 JIT 编译器。代码生成一次后，以后的调用将无一异常(exception)地通过。

我不了解是否有任何 Java JIT 编译器确实这样做了，但是如果不提供有关您正在运行的 JIT 的具体信息，您将无法获得明确的答案。是 Sun/Oracle HotSpot 编译器吗？ x86 或 x86_64 或其他平台？您深入了解因实现而异的实现细节。