220｜接口 RT 突增排查：依赖、慢 SQL、GC、线程池、网络与流量变化

客户端 → [DNS] → [负载均衡] → [应用服务器] → [依赖服务/数据库/缓存]
         |←──────────────── RT（端到端）─────────────────→|

第一步：确认范围（单机/集群？单接口/全站？）
第二步：检查流量变化（QPS、并发数、请求体大小）
第三步：检查依赖调用（下游 RT、超时、熔断状态）
第四步：检查数据库（慢 SQL、锁等待、连接池）
第五步：检查 JVM（GC、线程池、堆内存）
第六步：检查网络（跨机房延迟、丢包、带宽）

traceId: xxxxx
├── /api/order/create [8000ms] ← 你的接口
│   ├── userService.getUserInfo [50ms]   ← 正常
│   ├── inventoryService.checkStock [5000ms] ← 异常！通常 20ms
│   ├── couponService.queryCoupon [2000ms] ← 异常！通常 30ms
│   └── paymentService.createPayment [500ms] ← 正常

# 查看下游服务的 RT 监控
# 关注：是否全集群变慢？还是个别实例慢？
# 个别实例慢 → 可能是宿主机问题、实例 Full GC、网络抖动
# 全集群慢 → 可能是数据库慢、上游流量冲击、配置变更

// Sentinel Dashboard 或 Hystrix Dashboard 查看
// 关键指标：
// - circuitBreakerOpen：熔断器是否打开
// - flowControlRejected：是否被限流
// - threadPoolRejected：线程池是否拒绝

// 不好的做法：无限等待
RestTemplate restTemplate = new RestTemplate();
String result = restTemplate.getForObject(url, String.class); // 无超时

// 推荐做法：设置合理的超时和重试
@Bean
public RestTemplate restTemplate() {
    HttpComponentsClientHttpRequestFactory factory = 
        new HttpComponentsClientHttpRequestFactory();
    factory.setConnectTimeout(2000);     // 连接超时 2s
    factory.setReadTimeout(5000);        // 读取超时 5s
    factory.setConnectionRequestTimeout(1000); // 从连接池获取连接超时 1s
    return new RestTemplate(factory);
}

// 更好的做法：使用 Resilience4j 增加熔断保护
@CircuitBreaker(name = "inventoryService", fallbackMethod = "inventoryFallback")
public InventoryDTO checkStock(String skuId) {
    // 实际调用
}

-- MySQL：查看当前正在执行的慢查询
SHOW FULL PROCESSLIST;

-- 查看慢查询日志
-- my.cnf: slow_query_log=1, long_query_time=0.5
-- 或用 pt-query-digest 分析慢日志
pt-query-digest /var/log/mysql/slow.log

-- Druid 监控（Spring Boot 集成）
-- 访问 /druid/sql.html 查看 SQL 监控面板

EXPLAIN SELECT o.*, u.name FROM orders o 
JOIN users u ON o.user_id = u.id
WHERE o.create_time > '2024-01-01' AND o.status = 1;

-- 关键字段解读：
-- type: ALL（全表扫描）= 最差，ref/index = 较好，const = 最优
-- rows: 预估扫描行数，过大说明需要优化
-- Extra: Using filesort/Using temporary = 需要优化
-- key: 实际使用的索引，NULL = 未使用索引

-- MySQL 8.0 查看锁等待
SELECT 
    r.trx_id waiting_trx_id,
    r.trx_mysql_thread_id waiting_thread,
    r.trx_query waiting_query,
    b.trx_id blocking_trx_id,
    b.trx_mysql_thread_id blocking_thread,
    b.trx_query blocking_query
FROM information_schema.innodb_lock_waits w
JOIN information_schema.innodb_trx b ON b.trx_id = w.blocking_trx_id
JOIN information_schema.innodb_trx r ON r.trx_id = w.requesting_trx_id;

// 连接池是 RT 突增的常见放大器
// 慢 SQL → 连接持有时间变长 → 连接池耗尽 → 新请求等待连接 → RT 进一步恶化

// Druid 监控关键指标：
// ActiveCount：当前活跃连接数
// WaitThreadCount：等待获取连接的线程数 ← 关注这个
// 如果 WaitThreadCount > 0，说明连接池不够用

# 连接池配置建议
spring:
  datasource:
    druid:
      initial-size: 10
      min-idle: 10
      max-active: 50          # 不宜过大，MySQL 连接数有限
      max-wait: 3000          # 获取连接最大等待时间
      test-on-borrow: true    # 验证连接有效性
      validation-query: SELECT 1
      # 关键：慢 SQL 监控
      filter:
        stat:
          log-slow-sql: true
          slow-sql-millis: 1000

