FutureTask 和 CompletableFuture需要特别注意的点以及常见的陷阱

同步阻塞：FutureTask 是阻塞的，使用 get() 方法获取结果时，会阻塞当前线程直到任务完成。这意味着在主线程中使用时，可能会导致性能瓶颈，特别是当任务运行时间较长时。因此，在需要非阻塞的场景中，避免在主线程中直接调用 get()。
任务执行一次性：FutureTask 只能执行一次。一旦任务完成或被取消，就无法重用它。如果需要重新执行任务，必须创建一个新的实例。
线程安全：FutureTask 自身是线程安全的，但要确保任务（如 Callable 或 Runnable）的执行逻辑是线程安全的。
取消操作：在调用 cancel() 方法后，任务可能已经启动，因此，取消可能无法立即生效。这会导致在调用 isCancelled() 方法时出现状态不一致的问题。
超时处理：虽然 get(long timeout, TimeUnit unit) 支持超时，但如果超时时间过短，可能会导致任务被频繁中断。因此，要合理设置超时时间，避免频繁的重试和中断。

1.2 常见的坑

无异步回调支持：FutureTask 不支持回调函数，也无法直接实现链式调用。这会导致异步流程复杂化，需要手动组合多个任务，导致代码冗长和易错。
无法组合任务：FutureTask 不能合并多个异步任务，这意味着如果需要组合任务结果，就需要额外的逻辑来管理和同步不同的 FutureTask。
异常处理不直观：FutureTask 的异常只能通过 get() 方法捕获，这意味着所有的异常都可能在获取结果时被推迟处理。这会使调试和错误跟踪变得困难。

2. CompletableFuture：注意事项和陷阱

2.1 注意事项

异步执行器选择：CompletableFuture 默认使用 ForkJoinPool，这对于轻量级任务是可行的，但对于 I/O 密集型任务或需要更多线程的场景，可能需要指定自定义线程池来避免线程池饱和。
- 建议：为 supplyAsync() 或 runAsync() 提供自定义的线程池。
javaCopy codeCompletableFuture.supplyAsync(() -> someTask(), customExecutor);
异常传播和处理：CompletableFuture 允许在链式调用中处理异常，但需要注意的是，使用 exceptionally() 处理异常会返回一个默认值，并继续任务链。而使用 handle() 可以同时处理异常和结果，因此，选择合适的异常处理方法非常关键。
任务链中的副作用：在 thenApply() 和 thenAccept() 中，避免进行有副作用的操作（如修改全局变量或调用外部服务），以免在异步任务中造成数据不一致。
过长的链式调用：当 CompletableFuture 的链式调用过长时，可能会导致难以理解的代码逻辑和难以跟踪的错误。建议适当拆分复杂的链式调用，并使用注释解释任务的执行流。
无状态问题：由于异步任务可能在多个线程中执行，必须避免在任务中使用非线程安全的全局状态，以防止并发问题。

2.2 常见的坑

线程池资源耗尽：CompletableFuture 默认使用 ForkJoinPool.commonPool()，在高并发环境下可能导致线程池资源耗尽。因此，在 I/O 密集型任务中建议使用自定义线程池。javaCopy codeExecutorService customExecutor = Executors.newFixedThreadPool(10); CompletableFuture.supplyAsync(() -> someIOTask(), customExecutor);
阻塞操作：在 CompletableFuture 的异步任务中进行阻塞操作（如同步 I/O），可能会阻塞公共线程池中的线程，导致其他任务被阻塞。因此，建议在异步任务中使用非阻塞 I/O。
过度的链式组合：过度的 thenCompose() 和 thenCombine() 组合可能会导致任务链的复杂性增加，最终影响代码的可维护性和调试性。
异常的中断传播：在 allOf() 和 anyOf() 的组合任务中，如果某个任务抛出异常，可能会导致整个组合任务失败。需要在组合任务中添加异常处理逻辑来确保任务链的稳定性。javaCopy codeCompletableFuture.allOf(task1, task2) .exceptionally(ex -> { System.err.println("任务失败：" + ex.getMessage()); return null; });

