ThreadPoolExecutor是高并发场景首选，需按压测调核心参数并自定义拒绝策略；IO密集型任务用CompletableFuture异步编排并指定专用线程池；状态更新用ConcurrentHashMap+CountDownLatch；定时任务优先选ScheduledThreadPoolExecutor。
高并发请求处理：Web服务中用 ThreadPoolExecutor 承接突发流量
电商秒杀、抢票、活动页曝光这类场景，瞬时请求远超单线程吞吐能力。直接为每个请求新建 Thread 会快速耗尽内存和线程栈，且上下文切换开销巨大。必须用线程池控制并发度。
-
ThreadPoolExecutor是实际生产首选，而非Executors.newFixedThreadPool()这类封装——后者使用无界队列，容易因任务积压导致 OOM - 核心参数要按压测结果调：比如
corePoolSize=20、maximumPoolSize=50、workQueue=new ArrayBlockingQueue(100) - 拒绝策略别用默认的
AbortPolicy（抛RejectedExecutionException），建议自定义记录日志+降级返回，避免雪崩
IO密集型任务并行化：数据库查询/HTTP调用用 CompletableFuture 异步编排
一个用户订单页要查订单、库存、物流、优惠券，串行调用可能耗时 800ms+。这些操作本质是等待网络或磁盘响应，CPU 空闲，适合并发发起。
- 别用
Thread.join()或synchronized等待，那是阻塞式思维；用CompletableFuture.supplyAsync()+thenCombine()编排依赖关系 - 注意默认使用
ForkJoinPool.commonPool()，如果 IO 操作多且慢，会挤占 CPU 密集型任务资源；应显式传入专用线程池，如supplyAsync(() -> dao.getOrder(id), ioPool) - 异常处理必须显式调用
exceptionally()或handle()，否则上游收不到失败信号，容易静默丢数据
状态异步更新与事件通知：用 ConcurrentHashMap + CountDownLatch 避免锁竞争
后台任务生成报表后需通知多个下游系统（邮件、短信、IM），但通知失败不能阻塞主流程，也不能重复发。这类“写后触发”场景不适合全局锁。
-
ConcurrentHashMap适合做轻量状态注册表，比如Map<string list>></string>存各业务的回调，读写都无锁 -
CountDownLatch可用于等待所有异步通知完成，但仅限单次等待；若需多次重试，改用CyclicBarrier或状态机更稳妥 - 避免在同步代码块里调用外部服务——哪怕加了
synchronized，也会把整个临界区拖慢；应只同步状态变更，通知逻辑彻底异步剥离
定时与周期性任务：慎用 Timer，优先选 ScheduledThreadPoolExecutor
订单超时关闭、缓存预热、对账任务等，要求准时、可恢复、不丢失。很多老项目还在用 Timer，这是隐患。
立即学习“Java免费学习笔记（深入）”；
-
Timer是单线程执行所有任务，任一任务抛出未捕获异常会导致后续所有调度停止，且无法重试 -
ScheduledThreadPoolExecutor支持多线程、可配置拒绝策略、能捕获任务内异常（通过afterExecute()钩子），更健壮 - 周期任务不要用
scheduleAtFixedRate()直接跑长耗时逻辑；应拆成“触发器+工作队列”，比如定时往BlockingQueue放任务 ID，再由独立线程池消费
真正难的不是启动几个线程，而是理清哪些状态共享、哪些需要隔离、失败后怎么回滚或补偿。并发 bug 往往在线上低概率复现，所以设计阶段就要明确每块数据的读写边界和生命周期。
