使用JNI从Java调用本机（C+；+；）函数时发生访问冲突：这是我的代码的问题还是已知问题？ 我有一个本地函数，在C++代码中定义，它在java中调用（在C++代码调用java代码之后）。

（1） C++中本机函数的声明/定义：

// 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语言中本机函数的注册++

// 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中本机函数的声明：

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

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

（4） 在Java代码中调用本机函数：

// 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%成功地工作，并且已经工作了很长时间。我刚刚注意到，在VisualStudio2010的调试器中运行时，报告了访问冲突。简单地注释掉Java中对本机函数的调用，就会导致访问冲突消失

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

但是，我想确认我的代码没有可能的问题

*附录*

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

以下是输出窗口中的消息：

EncoderCoder.exe中0x03fbb256处的首次机会异常： 0xC0000005:访问冲突读取位置0x003d0100

*第二附录*

<>我发现，当C++应用程序仍然连接到JVM，并且我从C++应用程序再次执行相同的代码（导致调用相同的java代码，这又导致java代码调用相同的JNI函数）时，访问冲突不会出现。 （在我的实际程序中，有许多不同的本机函数在许多不同的类中调用，因此，在访问违反报告时准确地隔离，并且当它被停止报告时不是简单的，而是通过相同的功能的第三次运行而不退出C++应用程序，使用相同的加载JVM，在那里，e无首次访问冲突错误（也无普通访问冲突错误）

这让我相信，结合下面Ben Voigt的回答（以及相关的评论），JVM代码确实会在正常处理过程中导致第一次机会异常（访问冲突），这不是我的代码的问题

*附录3*

发件人：

第一次机会异常消息通常并不意味着存在异常 代码中的问题

---

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

这是一个未处理的问题吗访问冲突，或者如果继续（让异常处理程序运行），调用是否继续

JIT编译器有一整套技巧来生成函数的本机代码，而不必每次调用都要付出条件代价来查看函数是否已JIT。其中一种技术是拦截第一次调用，因为它会生成访问冲突来触发JIT编译器。在生成代码之后有一次，未来的电话会无一例外地接通

---

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

应用心灵感应c电源…ESP电路驱动器…运行热…不，太好了！抱歉。我想我特别想知道这是否是一个已知的问题。显然，我的代码可能有问题，但如果它已经是一个已知的问题（VS 2010调试器报告错误访问冲突时还有其他已知的问题；例如），那么为什么要花时间查找重影呢？这不太可能是一个错误的报告。访问冲突可以而且有时确实作为正常程序控制流的一部分发生。您是否尝试过使用任何其他调试器（例如WinDbg）？代码甚至不会在调试器中停止。即使在调试模式下，它也不会出错。访问冲突的唯一指示是输出窗口中的一行。@DanNissenbaum:很可能您已将调试器配置为在未处理的访问冲突时停止，而不是第一次。这是“异常”对话框（从调试菜单IIRC访问）“1.7”并没有足够具体的版本信息。除此之外，重要的是运行时环境，而不是

javac

版本。更具体地说，JDK是：jdk1.7.0_09（x86）。例如，整个虚拟内存系统是建立在访问冲突之上的（至少是处理将内存交换到磁盘的部分）。这些页面错误是由操作系统处理的，您的程序从未见过。写入时复制是用于控制流的访问冲突的另一个示例。Win64内核反补丁系统至少在某些版本中使用访问冲突。我将为您找到链接。