跳转到主内容
极星编程网:以代码为星,赴技术山海!

Java并发编程适合哪些业务场景_实际应用案例说明

高并发请求处理需用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
更实用。 Eclipse导入Android或其他的JAVA项目的正确方法 WORD版 本文档主要讲述的是Eclipse导入Android或其他的JAVA项目的正确方法;希望本文档会给有需要的朋友带来帮助;感兴趣的朋友可以过来看看 下载 典型写法:
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
更适合做稳态保护的最后一道闸门。

相关文章