CPU 飙高是线上最常见的问题之一，也是面试中最爱考的排查题。好消息是，和内存问题相比，CPU 问题的排查路径相对标准化——top 找进程、top -Hp 找线程、jstack 看堆栈。但真正的功力体现在：拿到堆栈之后，你能不能快速定位到根因？
这篇文章记录了几个真实的 CPU 飙高案例，涵盖了压测中发现的代码问题、发布后的 JIT 预热问题、数据库锁竞争导致的 CPU 打满，以及日志打印引发的性能瓶颈。每个案例都完整还原了排查过程。
线上接口的 RT（Response Time）突然飙高，监控大盘一片红。打开链路追踪一看，几十个 span，每个都在几十毫秒，到底是哪一层出了问题？
数据库慢查询、网络超时、连接池耗尽 -- 这三个是接口变慢最常见的三大元凶。这篇文章用真实的排查案例，走一遍从发现问题到定位根因再到修复验证的完整过程。每个案例都带实际的命令、SQL、监控截图描述，拿去就能用。
问题发现
我们在做一次风控定价策略的数据回流 -- 把风险测算出的价格通过数据同步回流到定价配置表中。回流前表中不到 2 万条数据，本次要回流 16 万条。
内存问题是 Java 线上排查中最让人头疼的一类——它不像 CPU 飙高那样能快速用 top + jstack 定位，也不像接口超时那样能通过链路追踪找到瓶颈。内存问题往往是缓慢积累、突然爆发，等你收到告警的时候，进程可能已经在 OOM 的边缘疯狂 FullGC 了。
这篇文章记录了几个真实的内存问题排查案例，从发现到定位到解决，完整还原排查过程。每个案例的排查思路都是可以复用的。
线上出了问题，第一反应是看日志。日志能解决大部分问题，但总有些时候日志不够用——没打日志的地方出了 bug、性能瓶颈藏在某个不起眼的方法里、第三方库的行为不符合预期。这时候你需要更强大的武器。
这篇文章从 Arthas 的核心用法讲起，深入到字节码增强的原理，再到排查方法论的完整思维框架。不追求面面俱到，但力求每个知识点都能在真实的线上排查中派上用场。
Arthas 在统计方法耗时时用的是字节码插桩技术——在需要监控的方法中插入代码，方法执行前记录开始时间，执行完记录结束时间，算差值就是执行时长。