正常：RT 基线 200ms，GC 偶尔 50ms STW，P99 约 300ms
异常：Full GC 频繁，每次 2s STW，P99 飙升至 2s+

# 查看 GC 日志（JDK 8）

- XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/path/to/gc.log


# 查看 GC 日志（JDK 11+）

- Xlog:gc*:file=/path/to/gc.log:time,level,tags


# 使用 jstat 实时查看
jstat -gc <pid> 1000 10   # 每秒打印一次，共 10 次

# 关键输出列：
# YGC/Full GC 次数
# YGCT/FGCT 总耗时
# GCT 总 GC 时间

# 典型 4C8G 应用的 GC 参数

- Xms4g -Xmx4g                    # 堆 4G，避免动态调整


- Xmn2g                           # 年轻代 2G（堆的一半）


- XX:+UseG1GC                     # 使用 G1（JDK 9+ 默认）


- XX:MaxGCPauseMillis=200         # 期望最大停顿 200ms


- XX:G1HeapRegionSize=4m          # Region 大小


- XX:InitiatingHeapOccupancyPercent=45  # 并发标记开始的堆占用阈值


- XX:+PrintGCDetails


- XX:+PrintGCDateStamps


- Xloggc:/var/log/app/gc.log


- XX:+UseGCLogFileRotation


- XX:NumberOfGCLogFiles=10


- XX:GCLogFileSize=100M


- XX:+HeapDumpOnOutOfMemoryError


- XX:HeapDumpPath=/var/log/app/heapdump.hprof

# Step 1: 使用 jmap 导出堆转储
jmap -dump:live,format=b,file=/tmp/heap.hprof <pid>

# Step 2: 使用 MAT 或 JProfiler 分析
# 重点关注：Dominator Tree（支配树）中的大对象
# 常见泄漏模式：
# - ThreadLocal 未清理
# - 静态集合无限增长
# - 连接未关闭
# - 监听器未取消注册

请求进入 → 提交到线程池 
  → 核心线程有空闲 → 立即执行（RT 正常）
  → 核心线程忙 → 进入队列等待（RT 增加队列等待时间）
  → 队列满 → 创建新线程到 maxPoolSize（RT 增加创建开销）
  → 线程也满 → 执行拒绝策略（RT = 失败或降级）

某个请求变慢 → 线程占用时间变长 → 可用线程减少
→ 新请求排队等待 → 队列堆积 → 请求超时
→ 调用方重试 → 更多请求涌入 → 线程池彻底崩溃

# Arthas 查看线程池状态
thread -b                    # 找出阻塞线程
thread -n 5                  # 最忙的 5 个线程
thread --state WAITING       # 查看 WAITING 线程

# 查看线程池 MBean
# 通过 jconsole 或 jmxterm 查看
# java.util.concurrent:type=ThreadPoolExecutor,name=*
# 关键属性：
# - ActiveCount：当前活跃线程
# - PoolSize：当前线程数
# - QueueSize：队列中等待的任务数 ← 最关键的指标
# - CompletedTaskCount：已完成任务数
# - RejectedCount：被拒绝的任务数

// 线程池配置：没有银弹，但有一套计算逻辑

// CPU 密集型任务
int cpuCore = Runtime.getRuntime().availableProcessors();
ThreadPoolExecutor cpuPool = new ThreadPoolExecutor(
    cpuCore + 1,           // corePoolSize
    cpuCore + 1,           // maxPoolSize（CPU 密集型不建超出核心数）
    60, TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(1000),
    new ThreadPoolExecutor.CallerRunsPolicy() // 让调用线程执行，防止丢任务
);

// IO 密集型任务
ThreadPoolExecutor ioPool = new ThreadPoolExecutor(
    cpuCore * 2,           // corePoolSize
    cpuCore * 4,           // maxPoolSize
    60, TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(5000),
    new ThreadPoolExecutor.CallerRunsPolicy()
);

// 更精确的公式（考虑阻塞系数）：
// 线程数 = CPU核心数 * (1 + 平均等待时间 / 平均计算时间)
// 例如：8核CPU，平均等待时间 100ms，平均计算时间 20ms
// 线程数 = 8 * (1 + 100/20) = 48

@Component
public class ThreadPoolMonitor {
    
