下游慢 2 秒，上游全挂：一次线程池被打满的连环追尾
积分服务变慢，订单服务接口全部超时，CPU 却只有 5%。jstack 看到 200 个 Tomcat 线程都阻塞在 socket read 与连接池里，根因是没设超时、队列无界、没有隔离。附拒绝策略与超时、舱壁隔离的落地写法。
Java / JVM 排查
CPU 飙高、OOM、Full GC、线程池打满、死锁——线上 Java 进程的疑难杂症。
接口“偶发”卡 3 秒？它其实很准时：一次 Full GC 频繁的追凶记
接口 P99 隔几分钟就冲到 3 秒，机器 CPU 却不高。开 GC 日志、jstat 看趋势，发现老年代被一个无界的静态 Map 缓存慢慢撑满，Full GC 越来越频繁。附 JDK8 与 JDK11+ 日志参数、G1 与 CMS 取舍。
导出 50 万行报表，堆直接原地去世：一次 OOM 的 dump 分析与流式改造
运营点了一下“导出全部订单”，服务就抛出 Java heap space 并重启。靠 HeapDumpOnOutOfMemoryError 留住现场，用 MAT 的 Dominator Tree 揪出一个 List，最后改成分页 + EasyExcel 流式写出。
堆明明没满，容器却被 OOMKilled：一个 ByteBuf 忘了 release 的堆外内存漏洞
消息推送网关的堆使用率一直只有 40%，容器 RSS 却每天涨一截，最后被 OOMKilled，日志里还偶发 Direct buffer memory。用 NMT、Netty 泄漏检测 PARANOID 找到忘记 release 的 ByteBuf，并给堆外内存加上限。
不重启、不改代码：用 Arthas 现场揪出“偶发 3 秒”的那一次调用
商品详情接口每隔几十次就慢 3 秒，日志里什么都没有。用 Arthas 的 dashboard、thread、trace、watch、stack 逐层下钻到一个连不上的备用节点，再用 jad、redefine 临时止血，最后用 profiler 火焰图复核。
应用“假死”：CPU 2%，请求全挂，jstack 一眼看出两个线程在互相“谦让”
服务进程在、端口通、健康检查也过，但所有业务请求都卡住，CPU 只有 2%。jstack 直接报出 Found one Java-level deadlock。本文含最小可复现代码、输出逐行解读，以及锁顺序统一、tryLock 超时、缩小锁粒度三种修法。
CPU 飙到 800%：一条“无辜”的正则，把 8 核机器吃得只剩渣
告警说 Java 进程 CPU 800%，接口全部超时。top -Hp → printf 转十六进制 → jstack，三步定位到一条正则的灾难性回溯。附完整命令、根因分析和三种修法。