高并发请求处理需用ThreadPoolExecutor、CompletableFuture和ConcurrentHashMap支撑吞吐，避免new Thread()；实时数据聚合用ConcurrentHashMap+LongAdder计数，禁用synchronized；异步任务编排用CompletableFuture链式调用并设超时；资源争用控制需Semaphore限流并结合动态限流组件。
高并发请求处理：Web API 与网关层
电商大促、秒杀活动、抢票系统等场景下，单机每秒数百甚至上万次请求涌入，必须靠 ThreadPoolExecutor、CompletableFuture 和 ConcurrentHashMap 支撑吞吐。比如用 CompletableFuture.supplyAsync() 异步查库存 + 扣减，避免线程阻塞在数据库 I/O 上。
常见错误是直接 new Thread() 处理每个请求——线程创建销毁开销大，且无统一管控，容易 OOM。正确做法是预设核心线程数（如 CPU 核心数 × 2）、设置有界队列（如 new ArrayBlockingQueue(1000)），并配置拒绝策略为 CallerRunsPolicy，让调用方降级或重试。
注意：ForkJoinPool.commonPool() 不建议用于 IO 密集型任务，它默认线程数少（通常为 CPU 核心数 -1），容易卡住整个公共池。
实时数据聚合与计算：风控与监控系统
金融风控需毫秒级判断用户行为是否异常，例如 5 分钟内登录失败超 3 次、同一设备 1 小时内交易超 10 笔。这类逻辑依赖高频写入 + 低延迟读取，ConcurrentHashMap 做本地缓存计数，配合 AtomicInteger 或 LongAdder 更新频次。
立即学习“Java免费学习笔记（深入）”；
关键点在于避免锁竞争：
- 不用
synchronized方法统计，改用map.computeIfAbsent(key, k -> new LongAdder()).increment() - 定时窗口（如滑动窗口）不能靠
Timer，推荐ScheduledThreadPoolExecutor清理过期 key，避免内存泄漏 - 若需跨 JVM 一致性，
ConcurrentHashMap仅作本地加速，最终状态仍要落库或发消息给分布式协调服务
异步任务编排：订单履约与对账系统
一个订单创建后，需并行触发短信通知、积分更新、物流下单、风控校验等多个子任务，任一失败需可追溯、可重试。这时 CompletableFuture 的链式编排能力比原始 Future 更实用。
典型写法：
CompletableFuture.allOf(
sendSms(orderId),
updatePoints(orderId),
createLogistics(orderId)
).exceptionally(ex -> {
log.error("Order {} async tasks failed", orderId, ex);
return null;
});
但要注意：allOf 不抛出子任务异常，要用 whenComplete 或 handle 捕获各阶段结果；若某个子任务耗时显著长于其他（如物流接口超时），应单独设置超时：future.orTimeout(3, TimeUnit.SECONDS)，防止拖垮整体响应。
资源争用控制：数据库连接池与限流器
当多个业务模块共用同一套数据库连接池（如 HikariCP），并发量突增时，连接获取等待时间飙升。此时不能只靠池大小硬扛，得叠加应用层限流 —— 用 Semaphore 控制同时发起的 SQL 查询数。
示例：
private final Semaphore dbQueryPermit = new Semaphore(50);
// ...
if (!dbQueryPermit.tryAcquire(1, 100, TimeUnit.MILLISECONDS)) {
throw new BusinessException("DB query rejected: too many concurrent requests");
}
try {
return jdbcTemplate.queryForObject(sql, rowMapper, params);
} finally {
dbQueryPermit.release();
}
这里 50 是经验阈值，需结合 DB 连接池最大连接数（如 HikariCP 的 maximumPoolSize=30）反推——不能设成 100，否则大量线程卡在 acquire 等待，反而加剧线程上下文切换开销。
真正难的是动态调节：固定阈值无法适应流量峰谷。生产中更常见的是接入 Sentinel 或自研基于 QPS 的滑动窗口限流，而 Semaphore 更适合做稳态保护的最后一道闸门。
