1. IT分享知识网首页

深入OpenJDK源码核心探秘Unsafe(含JNI完整使用流程)

老牧童 • • 未分类 • 阅读 118

深入OpenJDK源码核心探秘Unsafe(含JNI完整使用流程)一、介绍在Java中，sun.misc.Unsafe可以认为是用于JDK内部使用的工具类，它将一些需要使用native语言实现的功能通过java方法暴露出来，这些方法比较“危险”，因为它们可以直接修改内存中的值。通常情况下，我们并不能直接在程序中使用Unsafe，Unsafe的构造方法被私有化，语法层面上只能通过其提供的公共静态方法getUnsafe获取Unsafe实例：theUnsafe…

大家好，欢迎来到IT知识分享网。

一、介绍

在Java中，sun.misc.Unsafe可以认为是用于JDK内部使用的工具类，它将一些需要使用native语言实现的功能通过java方法暴露出来，这些方法比较“危险”，因为它们可以直接修改内存中的值。

通常情况下，我们并不能直接在程序中使用Unsafe，Unsafe的构造方法被私有化，语法层面上只能通过其提供的公共静态方法getUnsafe获取Unsafe实例：theUnsafe，theUnsafe在静态代码块被初始化，所以其是一个单例，如下所示：

public final class Unsafe {
    //静态的、私有的实例字段
    private static final Unsafe theUnsafe;
......
    //私有化构造器
    private Unsafe() {
        }

......
    //对外提供静态方法获取实例
    @CallerSensitive
    public static Unsafe getUnsafe() {
        Class var0 = Reflection.getCallerClass();
        //检查是否允许访问Unsafe
        if (!VM.isSystemDomainLoader(var0.getClassLoader())) {
            throw new SecurityException("Unsafe");
        } else {
            return theUnsafe;
        }
    }
......
    static {
        ......    
        //初始化Unsafe实例
        theUnsafe = new Unsafe();
        ......
    }
}

从Unsafe的代码中可以看出，通过getUnsafe方法获取Unsafe单例是唯一的“正规”途径，而该方法中对调用者classLoader做了检查，我们看一下检查代码：VM.isSystemDomainLoader：

public static boolean isSystemDomainLoader(ClassLoader var0) {
    return var0 == null;
}

逻辑比较简单，主要是看classLoader是否为null，也就是判断该类是不是由BootStrap加载，如果不是的话，则不具有访问Unsafe的权限，随即抛出SecurityException异常。

import sun.misc.Unsafe;

public class Test{

    public static void main(String[] args){
        Unsafe unsafe = Unsafe.getUnsafe();
    }
}

上述代码尝试获取一个Unsafe实例，会抛出异常异常：

Exception in thread "main" java.lang.SecurityException: Unsafe
	at sun.misc.Unsafe.getUnsafe(Unsafe.java:90)

二、使用Unsafe

虽然我们没有权限调用Unsafe#getUnsafe方法，但是我们还是有办法能够获取到Unsafe实例。既然theUnsafe字段在静态代码块中被初始化了，并且它是一个静态变量，那么我们可以直接通过反射获取该字段值。

在下面的代码中，我们先获取到了Unsafe实例，并且通过Unsafe#putInt方法将Test实例的value字段设置为100，然后通过Unsafe#getIntVolatile方法获取该值，并输出：

public class Test {
    private int value;

    public static void main(String[] args) throws Exception {
        //获取theUnsafe字段
        Field unsafeField = Unsafe.class.getDeclaredField("theUnsafe");
        //私有变量设置访问权限
        unsafeField.setAccessible(true);
        //theUnsafe是静态变量，直接通过Field#get(null)获取
        Unsafe theUnsafe = (Unsafe) unsafeField.get(null);

        //创建Test实例
        Test test = new Test();
        //获取value字段在Test中的偏移量
        long fieldOffset = theUnsafe.objectFieldOffset(Test.class.getDeclaredField("value"));
        //直接操作该内存，设置值
        theUnsafe.putInt(test, fieldOffset, 100);
        //获取该偏移的值
        System.out.println(theUnsafe.getIntVolatile(test, fieldOffset));
    }
}

