大秀视频后端高并发优化实战 附完整示例与压测数据
刚接手大秀视频直播后台时，最头疼的不是业务逻辑，而是监控大屏上那条随时可能爆表的 CPU 曲线。凌晨三点，报警电话响个不停，翻开日志全是 java.lang.OutOfMemoryError: Java heap space 和密密麻麻的 StackTrace。报错一堆看不懂，线程栈里全是 BLOCKED 状态，那一刻真的想砸键盘。
别慌，这种场景太常见了。大秀视频这类直播互动场景，特点是读多写少、瞬时流量大、依赖外部服务多。今天不讲虚的，直接上干货。我复盘了当时踩过的坑，把优化前后的代码、压测数据、排查思路全部整理出来。文中包含可运行的 完整示例，你可以直接拿去跑，对比性能差异。哪怕你刚转行后端，只要跟着做，也能把响应时间从秒级降到毫秒级。
一、 性能瓶颈定位：别猜，用数据说话
很多新手遇到慢，第一反应是“加机器”或“加索引”。错了。在动手改代码前，必须先定位瓶颈。在大秀视频的业务场景中，主要瓶颈集中在三处：JSON 序列化开销、数据库连接池等待、以及 N+1 查询问题。
以直播间弹幕列表接口为例，最初的表现是 QPS 刚过 500，P99 延迟就飙到 800ms 以上。使用 Arthas 的 trace 命令追踪方法调用耗时，发现 70% 的时间消耗在 Jackson 的 ObjectMapper.writeValueAsString 上。
为什么 JSON 序列化这么慢？因为当时的对象树太深，嵌套层级超过 5 层，且包含大量 MapString, Object 动态字段。Jackson 在反射处理动态结构时，性能衰减严重。
另外，通过 Druid 监控发现，数据库连接池经常处于满载状态，active 线程数逼近 maxActive。原因不是 SQL 慢，而是业务代码在循环中执行单条查询。
核心结论：序列化是 CPU 杀手：复杂对象频繁序列化，CPU 打满。
连接池是 IO 瓶颈：N+1 查询导致连接长期占用，新请求只能排队。
GC 压力巨大：大量临时对象产生，Young GC 频率极高，导致 STW（Stop The World）暂停。二、 优化前代码：典型的反面教材
为了复现问题，我提取了当时典型的“坏代码”片段。这段代码负责获取直播间最近 50 条弹幕，并附带用户头像和昵称。
// 优化前：高耗时、高资源占用
@Service
public class BulletChatServiceOld {@Autowiredprivate BulletChatMapper chatMapper;@Autowiredprivate UserService userService;@Autowiredprivate ObjectMapper objectMapper;public ListChatVO getRecentChats(Long roomId) {// 1. 查询最近50条弹幕 ID 和 用户IDListChatPO chats = chatMapper.selectRecentByRoomId(roomId, 50);ListChatVO result = new ArrayList(50);// 2. 典型的 N+1 问题：循环内查用户信息for (ChatPO chat : chats) {ChatVO vo = new ChatVO();vo.setId(chat.getId());vo.setContent(chat.getContent());vo.setCreateTime(chat.getCreateTime());// 致命伤：每条弹幕都查一次用户表// 假设用户表有索引，单次 2ms，50次就是 100msUserPO user = userService.getUserById(chat.getUserId());if (user != null) {vo.setNickname(user.getNickname());vo.setAvatar(user.getAvatarUrl());}result.add(vo);}// 3. 内存中构建复杂 JSON 字符串用于日志或缓存预热// 这里只是为了演示序列化开销，实际业务可能用于 Redis 存储for (ChatVO vo : result) {try {// 每次循环都创建新的 Writer 和序列化开销String jsonStr = objectMapper.writeValueAsString(vo);// 假设这里写入 Redis 或发送 MQ// redisTemplate.opsForValue().set(chat: + vo.getId(), jsonStr);} catch (JsonProcessingException e) {log.error(JSON serialize error, e);}}return result;}
}这段代码的问题点：N+1 查询：50 条弹幕，触发 1 次列表查询 + 50 次用户查询。数据库往返次数过多，TCP 握手和数据传输开销巨大。
循环内序列化：ObjectMapper 是线程安全的，但频繁调用 writeValueAsString 会产生大量临时字节数组，增加 GC 压力。
缺乏批量处理：用户信息查询完全可以批量获取，而不是逐条获取。三、 优化方案与代码：批量查询 + 对象池 + 缓存
针对上述问题，我们采取了三个核心优化策略：批量查询消除 N+1、对象池复用减少 GC、本地缓存热点数据。
1. 消除 N+1：批量查询用户信息
将循环内的单条查询，改为收集所有 userId，一次性查询。
2. 序列化优化：使用 String 缓存或 Protobuf
对于结构固定的数据，JSON 并不是最优解。但在 Java 生态中，如果必须用 JSON，可以使用 String 直接缓存，或者引入 Protobuf/Kryo 等二进制序列化方案。这里为了通用性，我们展示如何通过减少不必要的序列化来优化。在实际的大秀视频高并发场景中，我们最终将部分非持久化数据改为 Kryo 序列化，性能提升 3 倍。但考虑到读者易上手，下面代码依然使用 Jackson，但优化了调用方式。
3. 引入 Caffeine 本地缓存
对于用户昵称、头像等读多写少且更新频率低的数据，引入本地缓存。大秀视频用户数千万，但单个直播间活跃用户有限，本地缓存命中率极高。
// 优化后：高并发、低延迟
@Service
public class BulletChatServiceNew {@Autowiredprivate BulletChatMapper chatMapper;@Autowiredprivate UserMapper userMapper; // 直接注入 Mapper 以便批量查询// 1. 本地缓存：用户基础信息// Caffeine 比 Guava Cache 性能更好，推荐使用private final CacheLong, UserPO userLocalCache = Caffeine.newBuilder().maximumSize(10_000).expireAfterWrite(10, TimeUnit.MINUTES).build();@Autowiredprivate ObjectMapper objectMapper;public ListChatVO getRecentChats(Long roomId) {// 1. 查询最近50条弹幕ListChatPO chats = chatMapper.selectRecentByRoomId(roomId, 50);if (CollectionUtils.isEmpty(chats)) {return Collections.emptyList();}// 2. 提取所有 userId，去重ListLong userIds = chats.stream().map(ChatPO::getUserId).distinct().collect(Collectors.toList());// 3. 批量查询用户信息MapLong, UserPO userMap = new HashMap(userIds.size());// 先查本地缓存ListLong missUserIds = new ArrayList();for (Long uid : userIds) {UserPO cachedUser = userLocalCache.getIfPresent(uid);if (cachedUser != null) {userMap.put(uid, cachedUser);} else {missUserIds.add(uid);}}// 再查数据库（仅查未命中的）if (!missUserIds.isEmpty()) {// 假设数据库支持 IN 查询，注意限制数量防止 SQL 过长ListUserPO dbUsers = userMapper.selectByIds(missUserIds);for (UserPO user : dbUsers) {userMap.put(user.getId(), user);// 回填本地缓存userLocalCache.put(user.getId(), user);}}// 4. 组装 VOListChatVO result = new ArrayList(chats.size());for (ChatPO chat : chats) {ChatVO vo = new ChatVO();vo.setId(chat.getId());vo.setContent(chat.getContent());vo.setCreateTime(chat.getCreateTime());UserPO user = userMap.get(chat.getUserId());if (user != null) {vo.setNickname(user.getNickname());vo.setAvatar(user.getAvatarUrl());}result.add(vo);}// 5. 序列化优化：如果必须序列化，建议只在出口处一次性序列化整个 List// 而不是循环内单条序列化。如果用于 Redis，建议直接存储 ListChatVO 的字节数组// 这里假设不需要中间序列化，直接返回对象// String json = objectMapper.writeValueAsString(result); // 仅在必要时调用return result;}
}关键改动解析：批量查询：50 次 DB 交互变为 1 次（或更少，取决于缓存命中率）。
Caffeine 缓存：用户信息在内存中，响应时间从毫秒级降至纳秒级。
减少对象创建：HashMap 预分配容量，减少扩容开销。
序列化后置：移除了循环内的序列化逻辑，仅在必要时（如返回给前端由 Spring 处理，或存入 Redis）统一处理。四、 对比数据：用 JMeter 压测说话
为了验证优化效果，我们在预发环境进行了 JMeter 压测。
环境配置：4C8G 云主机，MySQL 8.0，JDK 11，G1 GC。
测试场景：并发 1000 线程，持续 10 分钟，请求 getRecentChats 接口。指标
优化前 (Old)
优化后 (New)
提升幅度QPS
520
3,850
642%P99 延迟
850 ms
12 ms
98.6% 降低Avg CPU
85%
35%
58% 降低Young GC 次数/分
120 次
15 次
87.5% 降低DB 连接池等待
频繁
无
消除数据解读：QPS 提升 6 倍：主要得益于批量查询和本地缓存，DB 压力骤降。
P99 延迟从 850ms 降到 12ms：消除了 IO 等待和 GC STW 的影响。
CPU 下降：减少了反射调用和临时对象分配，CPU 主要用于业务逻辑而非序列化。注：以上数据基于内部压测环境，实际生产环境受网络、数据量影响会有波动，但趋势一致。五、 落地建议与避坑指南
性能优化不是一次性的工作，而是持续的过程。结合大秀视频的实战经验，给转岗或初级开发者几点建议：
1. 不要过早优化，但要关注架构
在业务初期，代码清晰比性能更重要。但当 QPS 超过 1000 时，必须开始关注。架构上，读写分离和缓存分层（Redis + 本地缓存）是标配。
2. 警惕 N+1 查询
这是 Java 后端新手最容易犯的错误。只要看到 for 循环里有 mapper.select 或 service.get，立刻警觉。养成批量查询的习惯。可以使用 MyBatis-Plus 的 selectBatchIds 或自定义 XML 批量查询。
3. 缓存一致性
本地缓存（如 Caffeine）存在数据不一致风险。在用户信息修改时，需要主动失效本地缓存。如果集群部署，建议结合 Redis 作为一级缓存，Caffeine 作为二级缓存，或者使用 Redis + MQ 广播失效消息。
4. 序列化选型内部通信/RPC：推荐 Protobuf 或 Kryo，速度快，体积小。
对外 API：JSON 依然是标准，因为可读性和兼容性。
日志/监控：尽量使用 StringBuilder 拼接，避免复杂的 JSON 序列化。5. 监控先行
没有监控的优化是盲改。接入 Prometheus + Grafana，关注：JVM：GC 时间、堆内存使用率。
DB：连接池活跃数、慢查询日志。
业务：接口 P99 延迟、错误率。6. 参考开源项目
如果想深入理解高并发架构，可以参考 GitHub 上的开源仓库。例如 Seata 的分布式事务处理，或 Spring Cloud Alibaba 的限流熔断组件。大秀视频的部分中间件选型也参考了这些开源社区的 Best Practice。特别是 Caffeine 的源码，值得读一读，它的 W-TinyLFU 算法在缓存命中率上远超 LRU。
最后，聊聊一个争议点：
在批量查询中，你是倾向于**“查数据库后回填缓存”，还是“先查缓存，再批量查库”**？
前者逻辑简单，但可能污染缓存；后者命中率高，但代码复杂。在用户信息这种高频读场景，我推荐后者。但如果是订单状态这种强一致性要求场景，你怎么做？
你更常用哪种写法？评论区交流，或者分享你遇到的性能瓶颈，一起拆解。
