千鹤酱的开发笔记｜那些年踩过的坑与调优思路

千鹤酱的开发笔记为什么值得反复翻看

千鹤酱的开发笔记是我在排查线上故障时经常回头翻的一份记录。去年双十一大促当晚，订单接口突然超时暴涨，我按笔记里一段关于连接池的排查思路，十分钟就定位到了数据库连接泄漏的问题。这份笔记不堆砌概念，更像一个经验贴，把踩过的坑和对应的JVM 参数、线程池配置都列得明明白白，尤其是在接口响应时间优化这类高频场景里，能直接当操作手册用。

很多同学问过我为什么不用官方文档，其实官档更像字典，而千鹤酱的开发笔记更像一张故障地图。比如它会把“接口突然变慢”拆成慢查询、GC 停顿、下游超时三条分支，每条都附上了当时使用的jstack和arthas命令。这种按真实事故还原的思路，对于做后端开发的人来说，比看十篇原理文章都管用。

从一次 OOM 故障聊起：日志分析里的关键信号

我所在的项目组曾经被一个偶发 OOM 搞得很头疼。每次重启后恢复正常，过两三天又复现。那时我把千鹤酱的开发笔记里关于内存泄漏排查的章节翻出来，对照着用jmap dump 堆快照，再用 MAT 分析可疑的大对象。最后发现是一个静态 Map 在定时任务里不断写入却没有清理逻辑。笔记里提到的那条经验——“凡是看到ConcurrentHashMap的堆占用持续上涨，先去查定时任务里的 put 操作”，几乎原样命中了我们的问题。

这次以后，我在自己维护的JVM 内存泄漏排查文档里也补充了类似的 checklist。千鹤酱的笔记特别强调日志里java.lang.OutOfMemoryError: Java heap space和GC overhead limit exceeded的区别，前者一般是堆本身不够或大对象，后者往往是 GC 效率过低，这种区分能帮新手少走很多弯路。另外，笔记建议生产环境始终开启-XX:+HeapDumpOnOutOfMemoryError，这条我们一直保留在所有服务的启动参数里。

接口性能调优：笔记里的几个高频切入点

千鹤酱的开发笔记在性能优化这块贡献了不少可以直接落地的方案。我把印象最深的几个点整理一下，配合自己后续的实测数据，供大家参考。

• 数据库连接池大小：笔记推荐 HikariCP 的maximumPoolSize不要想当然设成 50、100，而是用公式 connections = ((core_count * 2) + effective_spindle_count) 估算。我们在 8 核、SSD 的机器上按这个公式得出约 20 个连接，实际压测下来 QPS 比之前设置 50 时还高了 12%，因为避免了数据库端的上下文切换。
• Redis 序列化方式：笔记里对比了 JDK 序列化和 Protostuff 的吞吐差距，我们用类似的数据集实测，Protostuff 确实在序列化速度上有近 3 倍优势。但笔记也提到要小心兼容性问题，字段新增时必须注意顺序，这一点在我们一次灰度发布里踩过坑。
• 线程池拒绝策略：笔记用一张表格列出了 AbortPolicy、CallerRunsPolicy、DiscardPolicy 的适用场景。我们原本统一用的 CallerRuns，后来参考了笔记中对线程池配置实战的分析，将核心交易链路改为 AbortPolicy 并配上降级逻辑，切流时出现的雪崩明显减少。

日常开发中容易被忽略的配置细节

除了大故障的排查，千鹤酱的开发笔记里还零散记录了很多小配置的调优经验，这些在最开始往往不太起眼，但累积起来对系统稳定性的影响很大。

Tomcat 最大连接数

笔记建议不要只设maxConnections而忽略acceptCount，当瞬时流量过来时，连接会先堆积在 accept 队列，如果这个值过小就会直接拒绝。我们的 Spring Boot 服务现在统一设置server.tomcat.accept-count=100，比默认的 100 略高，并根据实际情况微调。

Feign 超时熔断

笔记强调要同时配置connectTimeout和readTimeout，并配合 Hystrix 的timeoutInMilliseconds，否则可能出现熔断未生效而调用方一直阻塞的情况。这个配置在我们一个依赖较多的服务里改过之后，接口 RT P99 从 3s 降到了 900ms。

日志级别动态切换

千鹤酱推荐引入 spring-boot-starter-actuator 的 /loggers 端点，线上排查时不用重启就能把指定包的日志调成 DEBUG。我们之前没注意这点，每次改日志级别都要走一遍发布流程，白白浪费不少时间。

笔记里的工具链和排查习惯

千鹤酱的开发笔记并不是只给结论，它把整个排查工具链也串了起来。我在线上故障快速定位的分享里也借鉴了不少思路。笔记里最常用的组合是：top -Hp 找高 CPU 线程 → printf '%x\n' tid 转十六进制 → jstack 查线程状态 → 如果发现大量 BLOCKED，再用 arthas 的 thread -b 找出死锁根源。这套流程在几次突发流量下帮我们快速恢复了服务。

另外，笔记里多次提到“先恢复、再定位”的原则。遇到生产问题不要现场改代码去复现，而是先收集现场快照——jstack、jmap、gc.log 三件套拿齐，然后马上重启或切流止损。这种习惯一旦养成，值班时的心理压力会小很多。我们团队现在每台服务器都挂了一个自研的小脚本，当 CPU 或内存超过阈值时自动执行这些收集动作，很大程度上就是受这份笔记的启发。

千鹤酱的开发笔记里没有那种“一招吃遍天”的夸张说法，它反而反复提醒性能优化要基于压测数据，不要凭直觉动参数。比如之前有人看了线程池优化的章节后，直接把核心线程数调到 200，结果 CPU 上下文切换开销比业务逻辑还大，压测的 QPS 不升反降。后来还是对照笔记里的公式，结合压测记录一步步调回 16 个核心线程、32 个最大线程才稳定下来。这种真实的反面案例也让笔记更有参考价值。如果你手里也有一份类似的踩坑记录，不妨对比着看，或许能发现自己系统中那些一直存在但还没暴露的薄弱点。