java 堆外内存

堆外内存和堆内内存

堆内内存

java堆内内存，是java虚拟机通过malloc分配后，完全自己管理的，跟操作系统的内存管理没啥区别，java虚拟机有完全的控制权。
java虚拟机通过记录相关信息，能够完全掌握内存的使用情况（有那些空间是剩余的，那一块内存是属于那个对象的），因此通过可达性算法，能够识别出那些内存能够被释放掉。java的GC并不是真正的调用free将内存归还给操作系统，而是将该块内存放入到可用内存列表里面，类似于内存池化。
类似操作系统的内存管理，操作系统也是使用bitmap记录各个内存页的使用情况，内存释放也仅仅只是将该页标记为空闲。
java虚拟机通过malloc获得内存的使用权，然后通过记录相关信息（java中的new 操作，除了从虚拟机中获得内存外，会对该块内存信息做记录），能够进行内存管理，也就是GC，所以java程序不需要显示释放内存，虚拟机能够识别该块内存可以释放，并将可释放的内存重新纳入到可分配的内存里面。
c语言，c++语言并未对内存使用信息做记录，所以不具备内存管理功能，开发者得显示释放内存。

堆外内存

从字面意思堆外内存跟堆内内存不属于同一块区域，很多人将堆外内存类比为c语言中malloc分配的内存，不受GC控制。虽然这个不严谨，但是有助于理解堆外内存与堆内内存的的区别。
堆外内存其实也受gc控制，只是它的回收机制与堆内内存不一样。堆内内存GC的时候会进行内存整理，防止内存碎片。
因为堆外内存应用场景很小，不会大规模使用，所以不会进行内存整理。其内存地址在分配后就不会变动（该特性决定了其被开发出来的目的）。

堆外内存存在的意义

linux IO

linux的IO这么设计的原因是：
1.如果IO使用内核buff，不拷贝到用户空间，内核buff直接暴露给应用会很危险，用户空间的程序越界访问就会修改内核数据。
2.如果IO直接从物理设备拷贝到用户空间，理论上好像行的通（个人没想到有啥安全问题，读者可以留言），但是直接拷贝到用户空间的话，内核无法缓存该数据，下次读同样的文件，没办法加速。

当然linux也有零拷贝的API，比如sendfile,因为应用程序不需要获取到文件中的内容，所以数据只经过内核空间。

java BIO

图中的内容是读JDK源码得到的，大家可以看以下FileInputStream的源码，然后跟踪到本地代码。
本地代码中，会创建buff，然后调用系统api将数据读取到本地buff，再拷贝到java的数组中。下面是截取的部分代码，异常处理等已经去掉。
为什么不将java中的数组直接传给系统调用API？
在其他地方看过一个回答，我觉得解释的挺合理的。
虚拟机会对堆内内存进行内存整理，所以对象、数组这些引用类型的内存地址在其生命周期中会发生变化，直接将java中的数组传递给本地方法中的IO系统调用，如果在系统调用时阻塞了，此刻恰好又发生GC导致数组的地址发生了变化，那就会产生错误的结果。
当然也可以对该数组进行锁定，不允许对该部分内存进行内存整理，那会增加GC的复杂度。
那同学又要问了，那在执行(*env)->SetByteArrayRegion(env, bytes, off, nread, (jbyte *)buf);这一行时也会有上述问题。
我觉得应该是JDK就是这样设计的，非JVM的代码的执行不会影响JVM状态，所以随时可以进行GC。JVM内部的代码会影响JVM状态，进而影响JVM GC的时机，保证系统正确运行。

jint
readBytes(JNIEnv *env, jobject this, jbyteArray bytes,          
                jint off, jint len, jfieldID fid)
{    
    jint nread;    
char *buf = NULL;    
    FD fd;    
    buf = malloc(len);
    nread = IO_Read(fd, buf, len);    
(*env)->SetByteArrayRegion(env, bytes, off, nread, (jbyte *)buf);
return nread;
}

java NIO

堆外内存是为java NIO设计的。
java bio中，相对linux的IO，多了一次内存拷贝。java NIO对其进行了改进。
java NIO中传递给本地方法的参数是堆外内存，堆外内存一经申请，内存地址就不会发生改变，所以可以将其地址直接传递给本地方法，进行文件IO。
以下代码为sun.nio.ch.IOUtil的代码。FileChannelImpl的read方法最终会调用这个方法。
从代码中可以看见，无论传递的是堆外内存的ByteBuffer，还是堆内内存的ByteBuffer 。最终传递给本地方法的都是堆外内存，本地方法进行系统IO时，传递的是堆外内存的地址，所以少了一次拷贝。

代码有删减
static int read(FileDescriptor fd, ByteBuffer dst, long position,
                    NativeDispatcher nd)
{
    if (dst instanceof DirectBuffer)
        return readIntoNativeBuffer(fd, dst, position, nd)；
    获取临时堆外内存
    ByteBuffer bb = Util.getTemporaryDirectBuffer(dst.remaining());
    int n = readIntoNativeBuffer(fd, bb, position, nd);
    bb.flip();
    if (n > 0)
       dst.put(bb);
    return n;
}

java NIO最终调用的本地代码。address参数为堆外内存。

JNIEXPORT jint JNICALLJava_sun_nio_ch_FileDispatcherImpl_read0(JNIEnv *env, jclass clazz,                             
              jobject fdo, jlong address, jint len)
{    
    jint fd = fdval(env, fdo);    
    void *buf = (void *)jlong_to_ptr(address);
    return convertReturnVal(env, read(fd, buf, len), JNI_TRUE)
}