性能问题排查实战手册

FCP 慢的本质：关键渲染路径上的资源太重

浏览器从拿到 HTML 到渲染出第一个内容（FCP），要经历：① 下载 HTML → ② 下载 CSS/JS（阻塞渲染）→ ③ 解析编译 JS → ④ 构建 DOM + CSSOM → 渲染树 → 绘制

如果 JS 太大（vendor.js 1.2MB），下载和编译都要好几秒，FCP 自然慢。关键渲染路径上的每个阻塞资源都会拖慢首屏。

技术原理：浏览器渲染流程 — HTML 解析 → 遇到 CSS 会阻塞渲染（等 CSSOM）→ 遇到没有 async/defer 的 JS 会同时阻塞解析和渲染。关键渲染路径上的资源越多越重，FCP 越慢。

连接池耗尽原理：Redis 连接池 maxActive=8，高峰期 50 个并发请求同时竞争连接。每个请求必须等前面的释放连接才能拿到，排队等待时间 1700ms。

技术原理：Redis 连接池（Lettuce/Jedis）配置过小时，当并发请求超过连接数，后续线程会阻塞等待连接释放。如果连接池 maxActive=8，而 QPS=320，平均每个请求占用连接 5ms，那理论最大吞吐量 = 8 / 0.005 = 1600 QPS。但如果个别慢请求（大 key）占着连接不放，实际吞吐量远低于理论值。

filesort 原理：索引 idx_category_id 只能快速定位 category_id 匹配的行，但 ORDER BY sales_count 排序无法利用该索引。MySQL 只能把所有匹配行取出到内存（或临时文件）中，再做一次排序 —— 这就是 filesort。

技术原理：MySQL 索引是 B+ 树结构。查询条件用 category_id，排序用 sales_count，这两个字段不在同一个索引上，MySQL 无法利用索引的有序性完成排序，只能做 filesort。解决方案是创建联合索引 (category_id, status, sales_count)，让索引同时覆盖 WHERE 过滤和 ORDER BY 排序。

缓存三大问题原理：

• 缓存穿透：查询不存在的数据（如传入不存在的商品ID），缓存中没有，每次都打到 DB。防护：布隆过滤器或缓存空值。

• 缓存击穿：热点 key 过期的瞬间，大量并发请求同时打到 DB。防护：互斥锁或永不过期+异步刷新。

• 缓存雪崩：大量 key 同时过期（如启动时批量设了相同 TTL），DB 瞬间承压。防护：TTL 加随机值，错开过期时间。

本次问题属于：缓存回写缺失 + 覆盖率低。大量请求根本没走缓存。

房间整理类比：你的桌面（Eden 区）很小，随手放东西（新对象创建），桌面满了就要快速扫一眼：有用的收进抽屉（Survivor 区），没用的扔垃圾桶（Young GC），整个过程 1 秒搞定。抽屉里很久没清理的东西最终搬进储物间（Old Gen）。但储物间也满了，你要彻底翻箱倒柜整理整个房间（Full GC），要 10 分钟，整理期间谁也不能用这个房间（STW）。桌面越小，清理越频繁，别人等得越久。

技术原理：JVM 堆分为 Eden + Survivor + Old。新对象分配在 Eden，Eden 满了触发 Young GC（STW）。如果堆太小或分配速率太高，GC 频率就高。G1 GC 的 STW 时间与存活对象数量成正比，频繁 GC 意味着频繁暂停业务线程。

线程池耗尽原理：Tomcat 线程池 maxThreads=200，其中 156 个线程被阻塞在等待支付网关响应（超时 30s）。真正能处理新请求的线程只剩 44 个，新的请求进来就排队溢出，触发拒绝策略返回 503。

技术原理：Tomcat 用线程池处理 HTTP 请求。当所有线程都被阻塞在慢操作（同步调用外部支付网关）上，新请求进不来。解决方案不是简单增大线程池（线程也是资源），而是把同步阻塞调用改成异步非阻塞，让线程不被长时间占用。

DOM 节点过多导致卡顿原理：12,000 条订单 = 12,000 个 DOM 节点。每次滚动时浏览器要重新计算这些节点的位置（Layout Reflow）。但用户屏幕实际只能显示 ~20 条，其余 11,980 个节点完全不可见却在拖累渲染性能。

虚拟列表原理：只渲染可视区域内的 DOM 节点（~20 个），加上上下各 5 个缓冲节点，总共只有 30 个 DOM 节点。滚动时动态替换可视区域内容，DOM 总数恒定，性能恒定。