    @Scheduled(fixedRate = 10000)
    public void monitorThreadPools() {
        for (Map.Entry<String, ThreadPoolExecutor> entry : pools.entrySet()) {
            ThreadPoolExecutor pool = entry.getValue();
            String name = entry.getKey();
            
            int active = pool.getActiveCount();
            int queue = pool.getQueue().size();
            long completed = pool.getCompletedTaskCount();
            int poolSize = pool.getPoolSize();
            
            // 告警条件
            if (active >= pool.getCorePoolSize() * 0.8) {
                log.warn("线程池[{}]活跃线程接近上限: active={}, core={}", 
                    name, active, pool.getCorePoolSize());
            }
            if (queue > 100) {
                log.warn("线程池[{}]队列堆积: queue={}", name, queue);
            }
            
            // 上报到监控系统
            meterRegistry.gauge(name + ".active", active);
            meterRegistry.gauge(name + ".queue", queue);
        }
    }
}

# 基础连通性
ping -c 100 <目标IP>     # 查看 RTT 和丢包率

# TCP 层延迟（避免 ICMP 被限速）
tcpping <目标IP> <port>

# 路径追踪
traceroute <目标IP>

# 抓包分析（终极手段）
tcpdump -i eth0 -w /tmp/capture.pcap host <目标IP> and port <port>
# 然后用 Wireshark 分析：
# - TCP 重传率
# - TCP 窗口大小
# - 三次握手耗时
# - TLS 握手耗时

# 查看网络统计
netstat -s | grep -i retransmit   # TCP 重传统计
ss -ti                              # 查看每个连接的 TCP 信息（RTT、重传等）

正常 RT 分布：  [200ms, 210ms, 205ms, 198ms, 220ms, 215ms]  ← 稳定
CPU 问题 RT 分布：[200ms, 300ms, 280ms, 250ms, 350ms, 310ms]  ← 整体上移
GC 问题 RT 分布： [200ms, 200ms, 2000ms, 200ms, 200ms, 1800ms] ← 毛刺
网络问题 RT 分布：[200ms, 500ms, 200ms, 800ms, 200ms, 1000ms] ← 随机毛刺 + 部分超时

经验法则：如果你的 P50 很低但 P99 很高，且毛刺不规律，
不伴随 CPU/GC 变化，大概率是网络问题。

# 1. 查看 QPS 变化
# Prometheus: rate(http_requests_total[5m])

# 2. 查看请求体大小
# Nginx access log 中的 $body_bytes_sent
# 或通过 Skywalking 的请求体大小监控

# 3. 分析请求分布
# 是否有某个用户/某个接口的请求量突然大增？
# 是否有某个入参值导致慢查询？

// 多层次流量防护

// 第一层：负载均衡层限流（Nginx）
// limit_req_zone $binary_remote_addr zone=perip:10m rate=100r/s;
// limit_req zone=perip burst=20 nodelay;

// 第二层：网关层限流（Spring Cloud Gateway）
@Bean
public KeyResolver ipKeyResolver() {
    return exchange -> Mono.just(
        exchange.getRequest().getRemoteAddress().getAddress().getHostAddress()
    );
}

// 第三层：应用层限流（Sentinel）
@SentinelResource(value = "createOrder", 
    blockHandler = "createOrderBlockHandler")
public OrderDTO createOrder(CreateOrderRequest request) {
    // 业务逻辑
}

// 第四层：线程池隔离（Hystrix 线程池隔离 / Sentinel 线程隔离）
// 将不同接口分配到不同线程池，避免慢接口拖垮快接口

接口 RT  ↑ 从 14:00 开始飙升
CPU 使用率 ↑ 从 30% 升至 70%
GC 频率 ↑ Young GC 从 5次/min 升至 20次/min
线程池活跃线程 ↑ 接近 maxPoolSize

traceId: abc123
├── /api/order/create [5000ms]
│   ├── userService.getUserInfo [50ms]     ← 正常
│   ├── inventoryService.lockStock [3000ms] ← 异常！基线 50ms
│   ├── priceService.calculatePrice [800ms] ← 异常！基线 30ms
│   └── orderService.saveOrder [100ms]     ← 正常

├── inventoryService.lockStock [3000ms]
│   ├── db.queryStock [30ms]        ← 正常
│   ├── db.lockRow [2500ms]         ← 异常！行锁等待
│   └── cache.updateStock [10ms]    ← 正常

14:00 - 告警触发
14:05 - 确认影响范围，排除网络和流量变化
14:10 - 通过链路追踪定位到 inventoryService
14:15 - 深入 inventoryService 发现锁等待
14:20 - 联系相关团队确认变更
14:25 - 确认根因并回滚变更
14:30 - RT 恢复正常
总耗时：30 分钟

流量先看，依赖紧追，
SQL 慢查，GC 别漏，
线程池满，网络兜底。

最优线程数 = CPU核心数 × (1 + 平均等待时间 / 平均计算时间)

最优线程数 = 8 × (1 + 40/10) = 8 × 5 = 40