线上问题排查：10 大场景 + Arthas / JDK / 日志三件套，从应急止血到根因根治

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

第 1 步：分清是哪类 OOM
   ├── java.lang.OutOfMemoryError: Java heap space          → 堆 OOM
   ├── java.lang.OutOfMemoryError: Metaspace                → 元空间 OOM
   ├── java.lang.OutOfMemoryError: Direct buffer memory     → 直接内存 OOM
   ├── java.lang.StackOverflowError                         → 栈 OOM
   └── java.lang.OutOfMemoryError: GC overhead limit exceeded → GC 效率低
第 2 步：抓 dump
   └── jmap -dump:format=b,file=heap.hprof <pid>
第 3 步：MAT / jhat 分析
   └── Leak Suspects → Dominator Tree → GC Roots

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# CPU
top -c
# 8 核 CPU，平均 75%，不高 → 不是 CPU 问题

# 内存
free -h
# 总 16G，已用 15.2G，剩余 800M → 内存高
jstat -gcutil <pid> 1s 5
# 输出：O 99.8%，E 45%，S0/S1 0%，M 96%
# → 老年代满了，疑似内存泄漏

1
2
3
4
5

# GC 频率
jstat -gc <pid> 1s 5
# FGC 5 秒内 +3 次
# YGC 5 秒内 +50 次
# → GC 已经在"疯狂工作"

1
2
3
4

# 看日志
tail -1000 /var/log/app/app.log | grep -i error
# 找到 OutOfMemoryError: Java heap space
# + 大量 java.lang.RuntimeException: No space available

1
2
3
4

# 抓 heap
jmap -dump:format=b,file=/tmp/heap.hprof <pid>
# 用 MAT 分析 Leak Suspects
# 发现：com.example.PayService 持有 ConcurrentHashMap，3 亿 entries

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// 错代码
private Map<Long, PayRecord> recordCache = new ConcurrentHashMap<>();