控制台输出为：100

三、源码实现

Unsafe中的所有基础方法都属于native方法，这里我们就不一一解析了，就看一下JUC中经常使用的CAS源码实现即可，至于其它方法，读者朋友可以根据自身情况酌情研究。

在openjdk的源码中，Unsafe主要的实现代码在unsafe.cpp中，其中包含了native方法操作内存的实现细节。这里我们主要看看以下两个native方法的实现：

    public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);

    public final native boolean compareAndSwapLong(Object var1, long var2, long var4, long var6);

2.1 compareAndSwapInt

我们首先看看compareAndSwapInt方法在openjdk中的实现：

UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint e, jint x))
  UnsafeWrapper("Unsafe_CompareAndSwapInt");
  oop p = JNIHandles::resolve(obj);
  jint* addr = (jint *) index_oop_from_field_offset_long(p, offset);
  return (jint)(Atomic::cmpxchg(x, addr, e)) == e;
UNSAFE_END

首先是JNIHandles::resolve(obj)方法。该方法定义在jniHandles.hpp中：

inline oop JNIHandles::resolve(jobject handle) {
  oop result = (handle == NULL ? (oop)NULL : *(oop*)handle);
  assert(result != NULL || (handle == NULL || !CheckJNICalls || is_weak_global_handle(handle)), "Invalid value read from jni handle");
  assert(result != badJNIHandle, "Pointing to zapped jni handle area");
  return result;
};

可以看到，该方法定义为一个内联函数，没有做什么复杂的事儿，就是把jobject参数转成了oop。

然后调用index_oop_from_field_offset_long(p, offset);方法，其中offset为修改的字段在对象所占内存中的偏移位置（相关信息可参考Java对象内存布局），最终得到的addr就是该字段在内存中的位置，这里可以简单理解为对象地址加上offset。

得到字段地址addr之后就会调用核心的Atomic::cmpxchg方法，该方法定义在atomic.hpp中，除了cmpxchg，还有xchg、cmpxchg_ptr等等，我们简单看一下：

class Atomic : AllStatic {
 public:
  // Atomic operations on jlong types are not available on all 32-bit
  // platforms. If atomic ops on jlongs are defined here they must only
  // be used from code that verifies they are available at runtime and
  // can provide an alternative action if not - see supports_cx8() for
  // a means to test availability.

  // Atomically store to a location
  inline static void store    (jbyte    store_value, jbyte*    dest);
  inline static void store    (jshort   store_value, jshort*   dest);
  inline static void store    (jint     store_value, jint*     dest);
  // See comment above about using jlong atomics on 32-bit platforms
  inline static void store    (jlong    store_value, jlong*    dest);
  inline static void store_ptr(intptr_t store_value, intptr_t* dest);
  inline static void store_ptr(void*    store_value, void*     dest);

  inline static void store    (jbyte    store_value, volatile jbyte*    dest);
  inline static void store    (jshort   store_value, volatile jshort*   dest);
  inline static void store    (jint     store_value, volatile jint*     dest);
  // See comment above about using jlong atomics on 32-bit platforms
  inline static void store    (jlong    store_value, volatile jlong*    dest);
  inline static void store_ptr(intptr_t store_value, volatile intptr_t* dest);
  inline static void store_ptr(void*    store_value, volatile void*     dest);

  // See comment above about using jlong atomics on 32-bit platforms
  inline static jlong load(volatile jlong* src);

  // Atomically add to a location, return updated value
  inline static jint     add    (jint     add_value, volatile jint*     dest);
  inline static intptr_t add_ptr(intptr_t add_value, volatile intptr_t* dest);
  inline static void*    add_ptr(intptr_t add_value, volatile void*     dest);
  // See comment above about using jlong atomics on 32-bit platforms
         static jlong    add    (jlong    add_value, volatile jlong*    dest);

  // Atomically increment location
  inline static void inc    (volatile jint*     dest);
         static void inc    (volatile jshort*   dest);
  inline static void inc_ptr(volatile intptr_t* dest);
  inline static void inc_ptr(volatile void*     dest);

