17370845950

多线程是解决I/O或计算密集型、可并行且无强依赖的真实瓶颈的可控方案；应优先用CompletableFuture、ScheduledExecutorService等受管机制，配自定义线程池、异常捕获、超时重试与资源隔离。

多线程不是为了“炫技”，而是解决真实阻塞和吞吐瓶颈

Java 多线程在真实项目里几乎从不单独存在——它总是嵌套在某个具体瓶颈里：比如用户请求卡在数据库查询上、第三方 HTTP 接口响应慢、批量文件解析耗时太长。这时候单线程串行处理会拖垮整体响应时间或吞吐量，而多线程（或更现代的 CompletableFuture、ForkJoinPool）是直接且可控的解法。

关键判断标准就一条：任务是否「可并行」+ 「I/O 或计算密集型」+ 「相互无强状态依赖」。满足这三点，才值得开线程；否则加锁、同步、线程安全排查的成本远高于收益。

Web 请求中异步发通知：用 CompletableFuture.runAsync() 而非 new Thread()

典型场景：用户注册成功后，要发邮件、发短信、写日志、更新推荐模型缓存。这些操作都不影响主流程返回（HTTP 200），但全在主线程里串行执行，会让接口 P99 延迟飙升。

• 别手写 new Thread(() -> sendEmail()).start()：没线程池管控，高并发下可能 OOM 或创建海量线程
• 优先用 CompletableFuture.runAsync(Runnable, Executor)，显式传入自定义线程池（如 Executors.newFixedThreadPool(5)），避免挤占 Tomcat 的 common-pool
• 切记：异步任务内发生的异常默认被吞掉，必须调用 whenComplete((r, e) -> { if (e != null) log.error("notify failed", e); }) 主动捕获
• 不要在异步任务里操作 Spring 的 request-scoped bean（如 @RequestScope 的上下文对象），会报 No thread-bound request found

定时批处理任务：用 ScheduledExecutorService 替代 @Scheduled 简单轮询

比如每天凌晨同步 10 万条订单数据到数仓。若用 Spring 的 @Scheduled(fixedDelay = 86400000)，一旦某次执行超时或失败，下次就会堆积，甚至雪崩。

• 改用 ScheduledExecutorService 的 scheduleWithFixedDelay，确保上次执行完才等 delay，不重叠
• 批处理本身再拆成多线程：用 ForkJoinPool.commonPool() 或专用线程池，并行读 DB 分页（如每页 500 条）、转换、写入 Kafka
• 务必设置查询超时和重试：JDBC URL 加 socketTim

  

  eout=30000，MyBatis 的 timeout 属性设为 30 秒，避免一个慢查询卡住整个批次
• 记录断点位点（如最大 order_id），失败时从断点续跑，而不是全量重刷

高并发导出报表：用 CountDownLatch + 内存缓冲控制资源占用

用户点击“导出全部订单”，后端不能把几百万行一次性查出来再写 Excel——内存直接爆，GC 频繁，Tomcat 线程卡死。

• 分页查库（每次 1000 行），每页交给一个 Runnable 处理，用 CountDownLatch 等待所有页写入临时文件完成
• 写文件不用 Apache POI 的 XSSFWorkbook（内存全驻留），改用 SXSSFWorkbook，指定 rowAccessWindowSize=1000
• 导出接口立即返回任务 ID，前端轮询 /export/status?id=xxx，后端用 ConcurrentHashMap 存状态
• 临时文件写完立刻触发 sendFile 或生成预签名 URL，避免长期占用磁盘

真正难的从来不是“怎么开线程”，而是“怎么让多个线程协作时不互相踩脚、不抢光数据库连接、不把 JVM 内存吃满”。每个线程池的大小、每个异步任务的超时、每个共享资源的访问粒度，都要结合压测数据调，而不是拍脑袋设个 10 或 100。