Java NIO AsynchronousFileChannel 如何避免回调堆积：批量写入与吞吐基线

批量导出日志时，AsynchronousFileChannel 看起来能把写盘交给系统线程池，但如果循环一次性提交几万个写请求，完成回调会和待处理任务一起堆在内存里。更稳妥的做法是给提交窗口设上限，等一批写完再继续，并用同一组输入测出吞吐基线。

控制异步写入的关键不是把请求提交得越快越好，而是让“未完成的写请求数”有明确上限，并在每批完成后核对字节数和文件大小。

先建立可比较的写入基线

先别急着把线程池调大。我们准备一个固定大小的字节数组，按 64 KiB 分块写入临时文件，分别测试窗口为 1、8、32 和 128 的情况。每次测试前删除旧文件，测试后检查文件大小是否等于预期值。

static final int BLOCK_SIZE = 64 * 1024;
static final int FILE_SIZE = 64 * 1024 * 1024;

static long throughputMbPerSecond(long bytes, long nanos) {
    return Math.round(bytes / 1024.0 / 1024.0 / (nanos / 1_000_000_000.0));
}

这里的吞吐只用于比较同一台机器上的参数变化，不能直接代表生产环境。文件系统缓存、磁盘类型和 JVM 启动状态都会影响结果，至少要预热一次再记录正式数据。

为什么连续提交会让回调堆积

AsynchronousFileChannel.write 返回后，真正的完成通知稍后才到达。提交端如果一直循环，未完成请求就会不断增加；每个请求还会持有缓冲区和回调对象。这个问题通常不是“异步 API 失效”，而是生产速度超过了完成速度。

下面的关系图只保留正文中真实出现的三个节点：submitWrite 提交任务，CompletionHandler 报告结果，pendingWrites 记录尚未完成的数量。

用固定窗口改造批量写入

窗口控制可以放在提交循环外层：只要 pendingWrites 达到上限，就等待一个批次完成。回调只负责更新计数和错误状态，不在回调里继续无限递归提交，避免错误路径难以收敛。

static void submitWrite(AsynchronousFileChannel channel,
                        ByteBuffer buffer,
                        long position,
                        AtomicInteger pendingWrites,
                        AtomicReference failure,
                        CountDownLatch completed) {
    pendingWrites.incrementAndGet();
    channel.write(buffer, position, null, new CompletionHandler() {
        @Override public void completed(Integer written, Void ignored) {
            pendingWrites.decrementAndGet();
            completed.countDown();
        }

        @Override public void failed(Throwable error, Void ignored) {
            failure.compareAndSet(null, error);
            pendingWrites.decrementAndGet();
            completed.countDown();
        }
    });
}

真实代码还需要为每个分块准备独立的、不会被提前复用的 ByteBuffer。如果多个异步写共享同一个可变缓冲区，回调完成前修改它会造成数据错乱。

把完成条件和字节数一起验收

仅仅等到回调次数达到预期还不够：短写、异常和文件截断都可能让“任务完成”与“文件正确”不一致。writeBatch 应在批次结束后检查 bytesWritten，最后再检查输出文件大小。

static long writeBatch(Path target, List blocks, int window)
        throws IOException, InterruptedException {
    AtomicLong bytesWritten = new AtomicLong();
    CountDownLatch completed = new CountDownLatch(blocks.size());
    AtomicReference failure = new AtomicReference();

    try (AsynchronousFileChannel channel = AsynchronousFileChannel.open(
            target, StandardOpenOption.CREATE, StandardOpenOption.WRITE,
            StandardOpenOption.TRUNCATE_EXISTING)) {
        for (int i = 0; i 

示例刻意把计数和批次等待的位置露出来，方便改成项目自己的实现；生产代码应让每个批次拥有独立的完成计数，并在 CompletionHandler.completed 中累加写入字节。

压测时记录什么才有意义

每个窗口至少运行三轮，丢弃第一次类加载和文件系统准备带来的干扰，记录总字节数、耗时、吞吐、最大未完成请求数和最终文件大小。不要只看平均耗时；如果窗口 128 的平均值更高但尾部抖动明显，通常说明并发已经超过设备的消化能力。

建议把基线写成 CSV：window,bytes,nanos,throughput,maxPending,fileSize,passed。固定 FILE_SIZE 和 BLOCK_SIZE，一次只改变 window，否则结果无法解释。

常见问题与边界：窗口不是越小越安全

窗口为 1 会不会完全失去异步价值？

它更接近串行写入，能作为稳定基线，但吞吐可能受单次完成延迟限制。窗口 8 或 32 是否更好，要以同机实测为准。

回调失败后还能继续提交吗？

如果文件是一次性导出，通常应记录首个失败并停止后续批次，同时取消或等待已提交任务收尾。继续提交会让错误文件更难定位。

为什么文件大小正确仍要检查字节数？

文件大小只能说明最后一个写入位置形成了某个长度，不能证明每个分块都成功写入。累计 bytesWritten 能把短写和漏写暴露出来。

收尾检查

完成改造后，先看 pendingWrites 是否在窗口内，再看失败状态是否能让后续批次停止，最后用文件大小和 bytesWritten 双重核对。只有输入、环境和测量口径固定，窗口参数的吞吐对比才有参考价值。