  // Atomically decrement a location
  inline static void dec    (volatile jint*     dest);
         static void dec    (volatile jshort*    dest);
  inline static void dec_ptr(volatile intptr_t* dest);
  inline static void dec_ptr(volatile void*     dest);

  // Performs atomic exchange of *dest with exchange_value.  Returns old prior value of *dest.
  inline static jint         xchg(jint         exchange_value, volatile jint*         dest);
         static unsigned int xchg(unsigned int exchange_value, volatile unsigned int* dest);

  inline static intptr_t xchg_ptr(intptr_t exchange_value, volatile intptr_t* dest);
  inline static void*    xchg_ptr(void*    exchange_value, volatile void*   dest);

  // Performs atomic compare of *dest and compare_value, and exchanges *dest with exchange_value
  // if the comparison succeeded.  Returns prior value of *dest.  Guarantees a two-way memory
  // barrier across the cmpxchg.  I.e., it's really a 'fence_cmpxchg_acquire'.
         static jbyte    cmpxchg    (jbyte    exchange_value, volatile jbyte*    dest, jbyte    compare_value);
  inline static jint     cmpxchg    (jint     exchange_value, volatile jint*     dest, jint     compare_value);
  // See comment above about using jlong atomics on 32-bit platforms
  inline static jlong    cmpxchg    (jlong    exchange_value, volatile jlong*    dest, jlong    compare_value);

         static unsigned int cmpxchg(unsigned int exchange_value,
                                     volatile unsigned int* dest,
                                     unsigned int compare_value);

  inline static intptr_t cmpxchg_ptr(intptr_t exchange_value, volatile intptr_t* dest, intptr_t compare_value);
  inline static void*    cmpxchg_ptr(void*    exchange_value, volatile void*     dest, void*    compare_value);
};

cmpxchg实现在atomic.cpp中，最终会根据具体的宿主环境内联具体的实现，具体我们参照include的atomic.inline.hpp头文件：

// Linux
#ifdef TARGET_OS_ARCH_linux_x86
# include "atomic_linux_x86.inline.hpp"
#endif
#ifdef TARGET_OS_ARCH_linux_sparc
# include "atomic_linux_sparc.inline.hpp"
#endif
#ifdef TARGET_OS_ARCH_linux_zero
# include "atomic_linux_zero.inline.hpp"
#endif
#ifdef TARGET_OS_ARCH_linux_arm
# include "atomic_linux_arm.inline.hpp"
#endif
#ifdef TARGET_OS_ARCH_linux_ppc
# include "atomic_linux_ppc.inline.hpp"
#endif

// Solaris
#ifdef TARGET_OS_ARCH_solaris_x86
# include "atomic_solaris_x86.inline.hpp"
#endif
#ifdef TARGET_OS_ARCH_solaris_sparc
# include "atomic_solaris_sparc.inline.hpp"
#endif

// Windows
#ifdef TARGET_OS_ARCH_windows_x86
# include "atomic_windows_x86.inline.hpp"
#endif

// BSD
#ifdef TARGET_OS_ARCH_bsd_x86
# include "atomic_bsd_x86.inline.hpp"
#endif
#ifdef TARGET_OS_ARCH_bsd_zero
# include "atomic_bsd_zero.inline.hpp"
#endif

#endif // SHARE_VM_RUNTIME_ATOMIC_INLINE_HPP

以x86的linux环境为例，其引入的是atomic_linux_x86.inline.hpp头文件，其中实现的内联函数较多，我们先只看看jint的cmpxchg函数实现：

inline jint     Atomic::cmpxchg    (jint     exchange_value, volatile jint*     dest, jint     compare_value) {
  int mp = os::is_MP();
  __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl %1,(%3)"
                    : "=a" (exchange_value)
                    : "r" (exchange_value), "a" (compare_value), "r" (dest), "r" (mp)
                    : "cc", "memory");
  return exchange_value;
}

第一步调用了os::is_MP()函数，该函数定义在os.hpp中，主要是判断当前环境是否为多处理器环境：

  // Interface for detecting multiprocessor system
  static inline bool is_MP() {
    assert(_processor_count > 0, "invalid processor count");
    return _processor_count > 1 || AssumeMP;
  }

