使用CompletableFuture时如何消除关闭OutputStream的编译器警告？

我来帮你分析下为啥编译器会提示这个警告哈——其实是因为编译器的静态代码分析没办法识别whenComplete里的资源关闭操作。毕竟whenComplete是异步回调，编译器会担心出现极端情况：比如主线程在回调执行前就终止了，或者回调因为某些异常没触发，导致OutputStream一直没被关闭，所以才会弹出这个提示。

那怎么解决呢？这里有两个方案，推荐第一个：

方案一：在异步任务内部用try-with-resources管理OutputStream（最佳实践） #

把OutputStream的创建和使用都放到异步任务里，用try-with-resources包裹，这样不管任务成功还是失败，资源都会被自动关闭，编译器也能识别到这个安全的关闭路径，不会再提示警告。代码示例：

final String url = "https://example.com/some-download.zip";
final File file = new File("your/save/path/some-download.zip");

CompletableFuture.runAsync(() -> {
    // 用try-with-resources自动管理OutputStream
    try (OutputStream outputStream = Files.newOutputStream(file.toPath())) {
        // 执行下载逻辑，把内容写入输出流
        URL downloadUrl = new URL(url);
        // 同样用try-with-resources管理输入流
        try (InputStream inputStream = downloadUrl.openStream()) {
            inputStream.transferTo(outputStream);
        }
    } catch (IOException e) {
        // 这里处理下载或IO异常
        e.printStackTrace();
    }
});

这个方案的好处是资源的生命周期完全在异步任务内部，不会有线程安全问题，同时完美符合Java的资源管理规范。

方案二：外部创建OutputStream并同步等待任务完成（不推荐） #

如果你因为某些原因必须在外部创建OutputStream，那可以用try-finally包裹，同时调用future.join()等待异步任务完成后再关闭资源。但这个方法会阻塞主线程，相当于把异步操作变成了同步，失去了CompletableFuture的异步优势，所以只适合特殊场景：

final File file = new File("your/save/path/some-download.zip");
final String url = "https://example.com/some-download.zip";
OutputStream outputStream = null;

try {
    outputStream = Files.newOutputStream(file.toPath());
    CompletableFuture<Void> downloadFuture = CompletableFuture.runAsync(() -> {
        try {
            URL downloadUrl = new URL(url);
            try (InputStream inputStream = downloadUrl.openStream()) {
                inputStream.transferTo(outputStream);
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    });
    // 等待异步任务完成，否则主线程会提前关闭输出流
    downloadFuture.join();
} catch (IOException e) {
    e.printStackTrace();
} finally {
    // 手动关闭输出流
    if (outputStream != null) {
        try {
            outputStream.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

总的来说，优先选方案一，既解决了编译器警告，又能保持异步操作的优势。

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