一个慢接口引发的雪崩：Dubbo 超时 + 默认重试，把流量放大了 3 倍
下游一个慢接口，叠加 Dubbo 超时与默认 retries=2（最多调 3 次），流量被放大、provider 200 线程被占满并报 Thread pool is EXHAUSTED，故障从一个服务扩散到整条链路。附排查命令、超时分层、集群容错与限流降级的修法。
THOUGHTS, NOTES & PRACTICE
全部文章 最近在写.
XXL-JOB 的三种“灵异现象”：重复执行、莫名不触发、执行器离线——一次讲透调度链路
同一个定时任务有时跑两遍、有时一遍都没跑、有时执行器在后台显示离线。沿着调度中心到执行器的链路，查注册地址、accessToken、路由与阻塞策略、misfire、执行超时，最后用幂等设计兜底。
ES 写入全线 403：磁盘刚到 95%，整个集群就“只读”了——水位线三兄弟与 read_only_allow_delete
日志写入突然全部失败，报 index read-only / allow delete (api)，集群还变了 yellow。顺着 _cluster/health、_cat/allocation、allocation/explain 一路查到磁盘水位线，讲清 85/90/95 三道线、解除只读的正确姿势，以及分片过多这个隐形推手。
下游慢 2 秒，上游全挂：一次线程池被打满的连环追尾
积分服务变慢，订单服务接口全部超时，CPU 却只有 5%。jstack 看到 200 个 Tomcat 线程都阻塞在 socket read 与连接池里，根因是没设超时、队列无界、没有隔离。附拒绝策略与超时、舱壁隔离的落地写法。
接口“偶发”卡 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，三步定位到一条正则的灾难性回溯。附完整命令、根因分析和三种修法。
FROM IDEAS TO REALITY
了解全部服务