Java ByteBuffer.alignedSlice 怎样按内存对齐创建切片

Java 的 ByteBuffer 需要按 8、16 或 32 字节边界读取时，关键不是把整个缓冲区重新复制一份，而是先确定当前位置和结尾能保留下多少个完整的对齐单元。alignmentOffset 用来查询某个索引距离对齐边界的偏移，alignedSlice 则按照“起点向上取整、终点向下取整”的规则创建共享切片。

官方文档：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/nio/ByteBuffer.html

这两个方法自 Java 9 提供。本文只讨论 Java API 自身的对齐语义、切片容量和 direct 缓冲区边界，不把它延伸到 JNI、本地内存分配或具体 CPU 指令。

普通 slice 和 alignedSlice 解决的不是同一个问题

slice() 从当前 position 开始，把剩余内容映射成一个 position 为 0 的新视图；它保证的是范围连续和内容共享，不保证新视图的起点适合某个对齐单位。alignedSlice(unitSize) 仍然共享原内容，但会舍弃两端不完整的字节，使新视图的起点和结尾都落在指定单位的边界上。

这里的“共享”很重要：新切片写入的数据仍会反映到原缓冲区，原缓冲区的内容变化也会反映到切片。但两个对象的 position、limit 和 mark 独立，创建切片不会把原缓冲区的 position 推进到对齐位置。

alignmentOffset 返回的是距离，而不是新的索引

调用 alignmentOffset(index, unitSize) 后，返回值范围是 0 到 unitSize - 1。返回 0 表示索引已经对齐；返回正数表示当前位置偏离了边界多少。unitSize 必须是 2 的幂，例如 2、4、8、16。

假设单位是 8，某个索引的偏移为 3，那么向前移动 3 字节，或向后移动 5 字节，都可以到达 8 字节边界。API 不替你选择方向，所以“向前还是向后”要结合可用范围和业务记录大小决定。

import java.nio.ByteBuffer;

public class AlignmentOffsetDemo {
    public static void main(String[] args) {
        // direct 缓冲区适合演示大于 1 字节单位的对齐查询。
        ByteBuffer buffer = ByteBuffer.allocateDirect(40);
        int unitSize = 8;
        int index = 5;

        // 返回 index 对 8 字节边界的偏移；0 才表示已经对齐。
        int offset = buffer.alignmentOffset(index, unitSize);
        System.out.println("offset=" + offset);

        // 向后找到下一个对齐位置，避免手动猜测应增加多少字节。
        int nextAlignedIndex = index + (offset == 0 ? 0 : unitSize - offset);
        System.out.println("nextAlignedIndex=" + nextAlignedIndex);
    }
}

这个查询只报告偏移，不会修改 buffer 的 position。还要注意，索引必须非负，但 API 不会因为索引超过当前 limit 就自动报越界；调用方仍要自己保证后续访问范围合法。

alignedSlice 的容量可以按两次取整推导

设原缓冲区的 position 为 p，limit 为 l，对齐单位为 u。alignedSlice(u) 会把 p 向上取整成起点，把 l 向下取整成终点：

• 起点：如果 alignmentOffset(p, u) 是 0，就仍是 p；否则向后补足到下一个边界。
• 终点：从 l 中减去 alignmentOffset(l, u)，得到不超过 limit 的最后一个边界。
• 容量：终点减起点；如果起点已经越过终点，返回的切片容量和 limit 都是 0。

例如 position 为 5、limit 为 37、单位为 8 时，起点会落到 8，终点会落到 32，切片容量就是 24。原缓冲区的 5～7 和 32～36 不会进入切片，因为它们不能组成两端都对齐的完整范围。

用 direct ByteBuffer 创建 8 字节对齐的共享切片

实际使用时，通常先让 position 和 limit 表示待处理范围，再调用 alignedSlice。下面的示例把 5 到 37 的范围交给 API 处理，并用切片的绝对位置读取一个完整的 8 字节单元。

import java.nio.ByteBuffer;

public class AlignedSliceDemo {
    public static void main(String[] args) {
        // 多申请一些空间，让两端被舍弃后仍能留下完整的对齐范围。
        ByteBuffer source = ByteBuffer.allocateDirect(40);
        source.position(5).limit(37);
        int unitSize = 8;

        // 新切片从下一个 8 字节边界开始，到前一个边界结束。
        ByteBuffer aligned = source.alignedSlice(unitSize);

        // 新切片 position 从 0 开始，容量由对齐后的两端共同决定。
        System.out.println("capacity=" + aligned.capacity());
        System.out.println("startOffset=" + aligned.alignmentOffset(0, unitSize));
        System.out.println("endOffset=" + aligned.alignmentOffset(aligned.limit(), unitSize));

        // 切片与 source 共享内容，但不改变 source 的 position 和 limit。
        aligned.putLong(0, 0x0102030405060708L);
        System.out.println("sourcePosition=" + source.position());
    }
}

在这个范围下，切片容量应为 24，两个对齐查询都应返回 0，原缓冲区的 position 仍是 5。示例中的打印是根据 API 规则推导出的预期关系，不把它当作本文在本机执行得到的运行证据。

四个边界决定了结果是否符合预期

另外，新的 ByteBuffer 的字节序会回到 BIG_ENDIAN，不要把源缓冲区的字节序设置自动带入切片。如果后续用 getLong、putLong 等多字节方法，要在切片上明确调用 order。

什么时候用 alignedSlice，什么时候继续用 slice

如果任务只是把当前位置到 limit 的内容交给另一个组件，且组件不要求地址或范围对齐，普通 slice() 更直接。如果组件需要以固定字节宽度访问，并且两端的残余字节不应被读入，那么 alignedSlice 能把“边界取整”集中到 API 中。

采用前可以按下面的顺序做判断：

1. 确认对齐单位是 2 的幂，并明确是按字节边界还是按业务记录长度对齐。
2. 确认缓冲区类型；对大于 1 的单位，不要忽略非 direct 缓冲区的异常边界。
3. 用 position、limit 和单位估算可用容量，允许结果为 0。
4. 把切片视为共享视图，分别设置它的字节序和状态。

相关问题：

• alignedSlice 会复制原 ByteBuffer 的数据吗？不会，它创建的是共享内容的视图。
• alignedSlice 会改变原缓冲区的 position 吗？不会，新旧缓冲区的位置和 limit 独立。
• 为什么切片容量比 remaining 小？因为起点向上取整、终点向下取整，两端不完整部分被排除。
• alignmentOffset 的 unitSize 可以传 3 吗？不可以，单位必须是 2 的幂。