3. 总结

特性	FutureTask	CompletableFuture
执行模式	阻塞式同步调用	非阻塞式异步调用
任务组合	无法组合任务	支持任务组合（`thenCombine`、`allOf` 等）
异常处理	通过 `get()` 捕获异常	支持链式异常处理（`exceptionally`、`handle` 等）
性能	单次任务执行性能高，适用于短期异步任务	更适合复杂的异步任务流和长时间任务，但需注意线程池资源
常见陷阱	任务阻塞、无回调支持、难以组合任务	线程池资源耗尽、阻塞操作影响、过度组合导致链条复杂性

建议

使用 FutureTask 时：应仅用于一次性异步任务或短时间的异步计算，不适合复杂的任务流和回调场景。要特别注意同步问题和任务的重用。
使用 CompletableFuture 时：适合复杂的异步任务组合和流式调用，但需小心过长的链式结构、线程池的选择，以及任务链中异常的传播和处理。

CompletableFuture 默认使用 ForkJoinPool.commonPool() 作为线程池来执行异步任务，这种方式适用于轻量级的计算密集型任务。但是，对于I/O 密集型任务或需要更多线程的场景，这个默认配置可能会导致性能瓶颈甚至线程池饱和，从而降低系统的响应效率。

1. 默认的 ForkJoinPool.commonPool()

CompletableFuture 默认的线程池是 ForkJoinPool.commonPool()，它是一个共享的公共线程池，被所有 CompletableFuture 和其他并发任务（如并行流 Stream.parallel()）共享。它的特点是：

适合计算密集型任务：ForkJoinPool 是为了**分治法（Divide and Conquer）**而设计的，适合在多核环境下并行执行小而短的计算任务。
线程数量有限：默认情况下，ForkJoinPool 的线程数是与 CPU 核心数一致的。例如，在一个 8 核的机器上，默认的线程数是 8。对于CPU 密集型任务，这很合适，因为这样的任务主要依赖于 CPU 的计算能力，更多的线程数不会提高性能。
阻塞任务的潜在问题：ForkJoinPool 并不适合I/O 密集型任务。I/O 密集型任务会导致线程长时间等待外部资源（如文件、数据库、网络请求），而这会阻塞线程，导致线程池被耗尽。

2. 为什么默认 ForkJoinPool 不适合 I/O 密集型任务？

I/O 密集型任务（如数据库查询、文件读写、HTTP 请求等）常常会涉及大量的等待时间，比如等待磁盘 I/O、网络 I/O 或其他外部资源。与计算密集型任务不同，I/O 操作可能会让线程长时间处于阻塞状态，这会导致以下问题：

线程资源耗尽：由于 I/O 操作需要等待较长时间，有限的线程池可能会被阻塞的线程占满，从而导致其他异步任务无法获得线程资源来执行。
高延迟：当 ForkJoinPool 被阻塞的 I/O 任务占用时，其他任务可能会面临更高的排队时间和执行延迟。
吞吐量下降：由于线程被长期阻塞，系统的吞吐量会下降，无法充分利用多核 CPU 的并行处理能力。

3. 解决方案：使用自定义线程池

为了解决这些问题，可以为 I/O 密集型任务使用自定义的线程池，如 CachedThreadPool 或 FixedThreadPool。这可以确保 I/O 密集型任务有足够的线程资源来并发执行。

示例：使用自定义线程池处理 I/O 任务

javaCopy codeimport java.util.concurrent.*;

public class CompletableFutureWithCustomExecutor {
    public static void main(String[] args) {
        // 创建自定义线程池，适合 I/O 密集型任务
        ExecutorService ioExecutor = Executors.newFixedThreadPool(20); // 线程数可以根据需求设置

        // 使用 CompletableFuture 执行 I/O 密集型任务
        CompletableFuture<Void> future = CompletableFuture.supplyAsync(() -> {
            // 模拟 I/O 操作，如数据库查询或文件读取
            simulateIOOperation();
            return "I/O 任务完成";
        }, ioExecutor).thenAcceptAsync(result -> {
            System.out.println(result);
        }, ioExecutor);

        // 等待任务完成
        future.join();
        ioExecutor.shutdown();
    }