CDN 回源率高的原理：CDN 边缘节点本应缓存静态资源，用户就近获取。但如果源站返回的响应头设置了 Cache-Control: no-cache 或 TTL 太短，边缘节点不敢缓存，每次请求都要回源到 Nginx，CDN 等于白部署了。

技术原理：CDN 节点根据源站返回的 Cache-Control 头决定是否缓存。no-cache 表示每次都要验证，no-store 表示完全不缓存。静态资源（JS/CSS/图片）应该设置长期缓存 + 文件名 hash 实现缓存更新。

分片上传原理：整文件上传 100MB，任何一个分片失败就要从头来。分片上传把 100MB 拆成 20 个 5MB 分片，每个分片独立上传，失败只需重传那一片。还可以多分片并发上传，大幅缩短总时间。

技术原理：大文件分片上传将文件切成固定大小的块（如 5MB/片），每片独立上传，失败只需重传该分片。所有分片上传完成后，服务端合并文件。还可以用文件内容 hash 做秒传（文件已存在则跳过上传）。

WebSocket 断连原理：WebSocket 是长连接，但如果 60 秒内没有数据传输，中间的代理/负载均衡器（Nginx）会认为连接已经空闲，主动断开。解法：客户端定时发心跳包（ping），保持连接活跃。

技术原理：Nginx 作为反向代理转发 WebSocket 连接时，proxy_read_timeout 默认 60s。如果这段时间内没有数据从上游服务器读取到，Nginx 会关闭连接。解决方案：① 增大超时时间 ② 客户端/服务端定期发送心跳 ping/pong 保活 ③ 客户端实现指数退避重连。

N+1 查询原理：先查 20 条订单（1 次 SQL），然后循环中每条订单各查一次商品详情（20 次 SQL），总共 21 次。改为批量查询：收集所有 product_id，一条 SELECT * FROM product WHERE id IN (...) 查出全部，再在内存中关联，只需 2 次 SQL。

技术原理：ORM 框架（JPA/MyBatis）默认懒加载关联对象，访问关联属性时触发额外 SQL。在循环中访问 N 条记录的关联对象，就产生 N 条额外 SQL。修复方式：JOIN 查询、批量查询、MyBatis 的 association/collection 嵌套映射、JPA 的 @EntityGraph。

跨机房网络抖动原理：上海和北京机房之间走的是公网链路，经过多个路由跳转。公网延迟受拥塞、丢包影响，不像同机房内网稳定（<1ms）。高峰期公网带宽紧张时，延迟从 25ms 飙到 1850ms，丢包率 3%。解法：专线/VPN + 超时降级 + 本地缓存。

技术原理：跨机房走公网/VPN，网络质量受运营商链路影响。高延迟+丢包导致 TCP 重传，RT 进一步恶化。解决方案：① 专线/高速通道（稳定低延迟）② 同机房部署 ③ 重试+超时+降级策略 ④ 异步化调用。

日志 IO 瓶颈原理：每个请求打印 10+ 行完整请求体/响应体日志，高峰期 300 QPS × 10 行 = 每秒 3000 行写入。磁盘写入速度跟不上，iowait 飙到 45%，所有依赖磁盘的操作（包括数据库写入）都被拖慢。解法：异步日志（AsyncAppender）+ 采样 + 分级。

技术原理：日志框架（Logback/Log4j2）默认同步写入磁盘。高频写入产生大量小 IO 操作，机械磁盘（或云盘）随机写入性能有限。同步日志意味着业务线程要等 IO 完成，iowait 高 = CPU 在等磁盘 = 整体吞吐量下降。

前端内存泄漏原理：SPA 不刷新页面，每次路由切换/数据更新都在分配内存。如果组件销毁时没有清理定时器、事件监听器、闭包引用，这些内存永远无法被 GC 回收。长时间运行后内存持续增长，最终页面卡死。排查工具：Chrome DevTools Memory 面板 → Heap Snapshot 对比。

技术原理：JavaScript 使用垃圾回收（GC）自动管理内存。但如果有引用链从根对象（window/global）可达，GC 就不会回收。常见泄漏：① 全局变量/闭包引用 ② 未移除的事件监听器 ③ 未关闭的 WebSocket/setInterval ④ DOM 引用未释放 ⑤ 组件销毁时未清理定时器和监听器。