Java高并发案例如何优化

wen java案例 2026-06-28 30

Java高并发案例如何优化：从瓶颈突破到极致性能的实战指南

目录导读

高并发的本质与常见痛点
秒杀系统的限流与削峰
缓存穿透、击穿与雪崩的应对
数据库连接池与读写分离
线程池调优与异步化
JVM调优与GC策略选择
高并发优化的核心问答
从案例中提炼的系统优化原则

Java高并发案例如何优化

高并发的本质与常见痛点

在Java面试和实际项目中,“高并发”始终是绕不开的课题，很多开发者写出的代码在单线程下运行流畅，一旦面对每秒数千甚至数万的请求，就会出现响应延迟、CPU飙升、内存溢出甚至系统崩溃。

核心痛点集中在三方面：

锁竞争：synchronized、ReentrantLock等锁导致线程阻塞，吞吐量下降。
资源瓶颈：数据库连接、线程数、内存分配成为木桶的短板。
容量预测不足：突发流量（如大促、秒杀）直接打垮后端。

高并发优化的本质是：在有限硬件资源下，通过合理的架构设计、代码编写和中间件选型，将系统的吞吐量（TPS）提升到可接受水平，并保证响应延迟（RT）稳定。

案例一：秒杀系统的限流与削峰

业务场景：某电商平台618大促，秒杀商品接口瞬间涌入10万请求，后端数据库连接池被打满，导致系统崩溃。

优化前的问题

直接使用INSERT INTO seckill_order插入数据库，所有请求同步写库。
商品库存用UPDATE stock SET count = count - 1 WHERE id = ?，导致大量行锁竞争。

优化方案

第一步：前端限流
使用令牌桶算法（Guava RateLimiter）或Redis+Lua脚本实现令牌桶，每秒只放100个令牌，超过的直接返回“拥挤”提示。

第二步：库存预减+请求队列
将库存预减放在Redis中（使用DECR原子操作），然后在内存中维护一个容量有限的阻塞队列（如ArrayBlockingQueue），将“已减库存”的请求放入队列，由单个线程异步写入数据库，这样DB的写压力从10万降低到队列容量级。

第三步：数据库乐观锁
最后一步写库时，使用UPDATE stock SET count = count - 1 WHERE id = ? AND count > 0，配合版本号字段，避免行锁持续占用。

核心代码片段：

// Redis预减库存
Long remaining = redisTemplate.opsForValue().decrement("seckill:stock:" + productId);
if (remaining < 0) {
    // 库存不足
    return "fail";
}
// 异步队列写入DB
blockingQueue.put(new SeckillOrder(userId, productId));

优化效果：TPS从500提升到5000，DB连接数从200降至20。

案例二：缓存穿透、击穿与雪崩的应对

业务场景：用户查询某个老商品详情，由于缓存未命中，大量请求直接访问数据库，导致DB瞬时QPS飙升。

三大问题分析

缓存穿透：查询一个不存在的数据（如id=-1），每次都会穿透到DB。
缓存击穿：热点key过期瞬间，大量并发请求涌入DB。
缓存雪崩：大量key同时过期，导致DB压力陡增。

优化策略

针对穿透：使用布隆过滤器（Google Guava BloomFilter或Redis Module），先将所有可能存在的id加载进过滤器，查询时先经过过滤器，若不存在直接返回null，不查DB。

针对击穿：对热点key使用互斥锁，当缓存失效时，第一个请求获取锁并查询DB重建缓存，其他请求短暂等待后重新从缓存获取，代码实现：

String value = redisTemplate.opsForValue().get(key);
if (value == null) {
    String lockKey = "lock:" + key;
    if (redisTemplate.opsForValue().setIfAbsent(lockKey, "1", 3, TimeUnit.SECONDS)) {
        value = queryFromDB();
        redisTemplate.opsForValue().set(key, value, 3600, TimeUnit.SECONDS);
        redisTemplate.delete(lockKey);
    } else {
        Thread.sleep(100); // 等待
        return redisTemplate.opsForValue().get(key);
    }
}

