面经策

除了代码，还有哪些地方可以优化性能？ ​

  • 标签：后端、场景题

🏛 业务架构师 ​

"除了代码还有哪些地方可以优化性能"——这题我喜欢，因为它考系统观：性能是全栈工程，代码常常只占瓶颈的三成。我按离业务由近及远分层答。

1. 架构层（收益最大）

  • 缓存：多级缓存（本地 Caffeine + Redis），热点读的万能解
  • 异步化：非核心链路（通知、积分、日志）MQ 化，主链路砍掉等待
  • 读写分离 / CQRS：读流量去从库/搜索/宽表，写路径轻装
  • 预计算：实时算改离线算，排行榜、报表类秒变毫秒

2. 数据库层（性价比最高）

  • 索引优化、慢 SQL 治理、连接池参数、缓冲池大小（innodb_buffer_pool 常年被低估）
  • 冷热分离归档，主表瘦身

3. JVM 与运行时

  • GC 选型与调参（大堆上 G1/ZGC，停顿时间直接进 RT）
  • JIT 预热（低延迟场景的预热请求）

4. 资源与部署

  • 容器 CPU limit / 内存配额是否卡脖子（CPU 被限流的表现是 RT 毛刺，最易被忽略）
  • 混部干扰：和批处理任务同机的噪声
  • 就近部署：跨可用区每次调用 +1ms，链路一长就是几十毫秒

5. 网络与协议

  • 长连接复用（连接池）、HTTP/2 多路复用、序列化换 Protobuf（报文小一个数量级）
  • CDN 静态化，前端体验优化（首屏）

6. 业务层（架构师独有视角）

  • 和产品砍需求：实时刷新改 5 秒轮询、全量展示改分页——很多性能问题是产品定义出来的
  • 降级与弹性：高峰期关闭非核心计算（实时推荐改默认榜单）

收尾：性能优化的钱要花在刀刃上——先全链路压测定基线，找到真瓶颈，再按"架构 > 数据库 > 运行时 > 代码"的顺序动手，最后把优化结果折算成业务语言（RT 降 200ms → 转化提升 X%），这才是能拿到预算的优化报告。

🏗 系统架构师 ​

性能优化"代码之外"的战场非常大，我按请求路径从外到内列，每层给关键数字。

1. 缓存体系 多级缓存（本地 Caffeine → Redis → DB），命中率是核心指标：热点接口本地缓存命中率 40%+、整体缓存命中率 95%+，RT 与 DB 压力数量级下降。

2. 数据库 索引优化、慢查询治理（消灭 100ms+ SQL）、读写分离、连接池参数（HikariCP 的 poolSize 按公式而非默认）、大表归档与冷热分离。多数"应用性能问题"根因在 DB。

3. 异步化与削峰 非主链路（通知、埋点、积分）全部 MQ 异步；秒杀类洪峰用队列 + 预扣减。同步链路每砍掉一个远程调用，RT 降几十毫秒。

4. 网络与部署拓扑

  • 同机房/同 AZ 部署：跨 AZ 一次 RTT ~1~2ms，链路上 10 跳就是 20ms
  • 开启 TCP 连接复用（HTTP keep-alive/连接池），消除反复建连
  • 就近接入：多地部署 + DNS 智能解析，广域网 RTT 从 50ms 降到 5ms

5. JVM 与运行时 GC 选型（吞吐型 Parallel vs 低延迟 ZGC/Shenandoah——P99 敏感服务 2026 年我默认 ZGC）、堆大小与对象分配速率治理、JIT 预热（发版后空跑热点路径）。

6. 基础设施与资源 磁盘类型（NVMe vs SATA 差 10 倍）、网卡与带宽、容器 CPU limit 与线程数匹配（CPU 被限流时线程再多也白搭）、NUMA 绑核。

7. 架构与容量 无状态水平扩展、单元化路由、依赖梳理砍掉重复调用（一次链路里同一接口被调 3 次的"重复依赖"很常见）。

8. 前端与协议 静态资源 CDN、HTTP/2 多路复用、响应体压缩（gzip/br 省 70% 带宽）、Protobuf 替代 JSON。

方法论总结：先全链路压测建基线，找到资源花在哪（CPU/IO/网络/等待），再对症下药——优化永远从测量开始。

💻 全栈开发专家 ​

代码之外的优化空间非常大，我按离请求由近及远的链路讲。

架构层（收益最大）

  • 缓存：多级缓存（本地 Caffeine + Redis），命中率每提升 10%，RT 和 DB 压力都质变。
  • 异步化：非核心链路（通知、积分、日志）走 MQ，主链路 RT 直接瘦身。
  • 并行化：串行 RPC 改 CompletableFuture 并行。

数据库层

  • 索引治理、慢 SQL 清零；读写分离；连接池参数（maximumPoolSize 按压测调）。
  • 数据归档与冷热分离，主表控制在千万级。

JVM 与运行时

  • GC 选型：大堆低延迟场景换 ZGC/Shenandoah（JDK21+ 生产成熟），P99 毛刺显著改善。
  • 容器感知：-XX:MaxRAMPercentage=70 替代写死 Xmx；开启 -XX:+UseContainerSupport。

网络与协议

  • HTTP keep-alive / HTTP2 连接复用，消建连开销。
  • 压缩：响应 gzip/br，内网 RPC 序列化换 protobuf（体积减半以上）。

OS 与内核

  • 文件句柄 ulimit -n、TCP 参数（somaxconn、tcp_max_syn_backlog）。
  • 关闭 CPU 超线程争抢：绑核（低延迟场景）。

K8s/基础设施（2026 重点）

  • CPU limit 造成的 throttling 是隐形杀手：limit=2 的 Pod 瞬时用了 2.5 核就排队，RT 抖动查半天代码结果是资源限制。改 CPU request=limit（Guaranteed）或升 limit。
  • HPA 弹性扩缩容、Pod 反亲和打散热点。

方法论：先监控（SkyWalking + Prometheus）找到真实瓶颈分层，别凭感觉优化——80% 的性能问题出在 IO 和锁，不在 CPU。