最近从业务层的这段代码，突然对异步线程和协程感兴趣，查阅资料后，弄了个笔记保存一下方便日后查阅
原来的业务代码块：
/** * 异步延迟删除员工缓存 * * @param keys */ public void asyncDelayDeleteCategoryCache(String... keys) { CompletableFuture.runAsync(() -> { try { Thread.sleep(500); for (String key : keys) { redisCache.delete(key); log.debug("清理分类缓存：{}", key); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); log.warn("清理分类缓存线程被中断：{}", e.getMessage()); } }); }
核心演进：从线程到协程
- 原始时代（Thread）
- 特点：直接创建线程执行任务。
- 痛点：线程创建成本高，缺乏生命周期管理（难以获取结果、取消任务）。
- 场景：仅适用于简单场景，不适用于高并发应用。
- 线程池与Future（Java 5）
- 核心：引入线程池（
ExecutorService）和Future接口。 - 机制：
Future作为“任务凭据”，支持查询状态、阻塞等待结果或取消任务。 - 价值：解决了线程资源浪费问题，但缺乏链式处理能力，易导致阻塞或轮询。
- CompletableFuture（Java 8）
- 核心：实现
CompletionStage接口，支持回调注册（如thenApply、thenAccept）。 - 机制：任务完成后自动触发后续逻辑，实现非阻塞异步流水线。
- 价值：摆脱了
Future的阻塞等待，简化了异步编程复杂度。
概念辨析：线程、Future与协程
| 维度 | 操作系统线程 | Future | 协程（虚拟线程） |
|---|---|---|---|
| 本质 | 系统资源（内核级） | 任务契约/接口 | 用户态轻量级线程 |
| 调度者 | 操作系统内核（抢占式） | 线程池（协作式分配） | 语言运行时（协作式） |
| 资源模型 | 1:1（1个Java线程↔1个内核线程） | 依赖线程池配置 | M:N（多协程复用少量内核线程） |
| 核心痛点 | 栈内存占用大（MB级），上下文切换开销高 | 阻塞导致线程饥饿，需手动管理线程池 | 需运行时支持（Java 21+原生支持） |
- Future的本质：
CompletableFuture.runAsync本质是基于线程池的异步。任务提交至线程池（默认ForkJoinPool.commonPool()），由工作线程执行，Future仅管理任务状态。 - 协程的本质：协程是轻量级线程。Java 21的虚拟线程（Virtual Threads）在I/O阻塞时自动“挂起”，载体线程可执行其他任务，单线程可支撑数千协程，极大提升吞吐量。
JVM与垃圾回收（GC）
任务生命周期与GC的关系
- 提交阶段：任务对象被放入线程池工作队列，队列持有强引用，GC不会回收。
- 执行阶段：工作线程从队列取出任务，任务对象被线程栈引用。若任务引用大对象（如缓存数据），这些对象保持存活。
- 完成阶段：任务执行完毕，线程栈帧清理，队列引用移除。任务对象变为不可达（垃圾）。
- GC回收：短生命周期任务分配在新生代（Eden区），下一次Minor GC时快速清理。无需手动干预GC，但需避免线程池队列无限堆积导致内存溢出。
实践中的资源管理
- 线程池隔离原则
- 风险：滥用默认线程池（
commonPool）可能导致全JVM异步任务卡死（如耗时任务占满线程池）。 - 最佳实践：为不同业务场景（缓存清理、短信发送）创建独立的有界线程池。
- 异常处理原则
- 风险：异步任务异常未捕获会被“吞掉”，可能导致任务对象因异常栈持有而延迟GC。
- 最佳实践：通过
try-catch或exceptionally()显式处理异常。
- 协程时代的优化
- 适用场景：I/O密集型应用（Web服务、微服务）。
- 优势：虚拟线程轻量，可像创建对象一样创建，JVM自动调度，无需精细管理线程池大小。
总结
Java异步编程的演进本质是对线程资源的管理与编排能力的进化：Future 是基于线程池的契约模型，而协程（虚拟线程）则是对线程资源的彻底解放。理解二者的关键在于：线程是昂贵的系统资源，协程是廉价的用户态调度。在GC层面，只要线程池配置合理、任务不堆积，内存回收是自动且高效的。