使用__asm__ volatile嵌入汇编代码片段，一个内联汇编表达式分为四个部分，以：进行分隔。使用__asm__来声明表达式，volatile则保证指令不会被gcc优化影响，关于gcc内联汇编的更多内容不是本文的主题（博主也忘差不多了o(╯□╰)o），感兴趣的朋友可以自行了解。cmpxchgl指令则是x86的比较并交换指令，如果是多处理器会使用lock前缀，关于lock前缀，我们在总结volatile的博文中介绍过，其可以达到一个内存屏障的效果，也可以参照intel手册。

从上面也看到了，Atomic::cmpxchg的方法的返回值是内存中的

2.2 compareAndSwapLong

同样先在unsafe.cpp中找到compareAndSwapLong的实现：

UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapLong(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jlong e, jlong x))
  UnsafeWrapper("Unsafe_CompareAndSwapLong");
  Handle p (THREAD, JNIHandles::resolve(obj));
  jlong* addr = (jlong*)(index_oop_from_field_offset_long(p(), offset));
  if (VM_Version::supports_cx8())
    return (jlong)(Atomic::cmpxchg(x, addr, e)) == e;
  else {
    jboolean success = false;
    ObjectLocker ol(p, THREAD);
    if (*addr == e) { *addr = x; success = true; }
    return success;
  }
UNSAFE_END

和compareAndSwapInt不一样的是，jlong类型的CAS操作需要判断宿主平台是否支持8字节的CAS操作，也就是通过VM_Version::supports_cx8方法进行判断。该方法定义在vm_version.hpp中：

  // does HW support an 8-byte compare-exchange operation?
  static bool supports_cx8()  {
#ifdef SUPPORTS_NATIVE_CX8
    return true;
#else
    return _supports_cx8;
#endif
  }

其中_supports_cx8默认为false，在相应的平台下会有对应的方法进行赋值，比如在x86下，会在vm_version_x86.cpp中调用supports_cmpxchg8()方法进行赋值，该方法定义在vm_version_x86.hpp中：

  static bool supports_cmpxchg8() { return (_cpuFeatures & CPU_CX8) != 0; }

这个_cpuFeatures可以理解为cpu的一些属性，其在vm_version_x86.cpp中处理：如果支持CPUID，则会通过调用feature_flags()方法获取：

if (cpu_family() > 4) { // it supports CPUID
      _cpuFeatures = feature_flags();
      // Logical processors are only available on P4s and above,
      // and only if hyperthreading is available.
      _logical_processors_per_package = logical_processor_count();
    }

我们来看一下feature_flags方法：

  static uint32_t feature_flags() {
    uint32_t result = 0;
    if (_cpuid_info.std_cpuid1_edx.bits.cmpxchg8 != 0)
      result |= CPU_CX8;
    if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0)
      result |= CPU_CMOV;
    if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() &&
        _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0))
      result |= CPU_FXSR;
    // HT flag is set for multi-core processors also.
    if (threads_per_core() > 1)
      result |= CPU_HT;
    if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() &&
        _cpuid_info.ext_cpuid1_edx.bits.mmx != 0))
      result |= CPU_MMX;
    if (_cpuid_info.std_cpuid1_edx.bits.sse != 0)
      result |= CPU_SSE;
    if (_cpuid_info.std_cpuid1_edx.bits.sse2 != 0)
      result |= CPU_SSE2;
    if (_cpuid_info.std_cpuid1_ecx.bits.sse3 != 0)
      result |= CPU_SSE3;
    if (_cpuid_info.std_cpuid1_ecx.bits.ssse3 != 0)
      result |= CPU_SSSE3;
    if (_cpuid_info.std_cpuid1_ecx.bits.sse4_1 != 0)
      result |= CPU_SSE4_1;
    if (_cpuid_info.std_cpuid1_ecx.bits.sse4_2 != 0)
      result |= CPU_SSE4_2;
    if (_cpuid_info.std_cpuid1_ecx.bits.popcnt != 0)
      result |= CPU_POPCNT;
    if (_cpuid_info.std_cpuid1_ecx.bits.avx != 0 &&
        _cpuid_info.std_cpuid1_ecx.bits.osxsave != 0 &&
        _cpuid_info.xem_xcr0_eax.bits.sse != 0 &&
        _cpuid_info.xem_xcr0_eax.bits.ymm != 0) {
      result |= CPU_AVX;
      if (_cpuid_info.sef_cpuid7_ebx.bits.avx2 != 0)
        result |= CPU_AVX2;
    }
    if (_cpuid_info.std_cpuid1_edx.bits.tsc != 0)
      result |= CPU_TSC;
    if (_cpuid_info.ext_cpuid7_edx.bits.tsc_invariance != 0)
      result |= CPU_TSCINV;
    if (_cpuid_info.std_cpuid1_ecx.bits.aes != 0)
      result |= CPU_AES;
    if (_cpuid_info.sef_cpuid7_ebx.bits.erms != 0)
      result |= CPU_ERMS;
    if (_cpuid_info.std_cpuid1_ecx.bits.clmul != 0)
      result |= CPU_CLMUL;

    // AMD features.
    if (is_amd()) {
      if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) ||
          (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0))
        result |= CPU_3DNOW_PREFETCH;
      if (_cpuid_info.ext_cpuid1_ecx.bits.lzcnt != 0)
        result |= CPU_LZCNT;
      if (_cpuid_info.ext_cpuid1_ecx.bits.sse4a != 0)
        result |= CPU_SSE4A;
    }

    return result;
  }

