“双十一零点刚过，系统就挂了！”——这可能是技术人最怕听到的话。高并发就像一场突如其来的暴雨，若没有提前筑好堤坝，再强大的系统也会被瞬间冲垮。本文将从真实案例出发，揭秘Java系统应对高并发的15项实战技巧，教你用“疏堵结合”的策略，让系统在流量洪峰中稳如泰山。

限流：给系统装上“智能水闸”

场景：某电商平台促销时，每秒涌入10万请求，但系统实际承载力仅为3万。

1.四大限流算法实战选型固定窗口计数器：简单粗暴，但存在临界点突发流量风险（如窗口切换瞬间涌入双倍请求）滑动窗口：将1秒切分为10个100ms的格子，实时统计最近1秒请求量，避免流量突刺漏桶算法：以恒定速率处理请求（如每秒100次），适合平滑流量但可能丢弃突发请求令牌桶算法：预存令牌，允许突发流量（如每秒生成100个令牌，瞬间可消耗200个）

代码示例：Guava RateLimiter实现令牌桶

JavaRateLimiter limiter = RateLimiter.create(1000); // 每秒1000个令牌 if(limiter.tryAcquire()) { // 执行业务逻辑 } else { throw new ServiceUnavailableException("系统繁忙，请稍后重试"); } 2.分级限流策略全局限流：保护核心接口（如支付），全集群共享计数器用户级限流：单用户每秒最多5次请求，防刷接口资源级限流：针对热点商品ID设置独立阈值

案例：某社交平台对热搜话题接口实施动态限流，根据Redis实时统计调整阈值，避免单个话题拖垮系统。

线程池：别让“工人”累死在车间

惨痛教训：某金融系统使用默认线程池，突发流量下线程数暴涨至5000，导致OOM宕机。

1.线程池参数黄金公式IO密集型：核心线程数 = 2 * CPU核数CPU密集型：核心线程数 = CPU核数 + 1队列选择：LinkedBlockingQueue：适合平稳流量，但可能堆积任务SynchronousQueue：直接传递任务，配合最大线程数防堆积2.动态调优黑科技JavaThreadPoolExecutor executor = new ThreadPoolExecutor(...); executor.setCorePoolSize(20); // 运行时动态调整核心线程数

监控指标：

活跃线程数 > 80%最大线程数 → 触发扩容队列堆积 > 1000 → 触发告警

避坑指南：禁止使用Executors.newCachedThreadPool()，避免线程数失控。

缓存：给数据库穿上“防弹衣”

血泪案例：某资讯平台因缓存雪崩，导致数据库被打挂，宕机2小时。

1.三级缓存架构本地缓存（Caffeine）：5秒过期，应对瞬时高频读取Redis集群：30分钟过期，存储热点数据数据库：终极存储，通过binlog异步更新缓存2.缓存问题终极解法

问题类型

解决方案

代码示例

缓存穿透

布隆过滤器拦截非法ID

BloomFilter.create(...)

缓存击穿

分布式锁+逻辑过期

Redisson锁实现

20

缓存雪崩

随机过期时间+本地降级

expire = baseTime + random(300)

创新方案：热点数据预热——通过Flink实时分析用户行为，提前加载可能的热点商品数据。

数据库：最后一公里的生死时速

真实场景：某物流系统分库分表后，QPS从2000提升至2万。

1.连接池优化四板斧maxPoolSize=50（避免过多连接拖垮DB）minIdle=5（保持最小活跃连接）testOnBorrow=true（防止拿到失效连接）validationQuery="SELECT 1"（心跳检测）2.分库分表实战技巧垂直拆分：用户表拆分为基础信息表+扩展表水平拆分：按用户ID哈希分128张表冷热分离：3个月前的订单归档至ClickHouse

避坑指南：禁止在事务中跨库查询，采用最终一致性补偿。

异步化：让系统学会“分身术”

成效对比：某支付系统接入MQ后，支付成功率从85%提升至99.9%。

1.全链路异步方案Web层：Tomcat配置NIO模式，worker线程数=200Service层：使用@Async处理日志记录等非核心操作CompletableFuture实现并行调用数据层：消费MQ异步写ES索引批量合并请求减少DB压力2.性能对比数据

方案

吞吐量

响应时间

同步

1200 QPS

200ms

异步

6500 QPS

50ms

创新实践：机票查询系统将20个第三方API调用并行化，响应时间从5秒降至800ms。

终极防线：熔断与降级

救命案例：某银行系统在流量暴涨时，自动降级非核心功能，保住支付核心链路。

1.熔断器三态转换Closed：正常放行请求Open：直接拒绝请求Half-Open：试探性放行部分请求2.降级策略读降级：返回本地缓存/默认值写降级：将请求存入Redis队列异步处理功能降级：关闭商品评价功能保下单流程

Sentinel实战：

JavaFlowRule rule = new FlowRule("payApi") .setGrade(RuleConstant.FLOW_GRADE_QPS) .setCount(1000); // 每秒最多1000次调用

高并发防御不是一劳永逸的战役。某头部电商的限流规则库每天更新300+次，正是这种持续优化的精神，让他们在双十一的流量海啸中屹立不倒。好的系统不是设计出来的，而是在与流量的搏斗中成长起来的。