想写这个系列很久了，对自己也是个总结与提高。原来在学JAVA时，那些JAVA入门书籍会告诉你一些规律还有法则，但是用的时候我们一般很难想起来，因为我们用的少并且不知道为什么。知其所以然方能印象深刻并学以致用。
本篇文章针对堆外内存与DirectBuffer进行深入分析，了解Java对于堆外内存处理的机制，为下一篇文件IO做好准备
Java堆栈内存与堆外内存
1. 堆栈内存
堆栈内存指的是堆内存和栈内存：堆内存是GC管理的内存，栈内存是线程内存。
堆内存结构：
还有一个更细致的结构图（包括MetaSpace还有code cache）：
我们看下面一段代码来简单理解下堆栈的关系：
public static void main(String[] args) { Object o = new Object(); }
其中new Object()是在堆上面分配，而Object o这个变量，是在main这个线程栈上面。
- 应用程序所有的部分都使用堆内存，然后栈内存通过一个线程运行来使用。
- 不论对象什么时候创建，他都会存储在堆内存中，栈内存包含它的引用。栈内存只包含原始值变量好和堆中对象变量的引用。
- 存储在堆中的对象是全局可以被访问的，然而栈内存不能被其他线程所访问。
- 通过JVM参数
-Xmx我们可以指定最大堆内存大小，通过-Xss我们可以指定每个线程线程栈占用内存大小
2. 堆外内存
2.1. 广义的堆外内存
除了堆栈内存，剩下的就都是堆外内存了，包括了jvm本身在运行过程中分配的内存，codecache，jni里分配的内存，DirectByteBuffer分配的内存等等
2.2. 狭义的堆外内存 - DirectByteBuffer
而作为java开发者，我们常说的堆外内存溢出了，其实是狭义的堆外内存，这个主要是指java.nio.DirectByteBuffer在创建的时候分配内存，我们这篇文章里也主要是讲狭义的堆外内存，因为它和我们平时碰到的问题比较密切
为啥要使用堆外内存。通常因为：
- 在进程间可以共享，减少虚拟机间的复制
- 对垃圾回收停顿的改善：如果应用某些长期存活并大量存在的对象，经常会出发YGC或者FullGC，可以考虑把这些对象放到堆外。过大的堆会影响Java应用的性能。如果使用堆外内存的话，堆外内存是直接受操作系统管理( 而不是虚拟机 )。这样做的结果就是能保持一个较小的堆内内存，以减少垃圾收集对应用的影响。
- 在某些场景下可以提升程序I/O操纵的性能。少去了将数据从堆内内存拷贝到堆外内存的步骤。
3. JNI调用与内核态及用户态
- 内核态：cpu可以访问内存的所有数据，包括外围设备，例如硬盘，网卡，cpu也可以将自己从一个程序切换到另一个程序。
- 用户态：只能受限的访问内存，且不允许访问外围设备，占用cpu的能力被剥夺，cpu资源可以被其他程序获取。
- 系统调用：为了使上层应用能够访问到这些资源，内核为上层应用提供访问的接口
Java调用原生方法即JNI就是系统调用的一种。
我们举个例子，文件读取；Java本身并不能读取文件，因为用户态没有权限访问外围设备。需要通过系统调用切换内核态进行读取。
目前，JAVA的IO方式有基于流的传统IO还有基于块的NIO方式（虽然文件读取其实不是严格意义上的NIO，哈哈）。面向流意味着从流中一次可以读取一个或多个字节，拿到读取的这些做什么你说了算，这里没有任何缓存（这里指的是使用流没有任何缓存，接收或者发送的数据是缓存到操作系统中的，流就像一根水管从操作系统的缓存中读取数据）而且只能顺序从流中读取数据，如果需要跳过一些字节或者再读取已经读过的字节，你必须将从流中读取的数据先缓存起来。面向块的处理方式有些不同，数据是先被 读/写到buffer中的，根据需要你可以控制读取什么位置的数据。这在处理的过程中给用户多了一些灵活性，然而，你需要额外做的工作是检查你需要的数据是否已经全部到了buffer中，你还需要保证当有更多的数据进入buffer中时，buffer中未处理的数据不会被覆盖。
我们这里只分析基于块的NIO方式，在JAVA中这个块就是ByteBuffer。
4. Linux下零拷贝原理
大部分web服务器都要处理大量的静态内容，而其中大部分都是从磁盘文件中读取数据然后写到socket中。我们以这个过程为例子，来看下不同模式下Linux工作流程
4.1. 普通Read/Write模式
涉及的代码抽象：
//从文件中读取，存入tmp_buf read(file, tmp_buf, len); //将tmp_buf写入socket write(socket, tmp_buf, len);
看上去很简单的步骤但是经过了很多复制：
- 当调用 read 系统调用时，通过 DMA（Direct Memory Access）将数据 copy 到内核模式
- 然后由 CPU 控制将内核模式数据 copy 到用户模式下的 buffer 中
- read 调用完成后，write 调用首先将用户模式下 buffer 中的数据 copy 到内核模式下的 socket buffer 中
- 最后通过 DMA copy 将内核模式下的 socket buffer 中的数据 copy 到网卡设备中传送。
从上面的过程可以看出，数据白白从内核模式到用户模式走了一圈，浪费了两次 copy(第一次，从kernel模式拷贝到user模式；第二次从user模式再拷贝回kernel模式，即上面4次过程的第2和3步骤。)，而这两次 copy 都是 CPU copy，即占用CPU资源
4.2. sendfile模式
通过 sendfile 传送文件只需要一次系统调用，当调用 sendfile 时：
- 首先通过 DMA copy 将数据从磁盘读取到 kernel buffer 中
- 然后通过 CPU copy 将数据从 kernel buffer copy 到 sokcet buffer 中
- 最终通过 DMA copy 将 socket buffer 中数据 copy 到网卡 buffer 中发送 sendfile 与 read/write 方式相比，少了 一次模式切换一次 CPU copy。但是从上述过程中也可以发现从 kernel buffer 中将数据 copy 到socket buffer 是没必要的。
4.3. sendfile模式改进
Linux2.4 内核对sendFile模式进行了改进：
改进后的处理过程如下：
- DMA copy 将磁盘数据 copy 到 kernel buffer 中 2.向 socket buffer 中追加当前要发送的数据在 kernel buffer 中的位置和偏移量
- DMA gather copy 根据 socket buffer 中的位置和偏移量直接将 kernel buffer 中的数据 copy 到网卡上。
经过上述过程，数据只经过了 2 次 copy 就从磁盘传送出去了。（事实上这个 Zero copy 是针对内核来讲的，数据在内核模式下是 Zero－copy 的）。
当前许多高性能 http server 都引入了 sendfile 机制，如 nginx，lighttpd 等。
5. Java零拷贝实现的变化
Zero-Copy技术省去了将操作系统的read buffer拷贝到程序的buffer，以及从程序buffer拷贝到socket buffer的步骤，直接将read buffer拷贝到socket buffer. Java NIO中的FileChannal.transferTo()方法就是这样的实现
public void transferTo(long position,long count,WritableByteChannel target);
transferTo()方法将数据从一个channel传输到另一个可写的channel上，其内部实现依赖于操作系统对zero copy技术的支持。在unix操作系统和各种linux的发型版本中，这种功能最终是通过sendfile()系统调用实现。下边就是这个方法的定义：
#include <sys/socket.h> ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);
5.1. Linux 2.4之前的底层实现
和之前所述一样，我们用下面两幅图更清楚的展示一下发生的复制以及内核态用户态切换：
内核、用户态切换的次数只有两次，将数据的复制次只有三次(只有一次用到cpu资源) 在Linux2.4之后，我们可以将这仅有的一次cpu复制也去掉
