2023年Stack Overflow调研显示，47%的Java开发者仍在用裸线程处理并发。同一时期，Spring Boot的ExecutorService（执行器服务）已经迭代了8个主版本， CompletableFuture（可完成 future）从Java 8发布至今快10年——但多数人只用过最基础的submit()和get()。
这不是技术落后，是文档的锅。官方示例永远写着"Hello World"级别的代码，真实生产环境的熔断、限流、线程池监控，得靠开发者自己从Stack Overflow碎片里拼凑。
01 线程池不是越大越好，这个公式骗了太多人
网上流传的"线程数=CPU核数+1"在微服务场景下基本失效。Spring Boot 2.7之后，自动配置类TaskExecutionAutoConfiguration（任务执行自动配置）会根据应用类型动态调整，但默认参数针对的是传统单体应用。
某电商平台的真实案例：双11期间订单服务线程池飙到500，结果GC（垃圾回收）时间占比从2%涨到37%。根因不是业务量大，是线程上下文切换开销被严重低估。最终调优方案是把核心线程数压到CPU核数的2倍，队列改用LinkedBlockingQueue（链表阻塞队列）并设容量上限，配合CallerRunsPolicy（调用者运行策略）做兜底。
关键指标不是吞吐量，是拒绝请求时的降级能力。
Spring Boot 3.2新增的虚拟线程支持改变了游戏规则。Project Loom（织机项目）的虚拟线程在JVM（Java虚拟机）层面模拟轻量级线程，单个平台线程可承载数千虚拟线程。但别急着全量迁移——虚拟线程适合IO密集型，计算密集型任务反而会因为pinning（钉住）问题导致平台线程被独占。
02 CompletableFuture的"异步"是个文字游戏
90%的开发者没意识到：CompletableFuture.supplyAsync()默认用的是ForkJoinPool.commonPool()（公共分叉合并池），线程数等于CPU核数减一。这意味着你的"异步"操作可能在和Stream.parallel()抢资源。
正确的打开方式是显式指定Executor（执行器）。Spring Boot里可以注入ThreadPoolTaskExecutor（线程池任务执行器）的自定义实例：
```java @Bean("customExecutor") public Executor customExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePoolSize(10); executor.setMaxPoolSize(20); executor.setQueueCapacity(200); executor.setThreadNamePrefix("biz-"); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } ```
然后每个异步操作都带上这个执行器：supplyAsync(() -> fetchOrder(id), customExecutor)。多写这一行，生产环境少崩半夜。
异常处理是另一个深坑。CompletableFuture的exceptionally()和handle()看起来功能重叠，实际语义完全不同。前者只捕获异常并返回默认值，后者无论成功与否都会执行，适合需要统一日志或埋点的场景。某金融科技公司曾因混用两者，导致风控回调异常时既没触发熔断，也没记录失败日志，排查花了14小时。
03 自修复不是玄学，是三个开关的组合拳
Netflix的Hystrix（熔断器）停止维护后，Spring Cloud Circuit Breaker（断路器）成了事实标准。但很多人只配了熔断阈值，忽略了半开状态的探测频率。
Resilience4j（弹性4j）的实现细节：半开状态默认允许3个测试请求，全部成功才关闭熔断。这个数值在突发流量场景下过于乐观。某社交App把探测请求提到10个，配合指数退避的重试间隔，服务恢复时间从平均90秒降到12秒。
线程池隔离比信号量隔离更耗资源，但能提供真正的故障隔离。
信号量隔离只是限制并发数，阻塞线程仍在占用。线程池隔离给每个依赖分配独立线程池，慢调用不会拖垮整个服务。代价是上下文切换开销——所以Spring Cloud 2022.0.0之后推荐混合模式：核心链路用线程池，边缘功能用信号量。
监控层面，Micrometer（微米计）+ Prometheus（普罗米修斯）的组合可以暴露线程池的活跃线程数、队列积压量、拒绝次数。但默认指标粒度太粗，需要自定义MeterBinder（计量器绑定器）来追踪具体业务方法的线程等待时间。
04 虚拟线程上线前，先回答这三个问题
Spring Boot 3.2的虚拟线程支持不是银弹。Oracle官方文档列了12种pinning场景，最常见的是synchronized块和本地方法调用。某物流系统迁移后性能反而下降，排查发现是PDF生成库调用了本地Graphics2D（图形2D）渲染，导致虚拟线程被钉在平台线程上。
三个自测问题：
第一，代码里有没有synchronized？有的话换成ReentrantLock（可重入锁），后者支持虚拟线程的unmount（卸载）。
第二，有没有JNI（Java本地接口）调用或本地库依赖？这些操作会强制pinning。
第三，线程本地存储（ThreadLocal）用得多吗？虚拟线程的ThreadLocal实现是惰性拷贝的，高频访问会有额外开销。
如果三条都中，先别急着升级。Spring Boot 3.2允许通过spring.threads.virtual.enabled=false显式关闭虚拟线程，等依赖库适配后再开。
最后说个反直觉的发现：GitHub上star数最高的Spring Boot多线程示例项目，其核心配置类里线程池参数全是硬编码。这意味着复制粘贴的开发者，生产环境的线程数和本地笔记本的CPU核数绑定了——而笔记本通常是8核，服务器可能是64核或128核。
热门跟贴