本文是线上问题实战录系列的第 4 篇叙事框架现象 → 排查过程 → 根因 → 修复 → 预防问题现象线上问题排查中线程状态分析是最常用的手段之一。但 RUNNABLE 状态并不等同于线程正在高效执行这是一个普遍存在的认知误区。本文以一个真实案例展开Java 订单服务 CPU 使用率仅 25%p99 响应时间却从 30ms 飙升至 823ms。通过 top、jstack、perf 等工具的组合分析揭示了隐藏在 RUNNABLE 状态之下的真实瓶颈——大量线程处于可运行但因资源竞争尚未被调度执行的状态。本文详细还原了从现象到根因的完整排查链路。排查过程第一步top —— CPU 不高但 load average 很高登录生产服务器执行top结果让人困惑CPU 空闲 68%但 load average 高达 8.9。load average 远高于 CPU 使用率——说明有很多线程处于可运行状态但因为某种原因没有被调度执行或者在等待其他资源。第二步top -Hp —— 大量线程在 R 状态top-Hp17892输出显示 42 个线程处于 R 状态在 Linux 中对应 TASK_RUNNING但每个线程的 CPU 使用率不到 1.2%42 个线程都在 R 状态但几乎不消耗 CPU——这本身就很不正常。第三步jstack —— 全都在 SocketInputStream状态全是 RUNNABLEjstack17892/tmp/jstack-17892.txtgrep-A25http-nio-8080-exec-97/tmp/jstack-17892.txt157 个线程的状态都是RUNNABLE没有一个 BLOCKED 或 WAITING 的。更诡异的是——所有线程都卡在java.net.SocketInputStream.socketRead0(Native Method)。明明是在等网络 I/OJVM 却告诉你是 RUNNABLE。这就是第一个认知陷阱Java 里线程做网络 I/OSocket.read()时状态依然是 RUNNABLE不会变成 BLOCKED 或 WAITING。这是 HotSpot JVM 的实现细节SocketInputStream.read()底层调用的是 interruptible I/O 系统调用在 JVM 的线程状态模型中这种状态被映射为 RUNNABLE。也就是说JVM 的 RUNNABLE 不等于在 CPU 上执行它包括了在等待网络/磁盘 I/O 完成的情况。第四步perf top —— 从内核视角看真相既然 jstack 给不了答案切换到 OS 级别的分析工具sudoperftop-p17892结果一目了然符号占比含义tcp_recvmsg42.32%内核 TCP 接收数据sock_read15.18%socket 读取57.5% 的 CPU 时间花在内核态的网络收包上——线程根本不是在跑业务逻辑而是在等远程 socket 响应。第五步strace —— 精准确认sudostrace-f-p17892-etracenetwork-c78% 的系统调用时间花在recvfrom上——所有线程都在做 socket 读操作。证据链闭合了jstack 说线程在SocketInputStream.socketRead0→ 做网络 I/Operf top 说内核在tcp_recvmsg→ 等 TCP 数据strace 说系统调用在recvfrom→ 读 socket根因分析排查到这一步问题变成了为什么所有线程都堆积在等一个网络响应上查代码发现昨天上线的新版本引入了一个功能——调用外部评分服务score-api来丰富订单数据。实现使用的是 Java 11 的HttpClient// OrderServiceV1.javaprivatefinalHttpClientclientHttpClient.newHttpClient();问题出在HttpClient.newHttpClient()这个默认构造方法上。Java 11 的HttpClient.newHttpClient()使用的是内置的SimpleAsyncHttpClient默认每个路由只有 1 个连接。当 100 个请求同时进来只有 1 个请求能拿到连接正常发送其余 99 个请求排队等这个连接释放外部评分服务响应慢100~300ms连接被长时间占用队列越来越长响应越来越慢更糟糕的是请求超时设了 30 秒没有熔断机制——外部服务慢的时候线程就这样全部挂住。第二个认知陷阱很多人以为HttpClient.newHttpClient()是轻量级的但它的默认实现没有连接池在高并发场景下等于隐形的共享瓶颈。修复方案修复方案很明确自定义线程池为 HttpClient 配置独立的线程池连接超时设置 connectTimeout快速拒绝不可达的服务请求超时从 30 秒缩短到 5 秒// OrderServiceV2.javaThreadPoolExecutorexecutornewThreadPoolExecutor(4,8,30,TimeUnit.SECONDS,newLinkedBlockingQueue(100));this.clientHttpClient.newBuilder().executor(executor).connectTimeout(Duration.ofSeconds(3)).build();同时对于外部服务调用增加熔断机制使用 Resilience4j 或 Sentinel在外部服务故障时快速失败避免线程池被拖垮。验证结果修复后的效果立竿见影指标修复前修复后Load Average8.91.2CPU 使用率25%14%CPU Idle68%84%RUNNABLE 线程数15724p99 响应时间823ms42ms避坑建议1. 理解 JVM 线程状态的真实含义JVM 的线程状态和操作系统线程状态不是一一对应的JVM 状态对应 OS 状态典型场景RUNNABLETASK_RUNNING 或 TASK_INTERRUPTIBLE执行 CPU 计算或等待网络/磁盘 I/OBLOCKEDTASK_RUNNING等待进入 synchronized 块WAITINGTASK_RUNNING 或 TASK_INTERRUPTIBLEObject.wait()、LockSupport.park()RUNNABLE 不意味着在跑代码它只意味着 JVM 认为这个线程还能继续工作。2. 诊断工具配合使用场景首选工具补充工具CPU 高top -Hp→jstackarthas thread -n 3CPU 不高但服务慢perf topstrace -c、async-profiler怀疑网络 I/Operf top找 tcp_recvmsgsar -n TCP、ss -s线程阻塞jstackArthasthread -b3. HttpClient 使用规范禁止使用HttpClient.newHttpClient()默认构造必须使用HttpClient.newBuilder().executor(executor)自定义线程池必须设置connectTimeout建议 3s请求timeout不要超过业务容忍时间建议 5s4. 外部调用三件套任何对外部服务的 HTTP 调用都必须有连接池— 避免连接成为共享瓶颈超时控制— connectTimeout readTimeout requestTimeout熔断降级— 外部服务故障时快速失败保护自身5. 代码审查 Checklist 补充在高并发路径上引入外部网络调用时代码审查 checklist 中增加是否使用HttpClient.newBuilder()而不是newHttpClient()是否配置了连接池和超时外部服务故障是否有熔断/降级策略是否有 fallback 兜底逻辑附完整命令清单进程与线程级 CPU 排查top-b-n1|head-30# 进程 CPU 排行top-b-n1-Hppid|head-40# 线程 CPU 排行cat/proc/pid/status|grep-E^(Name|Pid|Threads|VmRSS|State)# 进程状态概览线程堆栈分析jstackpid/tmp/jstack-pid.txt# dump 线程堆栈grepThread.State/tmp/jstack-pid.txt|sort|uniq-c|sort-rn# 线程状态统计grep-A30http-nio-8080-exec-97/tmp/jstack-pid.txt|head-35# 查看业务线程堆栈grep-csocketRead0/tmp/jstack-pid.txt# 统计 socketRead0 线程数cat/tmp/jstack-pid.txt|grep-B2socketRead0|grepThread.State|sort|uniq-c# 统计特定方法状态内核级性能分析sudoperftop-ppid--stdio2/dev/null# CPU 热点分析内核态perfstat-etcp:tcp_rcv_space_adjust,tcp:tcp_receive_collapsed-ppid--sleep3# 内核 tracepoint 统计系统调用分析sudostrace-f-ppid-etracenetwork-c21# 网络系统调用耗时统计网络连接排查lsof-ppid|grep-cESTABLISHED# 统计 ESTABLISHED 连接数ss-tnp|greppid|awk{print $4}|seds/.*://|sort-n|uniq-c|sort-rn|head-5# 连接端口分布ss-tnp|greppid|grepscore-api|head-3# 按服务名过滤连接修复验证jstackpid|grepThread.State|sort|uniq-c|sort-rn# 修复后线程状态验证jstackpid|grep-csocketRead0# 修复后排队线程数curl-w\n-o/dev/null-shttp://localhost:8080/api/v1/orders/enriched/v2?orderIdtest001# 接口验证
的仿真解析)
