Java AsynchronousFileChannel 写入完成前关闭通道会怎样

会失败。AsynchronousFileChannel.write 只是提交一次异步写入；如果写入仍处于 outstanding 状态就调用 close()，Java 会让这个未完成操作以 AsynchronousCloseException 结束。已经回调完成的写入不受这次关闭影响，但不能把 write() 返回当成文件已经写完。

官方地址：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/nio/channels/AsynchronousFileChannel.html

关闭通道不是“等待最后一笔写完再释放”，而是主动终止该通道上的未完成异步操作。正确做法是等 completed 或 Future.get() 给出结果，再决定是否 force 和关闭。

一、关闭通道会让未完成写入失败

Java SE 25 的 API 对这个边界定义得很明确：AsynchronousFileChannel.close() 可以在任意时刻调用，但会让通道上所有未完成的异步操作以 AsynchronousCloseException 完成。这里的“完成”并不等于成功，回调仍会被调度，只是进入 failed 分支。

因此，下面两种状态必须分开看：回调已经收到写入字节数，说明该操作已经完成；回调还没有到达，此时关闭通道，业务只能按失败或取消收尾。文件可能已经出现部分内容，但 API 不承诺把它当成一次完整业务写入，应用应使用临时文件和最终改名保护成品。

二、先区分 Future 与 CompletionHandler 的等待方式

write(ByteBuffer,long) 返回的是 Future。这个对象代表“异步操作的结果”，不是已经写入的字节数。调用方如果提交后立即离开方法，通道很可能随资源管理逻辑一起被关闭。

使用 Future 时，至少要在关闭前取得结果；如果线程被中断或等待失败，也要把异常转成明确的业务状态。使用回调时，则把关闭责任放在 completed 和 failed 的共同收尾位置。两种方式选一种即可，不要同时用回调和 Future.get() 管同一笔写入。

三、用完成回调决定何时关闭

下面的写法让通道生命周期跟随回调，而不是跟随提交方法的返回。示例只负责一笔写入；生产环境若有多块数据，应为每块数据准备独立缓冲区，并在上一笔完成后再提交下一笔。

import java.io.IOException;
import java.nio.ByteBuffer;
import java.nio.channels.AsynchronousFileChannel;
import java.nio.channels.CompletionHandler;
import java.nio.channels.AsynchronousCloseException;
import java.nio.file.Path;
import java.nio.file.StandardOpenOption;

static void writeOnce(Path target, byte[] data) throws IOException {
    AsynchronousFileChannel channel = AsynchronousFileChannel.open(
        target, StandardOpenOption.CREATE, StandardOpenOption.WRITE);
    ByteBuffer buffer = ByteBuffer.wrap(data);
    channel.write(buffer, 0L, channel, new CompletionHandler() {
        @Override
        public void completed(Integer written, AsynchronousFileChannel ch) {
            try {
                // 回调拿到字节数后，才允许选择性地把更新推向存储设备。
                ch.force(false);
            } catch (IOException e) {
                // force 失败也要进入统一收尾，避免通道泄漏。
                System.err.println("force failed: " + e.getMessage());
            } finally {
                closeQuietly(ch);
            }
        }

        @Override
        public void failed(Throwable error, AsynchronousFileChannel ch) {
            // close 导致的未完成操作失败应单独记录，不能伪装成成功写入。
            if (error instanceof AsynchronousCloseException) {
                System.err.println("write cancelled by channel close");
            } else {
                System.err.println("write failed: " + error.getMessage());
            }
            closeQuietly(ch);
        }
    });
}

static void closeQuietly(AsynchronousFileChannel channel) {
    try {
        // 只有完成回调负责关闭，避免提交线程提前释放通道。
        channel.close();
    } catch (IOException e) {
        System.err.println("close failed: " + e.getMessage());
    }
}

如果采用 Future，结构会更直接，但等待线程会被占用：

Future pending = channel.write(buffer, 0L);
try {
    // get 返回才表示这一次异步写入已经给出结果。
    int written = pending.get();
    channel.force(false); // 关键文件可在此处选择内容落盘。
    System.out.println("written=" + written);
} catch (InterruptedException e) {
    // 恢复中断标志，让上层线程池仍能感知取消。
    Thread.currentThread().interrupt();
} catch (ExecutionException e) {
    // 从 ExecutionException 中取出真正的 I/O 原因。
    System.err.println("write failed: " + e.getCause());
} finally {
    // finally 只适合放在 get 已返回或失败已确定的生命周期内。
    channel.close();
}

四、生产代码的兼容边界

第一，多个读写操作可以同时 outstanding，但完成顺序和回调顺序都没有保证。如果文件格式依赖偏移顺序，不要只靠提交顺序，应该串联完成通知或使用明确的任务协调器。第二，一个 ByteBuffer 不能在异步操作结束前被另一笔 I/O 复用或修改，否则即便通道没有关闭，写出的内容也可能不是提交时看到的内容。

第三，force(false) 解决的是把该通道看到的内容更新推向底层存储设备，不等于远端文件系统和整套业务事务获得相同的原子性。重要文件更稳妥的组合通常是：写临时文件、等待成功完成、按需求 force、关闭临时文件，再做原子替换，并把失败文件清理交给明确的补偿逻辑。

• 关闭责任是否只有一个地方持有？
• 成功条件是“写入回调完成”还是“业务文件替换完成”？
• 失败回调是否区分 AsynchronousCloseException、InterruptedException 和普通 IOException？
• 每笔异步写入是否拥有独立且未提前复用的 ByteBuffer？

相关问题

close 之后还能继续调用 write 吗？

不能把它当成可用通道继续写。关闭后新操作会面临关闭通道异常；原先未完成的操作则按异步关闭语义进入失败完成。

回调 completed 是否代表数据已经抗住断电？

不一定。它代表异步操作成功完成；是否需要调用 force，取决于文件的持久化要求和底层文件系统边界。

为什么不能在方法末尾直接 close？

因为异步方法返回时写入可能仍在进行。方法末尾的 close 会把尚未完成的操作变成失败，应该把关闭放到完成通知或确定的 Future 等待之后。