从方法体中可以看到，如果从CPUID中判断到支持cmpxchg8，那么会将result和CPU_CX8进行按位或，CPU_CX8定义在枚举中，表示哪一位是cmpxchg8是否支持的标识：

  enum {
    CPU_CX8    = (1 << 0), // next bits are from cpuid 1 (EDX)
    CPU_CMOV   = (1 << 1),
    CPU_FXSR   = (1 << 2),
    CPU_HT     = (1 << 3),
    CPU_MMX    = (1 << 4),
    CPU_3DNOW_PREFETCH  = (1 << 5), // Processor supports 3dnow prefetch and prefetchw instructions
                                    // may not necessarily support other 3dnow instructions
    CPU_SSE    = (1 << 6),
    CPU_SSE2   = (1 << 7),
    CPU_SSE3   = (1 << 8), // SSE3 comes from cpuid 1 (ECX)
    CPU_SSSE3  = (1 << 9),
    CPU_SSE4A  = (1 << 10),
    CPU_SSE4_1 = (1 << 11),
    CPU_SSE4_2 = (1 << 12),
    CPU_POPCNT = (1 << 13),
    CPU_LZCNT  = (1 << 14),
    CPU_TSC    = (1 << 15),
    CPU_TSCINV = (1 << 16),
    CPU_AVX    = (1 << 17),
    CPU_AVX2   = (1 << 18),
    CPU_AES    = (1 << 19),
    CPU_ERMS   = (1 << 20), // enhanced 'rep movsb/stosb' instructions
    CPU_CLMUL  = (1 << 21) // carryless multiply for CRC
  } cpuFeatureFlags;

这里可以看到，用_cpuFeatures的最低位标识cmpxchg8，如果支持，那么将该位通过 | 操作设置为1，判断的时候像这样简单判断即可：

_cpuFeatures & CPU_CX8 != 0

我们回到Unsafe_CompareAndSwapLong处，如果支持cmpxchg8的话，那么和jint类似，会调用Atomic::cmpxchg方法实现CAS操作，一下是linux_x86下的内联实现：

inline jlong    Atomic::cmpxchg    (jlong    exchange_value, volatile jlong*    dest, jlong    compare_value) {
  bool mp = os::is_MP();
  __asm__ __volatile__ (LOCK_IF_MP(%4) "cmpxchgq %1,(%3)"
                        : "=a" (exchange_value)
                        : "r" (exchange_value), "a" (compare_value), "r" (dest), "r" (mp)
                        : "cc", "memory");
  return exchange_value;
}