public PayRecord getRecord(Long id) {
    PayRecord r = recordCache.get(id);
    if (r == null) {
        r = payRepository.findById(id);
        recordCache.put(id, r);  // 永久缓存，不限大小
    }
    return r;
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// 改用 Caffeine
private Cache<Long, PayRecord> recordCache = Caffeine.newBuilder()
    .maximumSize(100_000)         // 最多 10 万
    .expireAfterWrite(Duration.ofMinutes(10))
    .recordStats()
    .build();

public PayRecord getRecord(Long id) {
    return recordCache.get(id, payRepository::findById);
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 下载
curl -O https://arthas.aliyun.com/arthas-boot.jar

# 启动（自动检测运行中的 Java 进程）
java -jar arthas-boot.jar

# 选择进程（输入编号）
[INFO] Found existing java process, please choose one and hit RETURN.
* [1]: 12345 /usr/local/app.jar
  [2]: 23456 /usr/local/other.jar
1

# 进入交互式命令行
[arthas@12345]$ 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# 1. 看整体
dashboard -n 5

# 2. 找最忙的 CPU 线程
thread -n 3

# 3. 死锁检测
thread -b

# 4. 监控某个方法
watch com.example.OrderService create '{params, returnObj, throwExp}' -x 2

# 5. 跟踪调用链
trace com.example.OrderService create '#cost > 100' -n 5

# 6. 反编译
jad com.example.OrderService

# 7. 动态改日志级别
ognl '@com.example.LogConfig@setLevel("DEBUG")'

1
2
3
4
5
6
7
8

jps 找进程
jstack 看线程
jmap 抓堆
jstat 看 GC
jcmd 万能（替代 jstack/jmap/jstat）
jinfo 看参数
jhat 浏览器看堆
jfr 性能录制

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

// 1. 过滤器：自动注入 TraceId
@Component
public class TraceIdFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest req, 
                                    HttpServletResponse resp,
                                    FilterChain chain) {
        String traceId = req.getHeader("X-Trace-Id");
        if (traceId == null) {
            traceId = TraceContext.traceId();  // SkyWalking
        }
        MDC.put("traceId", traceId);
        MDC.put("userId", getUserId(req));
        MDC.put("uri", req.getRequestURI());
        try {
            chain.doFilter(req, resp);
        } finally {
            MDC.clear();
        }
    }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

<configuration>
    <!-- 控制台 + JSON 文件 -->
    <appender name="JSON" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>/var/log/app/app.json</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <fileNamePattern>/var/log/app/app.%d{yyyy-MM-dd}.%i.json.gz</fileNamePattern>
            <maxFileSize>500MB</maxFileSize>
            <maxHistory>30</maxHistory>
            <totalSizeCap>50GB</totalSizeCap>
        </rollingPolicy>
        <encoder class="net.logstash.logback.encoder.LogstashEncoder">
            <includeMdcKeyName>traceId</includeMdcKeyName>
            <includeMdcKeyName>userId</includeMdcKeyName>
            <customFields>{"app":"order-service","env":"prod"}</customFields>
        </encoder>
    </appender>
</configuration>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

{
  "@timestamp": "2026-06-09T03:47:23.456+08:00",
  "level": "ERROR",
  "logger": "com.example.OrderService",
  "thread": "http-nio-8080-exec-25",
  "message": "create order failed",
  "traceId": "7a3f.1234567890.01",
  "userId": "u-10086",
  "uri": "/api/order/create",
  "app": "order-service",
  "env": "prod",
  "stack_trace": "java.lang.RuntimeException: ..."
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# 1. 看进程 CPU 占用
top -c

# 2. 看哪个线程占 CPU（关键步骤）
top -Hp <pid>

# 输出示例：
#   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM     TIME+ COMMAND
#  5678 app       20   0  12g   8g  100m R 98.5  6.2  47:23.45 java
#  5679 app       20   0  12g   8g  100m R 95.2  6.2  45:18.32 java
#  5680 app       20   0  12g   8g  100m R 92.1  6.2  44:55.12 java
#  ...

# 3. 记录线程 ID（5678 → 0x162E）
printf '%x\n' 5678
# 输出：162e

1
2
3
4
5
6
7

# 抓取 3 次（间隔 5 秒），看"持续忙"的线程
for i in 1 2 3; do
  jstack <pid> > thread_$i.txt
  sleep 5
done

# 对比 3 个文件，**反复出现的线程** = 真凶

1
2
3
4
5
6

# 转 16 进制
printf '%x\n' 5678
# 162e

# 在 thread_1.txt 中搜
grep -A 30 'nid=0x162e' thread_1.txt

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

"http-nio-8080-exec-125" #125 daemon prio=5 os_prio=0 tid=0x00007f4a940a8800 
   nid=0x162e runnable [0x00007f4a8c4f0000]
   java.lang.Thread.State: RUNNABLE
        at java.util.regex.Pattern$GroupHead.match(Pattern.java:4658)
        at java.util.regex.Pattern$Loop.match(Pattern.java:4801)
        at java.util.regex.Pattern$Loop.match(Pattern.java:4798)
        at java.util.regex.Pattern$Loop.match(Pattern.java:4798)
        at java.util.regex.Pattern$Loop.match(Pattern.java:4798)
        at java.util.regex.Pattern$Loop.match(Pattern.java:4798)
        at java.util.regex.Pattern$GroupHead.match(Pattern.java:4658)
        ...
        at com.example.UserService.validateUsername(UserService.java:42)
        at com.example.OrderController.create(OrderController.java:28)
        ...

1
2

# 用 jad 看线上真实代码
arthas> jad com.example.UserService validateUsername

1
2
3
4

public boolean validateUsername(String username) {
    // 灾难代码
    return username.matches("^[a-zA-Z]+([._-]?[a-zA-Z0-9]+)*$");
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

a+([._-]?[a-zA-Z0-9]+)*$

输入：aaa!

1. 贪婪匹配 aaa
2. ([._-]?[a-zA-Z0-9]+)* 尝试匹配
3. ! 不在 [._-] 集合
4. 回溯：a+ 让出 1 个
5. 再次尝试 ([._-]?[a-zA-Z0-9]+)*
6. ... 指数级爆炸

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

// 改用 Apache Commons Lang 的字符判断
public boolean validateUsername(String username) {
    if (username == null || username.length() > 50 || username.isEmpty()) {
        return false;
    }
    // 简单字符判断，无正则
    for (int i = 0; i < username.length(); i++) {
        char c = username.charAt(i);
        if (!Character.isLetterOrDigit(c) && c != '_' && c != '-' && c != '.') {
            return false;
        }
    }
    return true;
}

1
2
3
4

# 启动 CPU 火焰图
profiler start -d 30
profiler stop --format html -o /tmp/flame.html
# 下载到本地，用浏览器看

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# 步骤 1：抓 CPU 占用线程（30 秒）
top -Hp <pid>
# 记录占用最高的 3 个线程 ID（如 5678、5679、5680）

# 步骤 2：转 16 进制 + jstack 抓栈（1 分钟）
for tid in 5678 5679 5680; do
    hex=$(printf '%x' $tid)
    jstack <pid> | grep -A 30 "nid=0x$hex"
done > cpu_hotspot.txt

# 步骤 3：定位方法（1 分钟）
# 看栈里反复出现的方法名（如 Regex.match → 死循环正则）

# 步骤 4：临时止血（5 分钟）
# 选项 A：摘流量（如果 K8s）
kubectl scale deployment order-service --replicas=0
# 选项 B：Nginx 切流量
# 选项 C：Sentinel 限流

# 步骤 5：修复 + 验证（30 分钟）
# - 修复代码（紧急 hotfix）
# - 压测验证
# - 灰度上线

1
2
3
4
5
6
7
8
9

# 1. 抓 dump（OOM 前最后一次机会）
jmap -dump:format=b,file=/tmp/heap.hprof <pid>

# 2. 紧急重启（保留 1 个旧实例，先启动新的）
# K8s: kubectl delete pod <pod-name>
# Docker: docker restart <container>

# 3. 临时调大堆（如果机器内存够）
java -Xmx8g -Xms8g -jar app.jar

1
2

# 看日志最后几行的异常类型
tail -1000 /var/log/app/app.log | grep -A 5 "OutOfMemoryError"

1
2
3
4
5
6
7
8

# 抓 dump
jmap -dump:format=b,file=/tmp/heap.hprof <pid>
# 文件可能很大（堆 8G → 8G 文件），**用 scp / oss 传到本地**

# 用 MAT（Eclipse Memory Analyzer）打开
# - Leak Suspects Report（自动）
# - Dominator Tree（手动）
# - Top Consumers

1
2
3
4
5

5,234,567 instances of "java.util.HashMap$Node"
  retained: 4,287,654,321 bytes
  ├── HashMap: cacheData  (in com.example.CacheService)
  │   └── ConcurrentHashMap: userCache  (size: 12,345,678)
  │       └── 原因：缓存没有过期时间，无限增长

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

// 灾难代码
@Component
public class CacheService {
    private final Map<Long, User> userCache = new ConcurrentHashMap<>();
    
    public User getUser(Long userId) {
        User user = userCache.get(userId);
        if (user == null) {
            user = userRepository.findById(userId);
            userCache.put(userId, user);  // 永久缓存
        }
        return user;
    }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// 改用 Caffeine（带过期 + 最大容量）
@Component
public class CacheService {
    private final Cache<Long, User> userCache = Caffeine.newBuilder()
        .maximumSize(100_000)        // 最多 10 万
        .expireAfterWrite(Duration.ofMinutes(10))  // 10 分钟过期
        .recordStats()               // 开启统计
        .build();
    
    public User getUser(Long userId) {
        return userCache.get(userId, userRepository::findById);
    }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

// 错
private static final ThreadLocal<User> currentUser = new ThreadLocal<>();

// 对
private static final ThreadLocal<User> currentUser = new ThreadLocal<>();

public void doBusiness() {
    try {
        currentUser.set(loadUser());
        // ... 业务逻辑
    } finally {
        currentUser.remove();  // 必须 remove
    }
}

1
2
3
4
5
6

# Prometheus + Grafana 监控
- name: jvm_memory_used_bytes
  alert: > 80% for 5m

- name: jvm_gc_pause_seconds
  alert: > 1s for 3m

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

# 步骤 1：分清 OOM 类型（30 秒）
tail -1000 /var/log/app/app.log | grep -A 5 "OutOfMemoryError"
# 看错误类型：Java heap / Metaspace / Direct buffer / GC overhead

# 步骤 2：抓 heap dump（重要！重启会丢现场）
jmap -dump:format=b,file=/tmp/heap.hprof <pid>
# 文件可能很大（8GB 堆 → 8GB 文件），用 scp/oss 传回本地

# 步骤 3：紧急止血（5 分钟）
# 选项 A：临时调大堆
kubectl set env deployment/order-service JAVA_OPTS="-Xmx8g -Xms8g"
# 选项 B：重启 Pod
kubectl delete pod <pod-name>
# 选项 C：摘流量
kubectl scale deployment order-service --replicas=0

# 步骤 4：MAT 分析（30 分钟）
# - Leak Suspects Report
# - Dominator Tree
# - Top Consumers

# 步骤 5：修复 + 复盘（1-3 天）
# - 修代码（加缓存上限 / ThreadLocal.remove）
# - 加监控（Old Gen 使用率告警）
# - 写 Runbook

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# 1. 看线程状态统计
arthas> thread
# 输出：
#   Threads Total: 1425
#   RUNNABLE: 8
#   BLOCKED: 1320     ← 关键指标
#   WAITING: 87
#   TIMED_WAITING: 10

# 2. 紧急摘流量
# K8s: kubectl scale deployment order-service --replicas=0
# 或 Nacos/Sentinel 切流

1
2

# jstack 自动检测死锁
jstack <pid> | grep -A 20 "Found one Java-level deadlock"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

Found one Java-level deadlock
=============================
"Thread-1":
  waiting to lock Monitor 0x00007f4a8c4a3e58 (Object@0x00000006c1a3b290, a java.lang.Object),
  which is held by "Thread-2"
"Thread-2":
  waiting to lock Monitor 0x00007f4a8c4a3e78 (Object@0x00000006c1a3b2a0, a java.lang.Object),
  which is held by "Thread-1"

  Java stack information for the threads listed above:
  ===================================================
"Thread-1":
    at com.example.AccountService.transfer(AccountService.java:35)
    - waiting to lock <0x00000006c1a3b290> (a java.lang.Object)
    - locked <0x00000006c1a3b2a0> (a java.lang.Object)
"Thread-2":
    at com.example.AccountService.transfer(AccountService.java:35)
    - waiting to lock <0x00000006c1a3b2a0> (a java.lang.Object)
    - locked <0x00000006c1a3b290> (a java.lang.Object)

1
2
3
4
5
6

# 找 BLOCKED 状态的线程
arthas> thread -b
# 自动检测 + 打印所有 BLOCKED 线程的栈

# 找最忙的 5 个线程
arthas> thread -n 5

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// 死锁代码（经典账户转账死锁）
public void transfer(Account from, Account to, BigDecimal amount) {
    synchronized (from) {           // 先锁 from
        synchronized (to) {         // 再锁 to
            from.debit(amount);
            to.credit(amount);
        }
    }
}

// Thread-1: transfer(A, B, 100)
// Thread-2: transfer(B, A, 200)
// 互相等待 → 死锁

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

// 修复 1：按顺序加锁
public void transfer(Account from, Account to, BigDecimal amount) {
    // 排序：ID 小的先锁
    Account first = from.getId() < to.getId() ? from : to;
    Account second = from.getId() < to.getId() ? to : from;
    synchronized (first) {
        synchronized (second) {
            from.debit(amount);
            to.credit(amount);
        }
    }
}

// 修复 2：使用 ReentrantLock.tryLock
private final ReentrantLock lockA = new ReentrantLock();
private final ReentrantLock lockB = new ReentrantLock();

public void transfer(Account from, Account to, BigDecimal amount) {
    boolean gotA = false, gotB = false;
    try {
        gotA = lockA.tryLock(100, TimeUnit.MILLISECONDS);
        if (!gotA) return;
        gotB = lockB.tryLock(100, TimeUnit.MILLISECONDS);
        if (!gotB) return;
        from.debit(amount);
        to.credit(amount);
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    } finally {
        if (gotB) lockB.unlock();
        if (gotA) lockA.unlock();
    }
}

// 修复 3：使用 Java 19+ StructuredTaskScope（虚拟线程）
// 或 Reactive 风格：避免锁

1
2
3
4
5
6

# 看线程池状态
arthas> thread | grep BLOCKED | wc -l
# 1320

# 看是不是某个线程池打满
jstack <pid> | grep -B 2 "at java.util.concurrent.ThreadPoolExecutor"

1
2
3
4
5
6
7

// 修复：给线程池加监控 + 拒绝策略
ThreadPoolExecutor executor = new ThreadPoolExecutor(
    20, 100, 60, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(1000),
    new ThreadPoolExecutor.CallerRunsPolicy()  // 关键：让调用者执行
);
executor.submit(() -> doWork());

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# 步骤 1：jstack 看死锁（30 秒）
jstack <pid> | grep -A 30 "Found one Java-level deadlock"
# 如果有输出 → 死锁，步骤 2
# 如果没有 → BLOCKED 太多，步骤 3

# 步骤 2：找死锁的代码
# 看 jstack 输出的 waiting to lock
# 找两个互相等待的锁
jstack <pid> | grep -B 1 -A 10 "waiting to lock" | head -50

# 步骤 3：Arthas 看阻塞链
arthas> thread -b
# 输出所有 BLOCKED 线程的栈

# 步骤 4：找最忙的线程
arthas> thread -n 3
# 看 nio-8080-exec 线程在等什么

# 步骤 5：紧急止血
# 选项 A：摘流量
kubectl scale deployment order-service --replicas=0
# 选项 B：重启（清线程池）
kubectl delete pod <pod-name>
# 选项 C：加机器（如果线程池打满）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 1. 强制 FullGC 一次（有时候会缓解）
jcmd <pid> GC.run

# 2. 紧急重启 + 切走流量
kubectl delete pod <pod-name>

# 3. 临时调大堆
java -Xmx16g -Xms16g -XX:+UseG1GC -jar app.jar

# 4. 切到老年代回收更激进的 GC（ZGC）
java -XX:+UseZGC -jar app.jar  # JDK 17+

1
2

# 每秒打印一次，连续看 10 秒
jstat -gcutil <pid> 1s 10

1
2
3
4

  S0     S1     E      O      M     CCS    YGC  YGCT  FGC  FGCT   GCT
  0.00  12.50  45.20  98.40  96.10  92.30   142  28.4  47  142.5  170.9
  0.00   0.00  18.40  99.20  96.10  92.30   143  28.7  48  145.8  174.5
  0.00   8.20  12.40  99.80  96.10  92.30   144  29.0  49  149.2  178.2

1
2
3
4
5

# 启用 GC 日志
-XX:+PrintGCDetails \
-XX:+PrintGCDateStamps \
-XX:+PrintTenuringDistribution \
-Xloggc:/var/log/app/gc.log

1
2
3
4
5
6
7

2026-06-09T03:47:23.456+0800: 142.456: [Full GC (Ergonomics) 
  PSYoungGen: 1024K->0K(1835008K)]
  ParOldGen: 8388608K->8388200K(8388608K)  ← 老年代没回收多少
  8389632K->8388200K(10223616K)
  [PSPermGen: 24573K->24573K(65536K)]
  [Times: user=2.45 sys=0.02 real=2.43 secs]  ← STW 2.43s
]

1
2

# 看每秒分配速率
jstat -gc <pid> 1s 5

1
2

jmap -dump:format=b,file=/tmp/heap.hprof <pid>
# 用 MAT 分析：Leak Suspects → 看哪个对象在增长

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// 错：循环内字符串拼接（产生大量临时对象）
for (Item item : items) {
    result += item.toString() + ",";  // 每次循环产生新 String
}

// 对：StringBuilder
StringBuilder sb = new StringBuilder();
for (Item item : items) {
    sb.append(item.toString()).append(",");
}
String result = sb.toString();

1
2
3
4
5
6
7
8
9

// 错：直接返回大 List
public List<Order> getOrders() {
    return orderRepository.findAll();  // 100 万行
}

// 对：分页
public Page<Order> getOrders(int page, int size) {
    return orderRepository.findAll(PageRequest.of(page, size));
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# G1 GC 调优（推荐，JDK 9+ 默认）
java -Xms8g -Xmx8g \
     -XX:+UseG1GC \
     -XX:MaxGCPauseMillis=200 \
     -XX:G1HeapRegionSize=16m \
     -XX:InitiatingHeapOccupancyPercent=45 \
     -jar app.jar

# ZGC（推荐，JDK 17+）
java -Xms16g -Xmx16g \
     -XX:+UseZGC \
     -XX:+ZGenerational \
     -jar app.jar

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 必加的 5 个 GC 指标
- name: jvm_gc_pause_seconds
  alert: P99 > 0.5s
- name: jvm_gc_collection_seconds_sum (Full GC)
  alert: rate > 0.1 /s
- name: jvm_memory_old_gen_used_bytes
  alert: > 80%
- name: jvm_memory_old_gen_max_bytes
  # 配合上面算使用率
- name: jvm_threads_states_threads (BLOCKED)
  alert: > 100

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# 步骤 1：抓 GC 日志（30 秒）
# 启用 GC 日志（需重启，加参数）
# 或者从 logback 实时看
tail -f /var/log/app/gc.log

# 步骤 2：jstat 看频率（1 分钟）
jstat -gcutil <pid> 1s 10
# 重点看 O（Old Gen）、FGC（FullGC 次数）、FGCT（FullGC 总耗时）

# 步骤 3：分清是泄漏还是分配过快（5 分钟）
jstat -gc <pid> 1s 5
# 看每秒 Old Gen 增长速率
# > 1GB/s → 分配过快
# 增长后不下降 → 内存泄漏

# 步骤 4：dump + MAT 分析（30 分钟）
jmap -dump:format=b,file=/tmp/heap.hprof <pid>

# 步骤 5：紧急止血
# 选项 A：临时调大堆（如果机器内存够）
kubectl set env deployment/order-service JAVA_OPTS="-Xmx16g -Xms16g"
# 选项 B：切到 ZGC（如果 JDK 17+）
# 选项 C：重启 Pod
# 选项 D：切流量到其他实例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# 1. 看连接池状态
curl -s http://<pod-ip>:8080/actuator/metrics/hikaricp.connections.active | jq

# 2. 看慢 SQL
# MySQL: SHOW PROCESSLIST;
mysql -u root -p -e "SHOW FULL PROCESSLIST;" | head -20

# 3. 紧急杀掉长事务
mysql -e "KILL <thread_id>;"

# 4. 切流量
# 限流 + 切走

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# application.yml
spring:
  datasource:
    hikari:
      maximum-pool-size: 20
      minimum-idle: 5
      connection-timeout: 30000
      idle-timeout: 600000
      max-lifetime: 1800000
      pool-name: OrderHikariCP
      register-mbeans: true

1
2

# 看是哪个 DAO 方法慢
arthas> trace com.example.OrderRepository findByUserId '#cost > 500' -n 5

1
2
3
4
5

`---[83.452ms] com.example.OrderRepository$$EnhancerBySpringCGLIB$$findByUserId()
    `---[83.380ms] org.apache.ibatis.binding.MapperMethod$$execute()
        `---[83.150ms] org.apache.ibatis.executor.statement.PreparedStatementHandler$$query()
            `---[82.890ms] com.mysql.cj.jdbc.ClientPreparedStatement$$execute()
                `---[82.450ms] SELECT * FROM orders WHERE user_id = ? AND status = 'PAID'

1
2
3
4
5
6
7
8
9

-- 开启慢查询日志
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;  -- 1 秒以上算慢
SET GLOBAL log_output = 'TABLE';  -- 写入 mysql.slow_log

-- 看最近的慢查询
SELECT * FROM mysql.slow_log 
ORDER BY start_time DESC 
LIMIT 10;

1

EXPLAIN SELECT * FROM orders WHERE user_id = 12345 AND status = 'PAID';

1
2
3
4

id  select_type  table  type  possible_keys  key     key_len  rows    Extra
1   SIMPLE       orders ALL   NULL           NULL    NULL     4500000 Using where
                                    ^^^^^
                                    全表扫！450 万行

1
2
3
4
5

-- 单字段索引
CREATE INDEX idx_user_status ON orders(user_id, status);

-- 覆盖索引（包含查询字段，避免回表）
CREATE INDEX idx_user_status_pay ON orders(user_id, status, pay_time, amount);

1
2
3
4
5
6
7
8
9

// 错：limit 1000000, 20 → 扫 100 万行
public List<Order> getOrders(int page) {
    return orderRepository.findAll(PageRequest.of(page, 20));
}

// 对：游标分页
public List<Order> getOrdersAfter(Long lastId, int size) {
    return orderRepository.findByIdGreaterThanOrderById(lastId(lastId, size);
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 大小经验值
maximum-pool-size: 20-50  # 不要过大！
# 公式：连接数 = ((核心数 * 2) + 有效磁盘数)
# 4 核 SSD → 10-12 个连接足够

# 关键参数
connection-timeout: 30000   # 获取连接超时
idle-timeout: 600000        # 空闲连接超时
max-lifetime: 1800000       # 连接最大生命周期
validation-timeout: 5000    # 验证超时
leak-detection-threshold: 60000  # 60 秒未关闭 = 泄漏

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# 步骤 1：看连接池状态（30 秒）
curl -s http://<pod-ip>:8080/actuator/metrics/hikaricp.connections.active | jq
curl -s http://<pod-ip>:8080/actuator/metrics/hikaricp.connections.pending | jq
# pending > 0 说明有请求在等连接

# 步骤 2：看 MySQL 慢查询（1 分钟）
mysql -u root -p -e "SHOW FULL PROCESSLIST;" | head -20
# 找 State 列是 "Sending data" / "Sorting result" / "Waiting for table lock"

# 步骤 3：紧急杀掉长事务
mysql -e "KILL <thread_id>;"

# 步骤 4：Arthas trace 慢 DAO（5 分钟）
arthas> trace com.example.OrderRepository findByUserId '#cost > 500' -n 5

# 步骤 5：临时方案（10 分钟）
# 选项 A：调大连接池（但要配合 DB 端）
kubectl set env deployment/order-service SPRING_DATASOURCE_HIKARI_MAX_POOL_SIZE=50
# 选项 B：限流
# 选项 C：切流量

1
2
3
4
5
6
7
8

# 1. 关闭 Sentinel 限流（紧急）
# 控制台 → 规则管理 → 临时关闭

# 2. 或调大阈值
# FlowRule: count 100 → 1000
# DegradeRule: rt 500 → 5000

# 3. 重启服务（让规则从 Nacos 重新加载）

1
2
3
4
5
6
7
8

# 看实时监控
http://sentinel-dashboard:8080

# 关键信息：
# - 资源名（API 路径）
# - 通过 QPS / 拒绝 QPS
# - 平均 RT
# - 异常比例

1
2

# 看被熔断的 API 实际耗时
arthas> trace com.example.api.OrderApi create '#cost > 1000'

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

// 服务级别（粗粒度）
@PostConstruct
public void initFlowRules() {
    FlowRule rule = new FlowRule("order-service");
    rule.setGrade(RuleConstant.FLOW_GRADE_QPS);
    rule.setCount(1000);  // 1000 QPS
    rule.setControlBehavior(RuleConstant.CONTROL_BEHAVIOR_WARM_UP);
    rule.setWarmUpPeriodSec(10);
    FlowRuleManager.loadRules(Collections.singletonList(rule));
}

// API 级别（细粒度）
@PostConstruct
public void initDegradeRules() {
    DegradeRule rule = new DegradeRule("order-create")
        .setGrade(RuleConstant.DEGRADE_GRADE_RT)  // 慢调用
        .setCount(500)        // RT 阈值 500ms
        .setTimeWindow(10)    // 熔断 10 秒
        .setMinRequestAmount(20)  // 最小请求数 20
        .setSlowRatioThreshold(0.5);  // 50% 慢才熔断
    DegradeRuleManager.loadRules(Collections.singletonList(rule));
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// 关键业务用专用线程池，与其他业务隔离
@Bean("orderExecutor")
public Executor orderExecutor() {
    ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
    executor.setCorePoolSize(20);
    executor.setMaxPoolSize(50);
    executor.setQueueCapacity(200);
    executor.setThreadNamePrefix("order-");
    executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
    executor.initialize();
    return executor;
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

// Resilience4j 超时（推荐）
TimeLimiterConfig timeLimiterConfig = TimeLimiterConfig.custom()
    .timeoutDuration(Duration.ofMillis(500))  // 500ms 超时
    .build();

// Feign 客户端
@FeignClient(name = "pay-service")
public interface PayClient {
    @RequestMapping(method = RequestMethod.POST, value = "/pay")
    String pay(@RequestBody PayRequest request);
}
// application.yml
feign:
  client:
    config:
      default:
        connectTimeout: 500
        readTimeout: 1500

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

@SentinelResource(value = "order-create", 
                  fallback = "createFallback",
                  blockHandler = "createBlockHandler")
public Order create(OrderRequest request) {
    // 正常业务
    return orderRepository.save(build(request));
}

// 降级逻辑
public Order createFallback(OrderRequest request, Throwable e) {
    // 1. 写本地缓存（异步补偿）
    pendingOrderCache.put(request.getOrderId(), request);
    // 2. 返回兜底
    return Order.deferred(request);
}

public Order createBlockHandler(OrderRequest request, BlockException e) {
    // 限流处理
    metrics.recordBlock("order-create");
    throw new BizException("系统繁忙，请稍后重试");
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# 步骤 1：判断雪崩源头（30 秒）
# 看监控：哪个依赖 RT 飙了？
# 看链路：SkyWalking 找根因服务

# 步骤 2：紧急熔断（1 分钟）
# Sentinel 控制台 → 资源 → 手动熔断
# 或 Nacos 推送降级配置

# 步骤 3：摘非核心流量
# 关闭推荐、广告、营销、监控上报等
# 保留：登录、下单、支付

# 步骤 4：扩容（5 分钟）
kubectl scale deployment order-service --replicas=20
# 或扩容依赖服务

# 步骤 5：恢复
# 等下游恢复后逐步放开熔断

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 1. 找出大 key
redis-cli --bigkeys

# 2. 紧急删除大 key
redis-cli DEL "big_key"

# 3. 临时清理过期
redis-cli --scan --pattern "*" | head -1000 | xargs redis-cli DEL

# 4. 切流量（如果是大 key 业务）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 找大 key
redis-cli --bigkeys

# 输出：
# -------- summary -------
# Biggest string found '"product:detail:10086"' has 12345678 bytes
# Biggest list found '"user:cart:10086"' has 89012 items

# 找占用内存最多的 key（按内存）
redis-cli --memkeys

# 看 key 内存详情
redis-cli MEMORY USAGE "product:detail:10086"
# 输出：12345678

1
2
3
4
5
6

# 监控：key 命中率
redis-cli INFO stats | grep keyspace_hits

# 监控：被淘汰 key
redis-cli INFO stats | grep evicted_keys
# evicted_keys > 0 → 内存不够

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

// 错：单 key 存整个商品详情
@Service
public class ProductService {
    public void saveDetail(Long productId, ProductDetail detail) {
        String json = objectMapper.writeValueAsString(detail);
        redisTemplate.opsForValue().set(
            "product:detail:" + productId, json, 24, TimeUnit.HOURS
        );
        // 1 个商品详情 10MB，1000 个商品 = 10GB
    }
}

// 对：按字段分 key
@Service
public class ProductService {
    public void saveDetail(Long productId, ProductDetail detail) {
        redisTemplate.opsForHash().putAll(
            "product:detail:" + productId, 
            Map.of("name", detail.getName(),
                   "price", detail.getPrice().toString(),
                   "desc", detail.getDesc())
        );
        // 单个 key 最大 100KB
    }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27