    private static void simulateIOOperation() {
        try {
            // 模拟 I/O 等待时间
            TimeUnit.SECONDS.sleep(2);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
}

解释：

自定义线程池：这里使用了 Executors.newFixedThreadPool(20) 来创建一个自定义线程池，该线程池为 I/O 密集型任务提供了额外的线程资源，确保任务能够并行执行，而不会被阻塞。
异步执行 I/O 操作：使用 supplyAsync() 和 thenAcceptAsync() 方法时，指定了自定义的线程池。这样，I/O 操作和回调操作都在独立的线程池中执行，不会占用公共的 ForkJoinPool 资源。
并行处理：通过增加线程池的线程数，可以提高 I/O 操作的并发度，从而避免线程资源耗尽。

4. 自定义线程池的优点

更多的线程数：相比于 ForkJoinPool，FixedThreadPool 或 CachedThreadPool 可以创建更多的线程数，适合处理需要高并发的 I/O 密集型任务。
减少阻塞影响：由于自定义线程池的容量更大，阻塞线程不会影响其他任务的执行，从而提高了系统的整体吞吐量。
灵活性：开发者可以根据实际业务需求调整线程池的大小和类型。例如，CachedThreadPool 可以在高负载下自动增加线程数，而 FixedThreadPool 则有固定数量的线程，更适合控制资源消耗。

5. ForkJoinPool 与自定义线程池的选择

计算密集型任务：
- 适合使用 ForkJoinPool，因为其设计初衷是为计算密集型任务提供高效的分治策略，并充分利用多核 CPU 的并行处理能力。
- 由于计算密集型任务主要占用 CPU 资源，而不会导致长时间的 I/O 等待，ForkJoinPool 的线程数与 CPU 核心数一致，可以实现高效的任务调度。
I/O 密集型任务：
- 建议使用自定义线程池，如 FixedThreadPool 或 CachedThreadPool。这种方式允许线程池在遇到长时间的 I/O 等待时，提供足够的并行线程，防止线程池资源耗尽。
- 自定义线程池可以根据 I/O 密集型任务的特点配置更多的线程数，从而提高任务的并发处理能力。

6. 总结

ForkJoinPool.commonPool()：适合 CPU 密集型任务，不适合 I/O 密集型任务。
自定义线程池：对于 I/O 密集型任务和高并发场景，应使用自定义线程池，以提高性能和吞吐量。

合理选择线程池类型和数量对于提升异步任务的执行效率至关重要，这需要根据任务的特性进行设计和优化。

在同一台机器上运行时，无论是使用公共线程池（如 ForkJoinPool.commonPool()）还是自定义线程池，线程都受制于物理 CPU 核心数的限制。即便如此，自定义线程池可以在特定情况下提升并发性能，避免线程资源枯竭。

1. 自定义线程池和公共线程池的区别

1.1 并行的概念

CPU 核心数确实决定了同一时间内的真正并行计算的线程数，但并不意味着只有 8 个线程。事实上，在高并发的应用中，通常会有比 CPU 核心数多得多的线程被创建。
例如，I/O 密集型任务在等待时可以让出 CPU，而这时另一个任务可以利用 CPU 继续执行。因此，虽然 CPU 核心数限制了同时运行的计算密集型线程，但在有大量 I/O 操作时，可以允许更多线程存在。

1.2 公共线程池的瓶颈

公共线程池（ForkJoinPool.commonPool()）默认使用的线程数等于 CPU 核心数，适合计算密集型任务。如果这些线程被 I/O 操作阻塞，那么新任务可能就无法获得线程资源，从而导致任务队列的积压。
公共线程池中的任务如果被长时间阻塞，那么整个线程池就可能耗尽可用线程，导致新任务无法立即启动。

1.3 自定义线程池的优点

更多的线程数：自定义线程池允许创建比核心数更多的线程，从而提高 I/O 密集型任务的吞吐量。在 I/O 阻塞时，其他线程仍然可以获得 CPU 时间片来执行。
分离不同任务类型：使用单独的线程池来处理不同类型的任务（如 I/O 和计算）可以避免不同任务之间的干扰。例如，计算密集型任务可以在公共线程池中运行，而 I/O 密集型任务可以在自定义的线程池中运行，从而提升系统的整体吞吐量和响应速度。

2. 为什么不会导致线程资源枯竭

2.1 I/O 密集型任务的特点

I/O 密集型任务的主要瓶颈不是 CPU，而是等待 I/O 完成（如网络请求、文件读写）。这类任务的大部分时间都在等待 I/O，而不是消耗 CPU。等待状态下的线程不会占用 CPU 资源。
在这种情况下，即使线程数超过了 CPU 核心数，也不会导致 CPU 的过载，因为这些额外的线程大多处于等待状态。
例如，在一个 8 核机器上，即使创建了 100 个线程，只要大部分线程处于 I/O 等待状态，系统也能正常运行。

2.2 Java 线程模型和并发设计

Java 的线程调度机制是由操作系统内核支持的。即使线程数多于 CPU 核心数，OS 也会基于时间片调度和任务切换来分配 CPU 时间给不同的线程。这意味着虽然某一时刻只有 8 个线程真正占用 CPU，但操作系统会让多个线程交替执行，提升系统的吞吐量。
这种调度模型允许更多的线程同时存在，从而在 I/O 密集型任务场景下提高并发性能，避免资源枯竭。

2.3 合理配置线程池

自定义线程池可以通过设置核心线程数和最大线程数来适应不同的任务类型和负载情况。
- 核心线程数：是线程池中长期保持的线程数，即使在空闲时也不会回收这些线程。
- 最大线程数：是线程池能够容纳的最大线程数，适用于短时间内突增的负载。
- 队列大小：是等待执行的任务数量。通过合理配置队列，可以避免任务过多时的线程创建开销。

3. 为什么自定义线程池不会导致系统吞吐量下降

3.1 提升系统吞吐量的原因

自定义线程池通过增加线程数，使得系统在 I/O 阻塞时仍能处理更多的任务，这实际上提高了并发性能和系统吞吐量。
虽然 CPU 核心数限制了同时运行的计算线程，但并发系统的吞吐量不完全取决于 CPU 核心数，而是由系统的并发处理能力决定的。增加并发的线程数可以在 I/O 密集型任务中充分利用 CPU 和 I/O 资源，提升系统的整体吞吐量。

3.2 合理的资源利用

当自定义线程池与公共线程池共同存在时，它们可以并行处理不同类型的任务，避免单一线程池的阻塞问题。
- 公共线程池可以专注于计算任务，而自定义线程池可以处理 I/O 密集型任务，避免 I/O 阻塞影响计算任务。
- 这种任务分离的设计提高了系统资源的利用率，实现了 CPU 和 I/O 的并发调度。

4. 可能的问题和风险

虽然自定义线程池解决了 I/O 密集型任务的资源占用问题，但需要注意以下几点：

线程过多：如果线程池中的线程数设置过多，可能会导致过多的上下文切换，从而影响性能。
内存消耗：每个线程都有自己的栈空间，创建过多的线程可能会占用大量内存资源，特别是在大规模并发的情况下。
任务饥饿：在某些情况下，如果 I/O 密集型任务过多，可能会导致计算密集型任务无法及时得到调度。

5. 结论

自定义线程池的主要优势在于能够更好地处理 I/O 密集型任务，通过增加并发度来提升系统吞吐量，避免线程资源被阻塞任务耗尽。
尽管物理 CPU 核心数限制了同时并行执行的计算任务数，但在高并发和 I/O 密集的场景下，自定义线程池可以通过更高的线程数来优化资源利用，提升整体性能。

合理的线程池配置和任务类型的分离可以最大限度地利用系统资源，从而实现更高效的并发处理。