注意前面jint的CAS使用的是cmpxchgl指令，而此处使用的是cmpxchgq指令。当然，如果不支持cmpxchg8的话，就只能自己处理，而且需要保证原子性，所以使用了ObjectLocker，上锁之后实现比较并交换逻辑即可：

jboolean success = false;
    ObjectLocker ol(p, THREAD);
    if (*addr == e) { *addr = x; success = true; }
    return success;

最后，CAS操作返回的是布尔类型的结果，使用ObjectLocker时，从代码上就很好理解，先比较地址上的值，如果相等则交换，返回true，否则返回false。而使用Atomic::cmpxchg时，结果是cmpxchg返回值和期望值比较的结果：

(Atomic::cmpxchg(x, addr, e)) == e

回到上面cmpxchg的内联实现，其返回的是exchange_value。关于cmpxchgl和cmpxchgq指令，如果期望值和当前值相等的话，那么会将新值写到内存地址，覆盖当前值，并且返回被覆盖的值（旧值，其实也是期望值）；如果期望值和当前值不相等，那么会返回最新的当前值。所以这个操作叫做比较并交换，不论比较的结果如何，都会“换出”内存地址的当前值。

所以，只有当返回的exchange_value和我们的期望值相等时，才表示指令执行成功了，否则表示该内存上的值被其它线程更新了，指令失败。

四、JNI实现

现在我们再回过头来看JNI（Java Native Interface），即Java本地接口，它能将Java与c/c++等本地代码进行集成，使得Java代码能够与其它编程语言进行相互操作。JNI是一个接口，类似于虚拟机规范，其并没有限制实现细节。

某一些功能我们可能无法用Java语言直接实现（或者说高效实现），那么就需要借助其他本地语言实现，我们只需要在Java中定义好接口(native)，JVM在调用方法时会根据指定的方法名从本地库中寻找具体的实现，这个实现可能由c++编写。

我们这里实现一个JNI调用的流程。

首先，我们编写Java文件，TestJNI.java：

class TestJNI{
	public native void say();
	static{
		System.loadLibrary("TestLib");
	}
	public static void main(String[] args){
		new TestJNI().say();
	}
}

在TestJNI.java中，我们定义了一个native方法say()，该方法我们会以c++实现。在static静态代码块中加载动态库，该库中需要包含say方法的本地实现，所以接下来我们需要组建TestLib动态库(TestLib.dll)。dll即Dynamic Link Library，可以想象为我们Java中的jar包，里面包含一系列可供他人调用的公用函数。

注：这里为了简单，我直接把TestJNI.java放到桌面上操作。

我们的native方法是定义在TestJNI.java中的，现在要用c++实现该方法，需要定义该方法的头文件，并且JNI对native方法的方法名有规范，并不能随便写，因为JVM寻找本地实现的时候有自己的规则。这样看来编写头文件还比较麻烦，好在jdk为我们提供了指令：javah，以快速创建该头文件。

C:\Users\Administrator\Desktop>javah TestJNI

C:\Users\Administrator\Desktop>

调用javah TestJNI之后，会生成一个TestJNI.h文件，我们来看一下文件内容：

/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class TestJNI */

#ifndef _Included_TestJNI
#define _Included_TestJNI
#ifdef __cplusplus
extern "C" {
#endif
/*
 * Class:     TestJNI
 * Method:    say
 * Signature: ()V
 */
JNIEXPORT void JNICALL Java_TestJNI_say
  (JNIEnv *, jobject);

#ifdef __cplusplus
}
#endif
#endif

我们看到TestJNI.h中引入了jni.h，该文件位于%JAVA_HOME%\include目录中：

深入OpenJDK源码核心探秘Unsafe(含JNI完整使用流程)

文件中定义了一个Java_TestJNI_say方法，JNIEnv*表示的是JNI本身，通过它可以调用jni.h中定义好的函数，jobject表示当前对象（实例对象或者class）。我们不用太过关注，知道这里定义了一个接口就行了。

有了头文件，接下来我们要开始编写实现、生成dll了，由于博主环境为64位，所以需要生成64位环境的dll，使用的IDE是Visual Studio 2010。

首先，选择文件-新建-项目，选择模板Visual C++、Win32控制台应用程序，项目名称为TestJNI.java中加载的库名TestLib，同时我们要清楚项目位置，这里使用的是默认配置：