针对雪崩：设置不同的过期时间，如3600 + random.nextInt(600)秒；或者对热点key设置永不过期，后台定时更新。

案例三：数据库连接池与读写分离

业务场景：后台管理系统的分页查询接口，每次请求都创建一个新的数据库连接，导致频繁的TCP握手和连接建立开销。

优化点

使用连接池：推荐HikariCP（性能最高），配置参数：

maximumPoolSize：设置为CPU核心数+1（如4核设为5），避免线程竞争。
connectionTimeout：设为3000ms，防止长时间等待。
idleTimeout：设为600000ms，避免空闲连接被频繁关闭和重建。

读写分离：使用ShardingSphere或MyBatis插件，将查询请求路由到从库，写入请求路由到主库，从库可以使用轮询或最少连接算法分配负载。

实际数据：优化前，每次请求花费约50ms用于连接管理；优化后，连接复用率超过95%，连接建立时间从50ms降到0.2ms。

案例四：线程池调优与异步化

业务场景：一个计算密集型报表生成任务，使用默认的newCachedThreadPool()，导致线程无限增长，CPU使用率100%，最终OOM。

调优步骤

明确任务类型：IO密集（如网络请求、磁盘读写）或CPU密集（如复杂运算），对于IO密集型，线程池大小可设为CPU核心数 * 2；对于CPU密集型，设为CPU核心数 + 1。

使用自定义线程池：

ThreadPoolExecutor executor = new ThreadPoolExecutor(
    8,  // coreSize
    16, // maxSize
    60, TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(1000), // 有界队列，避免OOM
    new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略：由调用线程执行
);

异步化改造：使用CompletableFuture并行执行任务，生成报表时，将“查询库存数据”、“查询用户数据”、“计算指标”等无依赖的子任务并行执行，最后通过allOf()合并结果。

优化效果：报表生成时间从15分钟降低到2分钟，CPU使用率稳定在70%。

案例五：JVM调优与GC策略选择

业务场景：一个高并发网关服务，每秒钟处理5000个请求，经常出现Full GC频繁，每次Full GC耗时超过5秒，导致大量请求超时。

调优过程

分析堆内存：使用JDK自带的jstat或VisualVM观察，发现老年代对象增长很快，且Young GC后存活对象频繁晋升到老年代。

优化策略：

增大新生代：将-Xmn从默认的1/3堆提升到1/2堆（例如堆4G，新生代设为2G），减少对象进入老年代的频率。
选择G1垃圾收集器：G1能够设置最大暂停时间目标（-XX:MaxGCPauseMillis=200），适合大堆内存（>4GB）。
调整晋升阈值：-XX:MaxTenuringThreshold=15（默认15），实际建议配合GC日志调整。
对象池化：对频繁创建的对象（如HttpResponse、JSON解析对象）使用池化技术（如Apache Commons Pool），减少GC压力。

调优后效果：Full GC频率从每5分钟一次降低到每小时一次，单次GC暂停时间从5秒降低到100ms内。

高并发优化的核心问答

Q1：优化时是先优化代码还是先扩容机器？
A：一般策略是“先优化后扩容”，先排查是否存在代码层面的明显瓶颈（如SQL未加索引、倒序排序未用覆盖索引、锁粒度过大），若优化后仍无法满足，再考虑加机器做分布式。

Q2：为什么说“无锁化”是终极优化？
A：锁会导致线程上下文切换、缓存行失效，无锁化方案如CAS（AtomicInteger）、CopyOnWriteArrayList、非阻塞队列（ConcurrentLinkedQueue），在低冲突场景下吞吐量远高于锁方案，但需要注意CAS的ABA问题。

Q3：使用缓存一定能提升并发吗？
A：不一定，如果缓存更新频繁（如秒杀库存），每次更新都要同步缓存和DB，反而增加延迟，合理的做法是：对于读多写少的场景（如商品详情），缓存效果极佳；对于写多读少的场景（如日志记录），直接写DB或用消息队列异步。

Q4：如何评估优化效果？
A：使用压测工具（JMeter、wrk、Locust）模拟高并发，重点观察三个指标：