Java中如何不拷贝缓冲区解码MappedByteBuffer的UTF-8码点

首先纠正一个普遍的认知偏差：不存在必须拷贝缓冲区才能解码的强制要求，大家遇到的拷贝问题基本都是API用法不对导致的，CharsetDecoder原生支持直接缓冲区的无拷贝解码。

核心逻辑 #

MappedByteBuffer本身是堆外直接内存的视图，只要解码流程满足两个条件就不会触发额外拷贝：

• 输入阶段不把映射的字节内容复制到堆内字节数组
• 输出阶段不把解码后的字符强制转储到堆内char数组、String这类堆内结构

所谓toCharArray()触发拷贝，本质是使用者主动调用方法把直接内存的内容读到堆里，不是解码流程的固有步骤。

具体实现 #

前置准备 #

全局复用CharsetDecoder实例，避免每次解码重复创建对象带来额外开销，提前配置好异常处理策略：

private static final CharsetDecoder UTF8_DECODER = StandardCharsets.UTF_8.newDecoder()
        .onMalformedInput(CodingErrorAction.REPLACE)
        .onUnmappableCharacter(CodingErrorAction.REPLACE);

注意不要用StandardCharsets.UTF_8.decode()这种封装好的简便方法，它内部默认分配堆内缓冲区，必然触发拷贝。

解码流程 #

1. 调整待解码MappedByteBuffer的position、limit，对准需要解码的字节区间，不要调用array()方法——MappedByteBuffer本身是直接缓冲区，没有支撑堆数组，调用这个方法会直接抛异常。
2. 分配直接内存类型的CharBuffer作为解码输出缓冲区，不要用CharBuffer.allocate()（这个方法分配的是堆内缓冲区），也不要手动包装char数组。缓冲区大小按UTF-8最坏编码效率（每个字符占3字节）计算，设为待解码字节长度的1/3+1即可。

   如果你用的是Java 8及更早版本，没有提供CharBuffer.allocateDirect()方法，可以自己实现一个继承CharBuffer的极简类，底层绑定一块通过ByteBuffer.allocateDirect()分配的直接内存地址即可，CharsetDecoder对所有CharBuffer子类都能正常适配。

3. 直接调用解码器完成解码，全程没有堆内存拷贝：

// mappedBuf 是你已经完成映射的MappedByteBuffer实例
int outCap = mappedBuf.remaining() / 3 + 1;
CharBuffer directCharBuf = CharBuffer.allocateDirect(outCap);

UTF8_DECODER.reset();
UTF8_DECODER.decode(mappedBuf, directCharBuf, true);
UTF8_DECODER.flush(directCharBuf);

// 切换到读模式，直接遍历处理字符即可
directCharBuf.flip();
while (directCharBuf.hasRemaining()) {
    char c = directCharBuf.get();
    // 在这里直接处理字符，不要调用toCharArray()、toString()这类会触发堆拷贝的方法
}

进一步降低开销的优化 #

如果你不需要一次性拿到全部解码结果，可以把输出的直接CharBuffer设为固定小尺寸（比如8KB），逐段解码映射的字节内容，处理完一段就移动缓冲区position继续解下一段，连全量字符的直接内存都不需要分配，内存开销可以降到恒定值，完全发挥内存映射大文件的性能优势。
如果需要随机访问码点，可以只在索引里记录每个UTF-8字符在MappedByteBuffer里的起始字节偏移，需要访问对应位置字符时，局部解码对应字节段即可，不需要全量解码。

常见踩坑 #

• 不要在解码完成后调用directCharBuf.toString()、directCharBuf.array()方法，这两个操作都会把直接内存里的字符复制到堆内，直接破坏零拷贝的效果。
• 直接内存的CharBuffer使用完成后记得主动释放，不要等GC回收，避免堆外内存泄漏。

内容的提问来源于stack exchange，提问作者ishaangupte