直接缓冲DirectByteBuffer详解
作者：互联网
https://blog.csdn.net/huangyu1985/article/details/103939462
1. 介绍
ByteBuffer底层是通过byte数组的方式来存储数据的，所谓直接缓冲是指byte数组是通过堆外存存储的，并没有存在jvm堆上，不受jvm垃圾回收的约束。
2. 直接缓冲和堆缓冲的创建方式
ByteBuffer的创建有两种方式，allocate和allocateDirect，其中通过allocate创建出来的是HeapByteBuffer(堆缓冲)，源码如下：
// 创建堆缓冲，返回HeapByteBuffer
public static ByteBuffer allocate(int capacity) {
if (capacity < 0)
throw new IllegalArgumentException();
return new HeapByteBuffer(capacity, capacity);
}
HeapByteBuffer继承ByteBuffer，在ByteBuffer中有byte数组来存储数据
public abstract class ByteBuffer extends Buffer
implements Comparable<ByteBuffer> {
// 存储数据的byte数组
final byte[] hb; // Non-null only for heap buffers
ByteBuffer(int mark, int pos, int lim, int cap, // package-private
byte[] hb, int offset) {
super(mark, pos, lim, cap);
this.hb = hb;
this.offset = offset;
}
....
}
通过allocateDirect创建出来的是DirectByteBuffer(直接缓冲)，源码如下：
public static ByteBuffer allocateDirect(int capacity) {
return new DirectByteBuffer(capacity);
}
在创建DirectByteBuffer过程中，存储数据的空间通过native方法来进行内存分配和初始化，最终通过一个内存地址将DirectByteBuffer和存储数据的数组关联在一起。源码如下：
DirectByteBuffer(int cap) {
....
base = unsafe.allocateMemory(size); // 分配内存空间
....
unsafe.setMemory(base, size, (byte) 0); // 内存空间初始化
if (pa && (base % ps != 0)) {
// Round up to page boundary
address = base + ps - (base & (ps - 1)); // 获取内存空间地址
} else {
address = base;
}
....
}
3. 为什么需要直接缓冲
如果使用堆缓冲，java堆属于用户空间，以IO输入为例，首先是用户空间进程向内核请求某个磁盘空间数据，然后内核将磁盘数据读取到内核空间的buffer中，然后用户空间的进程再将内核空间buffer中的数据读取到自身的buffer中，然后进程就可以访问使用这些数据，如下图： 
在上述过程中，有了一次数据拷贝，在高并发的场景下，必定有性能的损耗，直接缓冲就解决了此问题。目前的操作系统，用户空间和内核空间的区分一般采用虚拟内存来实现，因此用户空间和内存空间都是在虚拟内存中。使用虚拟内存无非是因为其两大优势：一是它可以使多个虚拟内存地址指向同一个物理内存;二是虚拟内存的空间可以大于物理内存的空间。对于第一点在进行IO操作时就可以将用户空间的buffer区和内核空间的buffer区指向同一个物理内存。这样用户空间的程序就不需要再去内核空间再取回数据，而是可以直接访问，避免了数据拷贝，提升性能。
再补充一个知识点，使用HeapByteBuffer时，为什么从磁盘读取数据到buffer需要做一次copy，为什么不能直接从磁盘copy到buffer。这个copy过程从jdk源码也有体现，如下：
/**
* var0: 文件描述符，表示将要读取数据的文件句柄
* var1: 我们创建出来的ByteBuffer，将要把文件的数据写入此buffer
*/
static int read(FileDescriptor var0, ByteBuffer var1, long var2, NativeDispatcher var4) throws IOException {
// 如果时只读buffer直接报错
if (var1.isReadOnly()) {
throw new IllegalArgumentException("Read-only buffer");
} else if (var1 instanceof DirectBuffer) {
// 如果是DirectBuffer，那么直接把文件内容写入buffer
return readIntoNativeBuffer(var0, var1, var2, var4);
} else {
// 如果是HeapByteBuffer，那么先创建一个DirectByteBuffer
ByteBuffer var5 = Util.getTemporaryDirectBuffer(var1.remaining());
int var7;
try {
// 先把文件内容写入DirectByteBuffer
int var6 = readIntoNativeBuffer(var0, var5, var2, var4);
var5.flip();
if (var6 > 0) {
// 再把DirectByteBUffer内容写入我们传入的HeapByteBuffer
var1.put(var5);
}
var7 = var6;
} finally {
Util.offerFirstTemporaryDirectBuffer(var5);
}
return var7;
}
}
从源码看到，确实做了一次copy，这么做其实是在迁就OpenJDK里的HotSpot VM的一点实现细节。HeapByteBuffer存储对象的byte数组在java堆上，而HotSpot VM里的GC除了CMS之外都是要移动对象的，是所谓“compacting GC”。如果要把一个Java里的 byte[] 对象的引用传给native代码，让native代码直接访问数组的内容的话，就必须要保证native代码在访问的时候这个 byte[] 对象不能被移动，也就是要被“pin”（钉）住。可惜HotSpot VM出于一些取舍而决定不实现单个对象层面的object pinning，要pin的话就得暂时禁用GC——也就等于把整个Java堆都给pin住。HotSpot VM对JNI的Critical系API就是这样实现的。这用起来就不那么顺手。所以 Oracle/Sun JDK / OpenJDK 的这个地方就用了点绕弯的做法。它假设把 HeapByteBuffer 背后的 byte[] 里的内容拷贝一次是一个时间开销可以接受的操作，同时假设真正的I/O可能是一个很慢的操作。于是它就先把 HeapByteBuffer 背后的 byte[] 的内容拷贝到一个 DirectByteBuffer 背后的native memory去，这个拷贝会涉及 sun.misc.Unsafe.copyMemory() 的调用，背后是类似 memcpy() 的实现。这个操作本质上是会在整个拷贝过程中暂时不允许发生GC的，虽然实现方式跟JNI的Critical系API不太一样。（具体来说是 Unsafe.copyMemory() 是HotSpot VM的一个intrinsic方法，中间没有safepoint所以GC无法发生）。然后数据被拷贝到native memory之后就好办了，就去做真正的I/O，把 DirectByteBuffer 背后的native memory地址传给真正做I/O的函数。这边就不需要再去访问Java对象去读写要做I/O的数据了。
4. 直接缓冲的优缺点
4.1 优点
前面已经分析了，在进行IO操作时，例如文件读写，或者socket读写，少了一次copy性能有提升。
注意，仅限于有IO操作的场景下
4.2 缺点
在非IO操作的场景下，例如仅仅做数据的编解码，不和机器硬件打交道，那么即使使用了HeapByteBuffer也不会产生copy动作，如果此时仍然在使用DirectByteBuffer，由于数据存储部分在堆外存，内存空间的分配和释放比堆内存更加复杂一些，性能也稍慢一些，在netty中是通过buf池的方案来解决的，后续的netty博客会深入讲解。
基于此我们可以总结一下HeapByteBuffer和DirectByteBuffer的使用场景：对于后端业务的编解码操作，使用HeapByteBuffer，对于IO通信，使用DirectByteBuffer。
标签：buffer,缓冲,HeapByteBuffer,int,详解,ByteBuffer,byte,DirectByteBuffer 来源： https://blog.csdn.net/fengyuyeguirenenen/article/details/123186486