深入OpenJDK源码核心探秘Unsafe(含JNI完整使用流程)

然后点击确定：

深入OpenJDK源码核心探秘Unsafe(含JNI完整使用流程)

这里点击“下一步”，然后再应用程序设置中，选择应用程序类型为DLL，附加选项为空项目，点击完成：

深入OpenJDK源码核心探秘Unsafe(含JNI完整使用流程)

这样项目就创建好，接下来我们设置64位环境。首先进入配置管理器：

深入OpenJDK源码核心探秘Unsafe(含JNI完整使用流程)

平台在win32处下拉，选择新建：

深入OpenJDK源码核心探秘Unsafe(含JNI完整使用流程)

在新平台处选择64，从Win32处复制，勾选创建新的项目平台：

深入OpenJDK源码核心探秘Unsafe(含JNI完整使用流程)

然后点击确定：

深入OpenJDK源码核心探秘Unsafe(含JNI完整使用流程)

然后关闭配置管理器。

接下来我们创建头文件，在项目上右键-添加-类，选择C++类：

深入OpenJDK源码核心探秘Unsafe(含JNI完整使用流程)

选择之后，点击添加。然后在向导中输入类名，这里我们使用前面定义的TestJNI就行了，点击完成。

深入OpenJDK源码核心探秘Unsafe(含JNI完整使用流程)

这里就创建了TestJNI.h和TestJNI.cpp文件：

深入OpenJDK源码核心探秘Unsafe(含JNI完整使用流程)

然后我们直接将前面使用javah命令生成的TestJNI.h文件内容拷贝到当前项目的TestJNI.h中，由于需要引用jni.h，所以我们需要将jni.h从%JAVA_HOME%\include目录中拷贝一份。为了简单，这里直接将jni.h放到TestJNI项目中，和TestJNI.h处于同一目录，所以我们需要修改TestJNI.h中引用jni.h的方法，改为相对路径引入，即<>改为””：

深入OpenJDK源码核心探秘Unsafe(含JNI完整使用流程)

这里我们打开jni.h简单看一下，发现其中需要引入jni_md.h:

深入OpenJDK源码核心探秘Unsafe(含JNI完整使用流程)

所以我们需要将jni.h文件和jni_md.h都拷贝到项目中，和TestJNI.h同目录（jni_md.h在%JAVA_HOME%\include\win32目录中）：

深入OpenJDK源码核心探秘Unsafe(含JNI完整使用流程)

接下来编写TestJNI.cpp文件，在该文件中实现Java_TestJNI_say方法：简单输出hello world

#include "TestJNI.h"

JNIEXPORT void JNICALL Java_TestJNI_say (JNIEnv *env , jobject obj){
	printf("hello world");
}

到这里我们代码就编写完毕了，接下来进入顶部导航栏：生成-重新生成解决方案

深入OpenJDK源码核心探秘Unsafe(含JNI完整使用流程)

下方输出区域会显示执行结果：

深入OpenJDK源码核心探秘Unsafe(含JNI完整使用流程)

这里可能会被360等软件拦截，允许即可。生成成功之后，我们进入项目目录的x64\Debug目录中，可以看到已经生成了dll文件了：

深入OpenJDK源码核心探秘Unsafe(含JNI完整使用流程)

到这里我们TestLib.dll动态链接库已经创建好了，接下来将其复制到TestJNI.java目录中，当然我们这里是在桌面上：

深入OpenJDK源码核心探秘Unsafe(含JNI完整使用流程)

然后我们打开命令窗口，先javac TestJNI.java编译，然后java TestJNI运行代码：

深入OpenJDK源码核心探秘Unsafe(含JNI完整使用流程)

我们看到，输出了hello world，native方法调用成功。

免责声明：本站所有文章内容,图片，视频等均是来源于用户投稿和互联网及文摘转载整编而成，不代表本站观点，不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益，请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权，请联系删除，如若转载，请注明出处：https://yundeesoft.com/15384.html

赞 (0)
老牧童老牧童
0

相关推荐

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

关注微信