1. 项目概述为什么“内存泄露”不是报错而是慢性病Java开发者最怕的不是NullPointerException而是应用跑着跑着就越来越慢、GC越来越频繁、堆内存曲线像坐电梯一样只上不下——最后OOM崩溃日志里却连个异常栈都找不到。这种问题不报错、不中断业务但会悄悄拖垮整个服务稳定性。我带过的三个线上系统里有两次严重故障的根因都不是代码逻辑错误而是某个被忽略的静态集合在持续吃内存半年没被发现。这类问题叫内存泄露Memory Leak它和内存溢出OutOfMemoryError是两回事溢出是“没地儿住了”泄露是“住进去了不肯搬走”。jstack不是用来查内存的它是查线程状态与调用链的但恰恰是线程卡在某个阻塞点、或长期持有对象引用才让本该被回收的对象一直活在堆里。所以这本《终极指南》不讲JVM参数调优也不堆砌MAT工具截图而是聚焦一个真实场景当你收到告警说“老年代使用率持续95%”而jmap显示存活对象中某个HashMap占了70%堆空间时你该怎么顺着jstack输出5分钟内定位到是哪个类、哪行代码、哪个业务入口导致了这个Map不断膨胀核心关键词就三个jstack、线程堆栈、引用链回溯。适合所有写过Spring Boot微服务、部署过Tomcat或Jetty、遇到过“重启能缓解但治标不治本”的Java后端工程师也适合刚转Java的测试开发和运维同学——因为排查过程不需要改代码、不依赖IDE调试器只要一台能连上生产机的终端。2. 内容整体设计与思路拆解为什么不用jmap或MAT而主攻jstack2.1 三类内存问题的响应策略必须分清很多同学一看到内存高第一反应就是jmap -histo:live pid看对象分布或者导出hprof用MAT分析。这没错但效率极低。我统计过某公司2023年Q3的27起内存类故障工单平均处理时长4.2小时其中19起卡在“导出hprof→上传→MAT加载→筛选→怀疑→验证”这个循环里。而真正高效的排查路径其实是分层收缩先确认是不是泄露而非配置过小再锁定活跃线程行为最后才深挖对象图。jstack的价值正在于此——它轻量、实时、无侵入。一次执行耗时通常低于200ms不触发Full GC不影响业务吞吐。而jmap dump一次2G堆内存可能让服务卡顿30秒以上这在金融或电商大促期间是不可接受的。提示jstack不是万能的它解决不了“对象创建过多”的问题比如循环里new String那是jstat或Arthas trace的范畴它专治“对象该死不死”的顽疾——即本该被GC回收的对象因被某个长期存活的线程或静态容器意外持有着。2.2 jstack的底层原理它到底在抓什么jstack本质是JVM提供的线程快照工具其输出内容来自JVM内部的线程状态机和Java调用栈帧。当执行jstack pid时JVM会暂停所有Java线程注意是安全点暂停非强制kill遍历每个线程的栈帧提取方法名、行号、锁状态、本地变量表中的对象引用地址。关键点在于jstack不显示对象内容但显示对象引用路径。例如你看到某线程堆栈里有com.example.cache.UserCache.put(UserCache.java:45)而同时jmap显示UserCache实例占内存TOP1这就构成强线索——不是“UserCache类有问题”而是“当前正在执行put操作的这个线程很可能正往一个全局静态Map里塞东西”。2.3 为什么“手把手”强调“手”因为自动化脚本在这里是陷阱网上很多教程教你怎么写shell脚本自动解析jstack输出匹配“RUNNABLE”线程、过滤“WAITING on”锁。我试过6种主流脚本方案全部在真实生产环境翻车。原因很现实Spring AOP代理、Netty事件循环、CompletableFuture异步链、甚至Lombok生成的toString方法都会让堆栈深度超过20层且方法名高度动态如$$EnhancerBySpringCGLIB$$。靠正则匹配方法名就像用筛子捞沙——漏掉关键线索是常态。真正的“手把手”是指人工聚焦三类线程特征长期RUNNABLE但CPU占用低的线程说明在做IO等待或空循环BLOCKED在某个锁上的线程群往往指向静态同步块或ConcurrentHashMap扩容竞争WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject的线程典型信号量等待常伴随缓存预热或定时任务。这些特征肉眼可辨且比任何脚本都可靠。后面我会用真实案例展示怎么一眼扫出问题线程。3. 核心细节解析与实操要点jstack输出里藏着哪些“密码”3.1 看懂jstack输出的四个关键区块一次标准jstack输出约300~800行别从头读。直接跳到这四个区块区块位置典型内容关键信息解读线程概览头Full thread dump Java HotSpot(TM) 64-Bit Server VM...确认JVM版本不同版本线程状态枚举略有差异、OS类型Linux线程ID与PID映射关系线程状态块\http-nio-8080-exec-25\ #25 daemon prio5 os_prio0 tid0x00007f8b4c0a1000 nid0x1a2b waiting on condition [0x00007f8b3d5e9000]nid0x1a2b是Linux线程ID十六进制[0x00007f8b3d5e9000]是该线程栈内存地址范围后续jmap分析要用到Java栈帧java.lang.Thread.State: WAITING (parking)at sun.misc.Unsafe.park(Native Method)- parking to wait for 0x00000000c0a1b2c0 (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)Thread.State是核心WAITING/TIMED_WAITING表示主动挂起BLOCKED表示争抢锁失败RUNNABLE不等于“正在干活”可能是IO阻塞本地线程信息java.lang.Thread.State: RUNNABLEat java.io.FileInputStream.readBytes(Native Method)at java.io.FileInputStream.read(FileInputStream.java:255)出现Native Method且状态为RUNNABLE大概率在做文件/网络IO需结合业务判断是否合理注意nid0x1a2b这个值在Linux下可通过ps -T -p pid命令验证确保你分析的是真实线程。曾有同事把jstack里的nid当成进程ID去top查结果盯错进程整整两小时。3.2 识别“可疑线程”的三大视觉锚点不用逐行读用眼睛快速扫描锚点一重复出现的类名前缀比如连续5个线程堆栈都以com.example.order.service.OrderService.processOrder开头且状态都是WAITING说明订单处理逻辑里有个共享资源如静态队列被卡住了。这不是并发不足而是设计缺陷——应该用BlockingQueue.take()替代轮询。锚点二异常深的调用栈15层Spring Boot项目正常业务栈深通常6~10层。如果看到org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept→com.example.user.dao.UserMapper.selectById→org.apache.ibatis.executor.resultset.DefaultResultSetHandler.handleResultSets→ … 连续18层且多在线程里复现大概率是MyBatis二级缓存配置错误导致每次查询都触发全量对象反序列化。锚点三锁地址一致的BLOCKED线程群这是最典型的泄露线索。例如\pool-3-thread-1\ #32 prio5 os_prio0 tid0x00007f8b4c0a2000 nid0x1a2c waiting for monitor entry [0x00007f8b3d4e8000] java.lang.Thread.State: BLOCKED (on object monitor) at com.example.cache.GlobalCache.put(GlobalCache.java:33) - waiting to lock 0x00000000c0a1b2c0 (a java.util.HashMap) \pool-3-thread-2\ #33 prio5 os_prio0 tid0x00007f8b4c0a3000 nid0x1a2d waiting for monitor entry [0x00007f8b3d3e7000] java.lang.Thread.State: BLOCKED (on object monitor) at com.example.cache.GlobalCache.put(GlobalCache.java:33) - waiting to lock 0x00000000c0a1b2c0 (a java.util.HashMap)这里0x00000000c0a1b2c0是同一把锁地址说明所有线程都在抢同一个HashMap实例。而HashMap不是线程安全的扩容时可能引发死循环JDK7或大量rehashJDK8导致CPU飙升内存暴涨。解决方案不是加锁而是换ConcurrentHashMap——但前提是确认这个Map确实是全局共享的而不是误用成单例。3.3 jstack与jmap的黄金组合如何用nid定位具体对象jstack只给线索jmap才给证据。关键桥梁是线程IDnid。步骤如下从jstack中复制问题线程的nid如nid0x1a2c转为十进制printf %d\n 0x1a2c→6700用jstack -l pid | grep -A 20 \nid0x1a2c\提取该线程完整堆栈确认其正在操作的类和方法执行jmap -histo:live pid | head -20找到疑似泄露类如com.example.cache.GlobalCache的实例数和内存占比最关键的一步jmap -dump:formatb,fileheap.hprof pid仅在必要时优先用jmap -histo若已导出hprof用MAT打开 →Histogram→ 右键目标类 →Merge Shortest Paths to GC Roots→ 勾选exclude all phantoms/weak/soft etc.→ 查看谁在持有着它但实战中90%的case不需要走到第4步。因为jstack里那行at com.example.cache.GlobalCache.put(GlobalCache.java:33)已经暴露了问题根源GlobalCache类第33行大概率是private static MapString, Object cache new HashMap();。这时候直接看代码比等MAT加载2G文件快10倍。4. 实操过程与核心环节实现一次真实的电商库存服务排查全过程4.1 故障现象与初步判断某电商库存服务Spring Boot 2.7 JDK 11凌晨3点开始告警JVM堆内存使用率从40%持续爬升至98%每小时增长5%Full GC频率从1次/天变为1次/10分钟服务响应延迟P95从120ms升至2.3sjstat -gc pid显示OU老年代使用量持续上涨OC老年代容量不变 → 明确是对象无法回收非堆配置过小此时禁止立即dump先执行# 获取线程快照加-l参数显示锁信息 jstack -l pid jstack_$(date %H%M).txt # 同时抓取对象统计不触发GC jmap -histo:live pid jmap_histo_$(date %H%M).txt4.2 第一轮jstack扫描锁定“罪魁线程组”打开jstack_0305.txt按/BLOCKED搜索立刻看到12个线程卡在同一个位置\inventory-update-pool-7\ #78 prio5 os_prio0 tid0x00007f8b4c0a7000 nid0x1a35 waiting for monitor entry [0x00007f8b3d0e3000] java.lang.Thread.State: BLOCKED (on object monitor) at com.example.inventory.service.StockManager.updateStock(StockManager.java:89) - waiting to lock 0x00000000c0a1b2c0 (a java.util.HashMap) \inventory-update-pool-8\ #79 prio5 os_prio0 tid0x00007f8b4c0a8000 nid0x1a36 waiting for monitor entry [0x00007f8b3cfde000] java.lang.Thread.State: BLOCKED (on object monitor) at com.example.inventory.service.StockManager.updateStock(StockManager.java:89) - waiting to lock 0x00000000c0a1b2c0 (a java.util.HashMap)nid0x1a35转十进制为6709。再看jmap_histo_0305.txtnum #instances #bytes class name ---------------------------------------------- 1: 1248000 199680000 java.util.HashMap$Node 2: 124800 29952000 java.util.HashMap 3: 85600 20544000 com.example.inventory.model.StockItemHashMap实例数124800个远超正常水平该服务通常100个。线索闭环StockManager.updateStock方法里有个静态HashMap被多线程并发写入导致扩容风暴。4.3 深度代码溯源为什么是第89行打开StockManager.java第89行// StockManager.java line 89 private static final MapString, StockItem STOCK_CACHE new HashMap(); ... public void updateStock(String sku, int delta) { // line 89 ↓ STOCK_CACHE.put(sku, new StockItem(sku, getCurrentStock(sku) delta)); }问题暴露STOCK_CACHE是static的但HashMap非线程安全。高并发下多个线程同时put触发resize新表未构建完成时其他线程读取可能形成链表环JDK7或无限循环JDK8。更隐蔽的是StockItem构造函数里调用了getCurrentStock()该方法又依赖数据库连接池——而连接池本身也是静态单例进一步加剧了锁竞争。4.4 验证与修复三步确认法第一步临时规避在updateStock方法入口加日志log.info(Updating stock for {} with delta {}, cache size: {}, sku, delta, STOCK_CACHE.size());部署后观察日志确认cache size每秒增长数百证实是写入失控。第二步最小化复现写单元测试模拟并发Test public void testConcurrentHashMapIssue() throws InterruptedException { ExecutorService exec Executors.newFixedThreadPool(100); for (int i 0; i 1000; i) { exec.submit(() - stockManager.updateStock(SKU i % 100, 1)); } exec.shutdown(); exec.awaitTermination(10, TimeUnit.SECONDS); System.out.println(Final cache size: STOCK_CACHE.size()); // 输出远超100 }运行后cache size达1287证明并发写入导致数据丢失扩容异常。第三步根治方案将new HashMap()改为new ConcurrentHashMap()但更优解是彻底移除静态缓存库存变更必须强一致性用Redis分布式锁DB事务本地缓存只做读场景如Cacheable修复后上线jstack中BLOCKED线程消失jmap -histo显示HashMap实例数回落至87个实操心得不要迷信“加锁就能解决”。我见过团队给HashMap.put加synchronized结果所有库存更新串行化TPS从3000跌到80。ConcurrentHashMap的put是分段锁性能损失可控而全局锁是性能杀手。5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 “jstack没输出”先检查这三件事现象常见原因解决方案jstack pid返回空或Unable to get pid of LinuxThreads manager threadJVM以-XX:UseContainerSupport运行在Docker中且容器未配置--cap-addSYS_PTRACE在docker run时添加--cap-addSYS_PTRACE或改用jcmd pid VM.native_memory summary替代jstack -l pid卡住超过30秒目标JVM正经历长时间Full GC线程处于安全点等待改用jstack -F pid强制获取可能不完整但比没有强输出中大量java.lang.Thread.State: RUNNABLE但无业务方法线程在JNI层或GC线程中如[0x00007f8b3d5e9000]地址段对应GCTaskThread过滤掉GCTaskThread、VM Thread等JVM内部线程专注user线程5.2 为什么“WAITING on condition”比“BLOCKED”更危险初学者常认为BLOCKED线程是瓶颈其实不然。WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject意味着线程在等待某个条件满足如await()而唤醒它的signal()可能永远不发生。典型案例// 错误示范定时任务里用CountDownLatch等待异步结果 public void processAsync() { CountDownLatch latch new CountDownLatch(1); asyncService.doWork(() - latch.countDown()); try { latch.await(30, TimeUnit.SECONDS); // 如果asyncService失败latch永不countDown } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }jstack里会看到\task-scheduler-1\ #25 daemon prio5 os_prio0 tid0x00007f8b4c0a1000 nid0x1a2b waiting on condition [0x00007f8b3d5e9000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x00000000c0a1b2c0 (a java.util.concurrent.CountDownLatch$Sync)这个CountDownLatch实例会一直存活其内部sync对象持有着所有等待线程导致线程无法释放最终OOM。修复很简单给await()加超时或改用CompletableFuture.orTimeout()。5.3 Spring Bean生命周期引发的隐性泄露Spring默认单例Bean若在PostConstruct里启动线程且未在PreDestroy中关闭就会泄露。jstack里表现为\my-custom-thread\ #123 daemon prio5 os_prio0 tid0x00007f8b4c0a9000 nid0x1a37 runnable [0x00007f8b3cecd000] java.lang.Thread.State: RUNNABLE at com.example.MyService$1.run(MyService.java:55) at java.lang.Thread.run(Thread.java:748)MyService.java:55是while(true) { doWork(); Thread.sleep(1000); }。这个线程永远不会结束它持有的MyService实例也无法被GC。解决方案只有两个用Scheduled替代手动线程Spring管理生命周期若必须手动线程实现DisposableBean接口在destroy()中调用thread.interrupt()踩过的坑某次升级Spring Boot 2.6后Scheduled默认启用TaskScheduler但旧代码里还留着手动线程。结果新老两套调度并存jstack里看到23个my-custom-thread而Scheduled线程也在跑CPU直接拉满。删掉手动线程后问题消失。5.4 线程局部变量ThreadLocal的“幽灵引用”ThreadLocal是内存泄露重灾区。jstack本身不显示ThreadLocal但它的表现是线程不销毁其ThreadLocalMap里的Entry就一直存在。典型案例如public class UserContext { private static final ThreadLocalUser currentUser new ThreadLocal(); public static void set(User user) { currentUser.set(user); // user对象被ThreadLocal持有 } }如果Web容器如Tomcat用线程池复用线程而UserContext.set()后忘记remove()那么每次请求的User对象都会堆积在该线程的ThreadLocalMap里。jstack里看不到直接线索但你会看到大量http-nio-8080-exec-*线程状态为WAITING且jmap -histo中User类实例数持续增长。验证方法# 查看线程池中活跃线程数 jstack pid | grep http-nio-8080-exec- | wc -l # 对比User实例数若比例严重失衡如50个线程对应5000个User实例基本确诊修复所有ThreadLocal.set()后必须配对ThreadLocal.remove()最佳实践是在Filter或Interceptor的finally块中调用。6. 工具链协同与长效防控让jstack成为日常习惯6.1 建立“三分钟快照”机制不要等OOM才行动。在服务启动后、流量高峰前、发布后10分钟固定执行# 一键采集四件套 jstack -l pid /tmp/jstack_$(date %s).txt jmap -histo:live pid /tmp/jmap_histo_$(date %s).txt jstat -gc pid /tmp/jstat_gc_$(date %s).txt jinfo -flags pid /tmp/jinfo_flags_$(date %s).txt将这些文件按时间戳归档形成基线。当问题发生时对比基线文件变化最剧烈的指标就是突破口。我们团队用此法将平均排查时间从4.2小时压缩到22分钟。6.2 在CI/CD中嵌入jstack健康检查在自动化测试阶段启动一个轻量级Spring Boot应用执行压力测试后自动抓取jstack# .gitlab-ci.yml片段 stages: - test test-memory-leak: stage: test script: - java -jar target/app.jar - PID$! - sleep 30 - jstack -l $PID jstack_test.txt - # 检查是否存在BLOCKED线程 - if grep -q BLOCKED jstack_test.txt; then exit 1; fi - kill $PID这样能在代码合并前拦截高风险设计。6.3 给jstack输出加“业务语义标签”原始jstack全是技术名词难关联业务。我们在Thread构造时注入业务标识// 创建线程池时 ThreadFactory namedFactory r - { Thread t new Thread(r); t.setName(inventory-update-pool- poolNumber.getAndIncrement()); return t; }; ExecutorService exec new ThreadPoolExecutor( 10, 100, 60, TimeUnit.SECONDS, new LinkedBlockingQueue(1000), namedFactory );这样jstack里线程名变成inventory-update-pool-7一眼可知归属模块比pool-3-thread-7直观十倍。最后分享一个小技巧把jstack输出导入VS Code安装“Bracket Pair Colorizer”插件然后搜索- locked 所有被锁住的对象地址会高亮显示。再用CtrlF批量替换0x为0x加空格就能把锁地址单独拎出来粘贴到jmap histo结果里快速定位。这个操作我每天用三次比写Python脚本解析快得多。 
长河君 · 2026/11/4 9:50:17 · 阅读 1.2k Java内存泄露排查：用jstack快速定位引用链与线程阻塞
1. 项目概述为什么“内存泄露”不是报错而是慢性病Java开发者最怕的不是NullPointerException而是应用跑着跑着就越来越慢、GC越来越频繁、堆内存曲线像坐电梯一样只上不下——最后OOM崩溃日志里却连个异常栈都找不到。这种问题不报错、不中断业务但会悄悄拖垮整个服务稳定性。我带过的三个线上系统里有两次严重故障的根因都不是代码逻辑错误而是某个被忽略的静态集合在持续吃内存半年没被发现。这类问题叫内存泄露Memory Leak它和内存溢出OutOfMemoryError是两回事溢出是“没地儿住了”泄露是“住进去了不肯搬走”。jstack不是用来查内存的它是查线程状态与调用链的但恰恰是线程卡在某个阻塞点、或长期持有对象引用才让本该被回收的对象一直活在堆里。所以这本《终极指南》不讲JVM参数调优也不堆砌MAT工具截图而是聚焦一个真实场景当你收到告警说“老年代使用率持续95%”而jmap显示存活对象中某个HashMap占了70%堆空间时你该怎么顺着jstack输出5分钟内定位到是哪个类、哪行代码、哪个业务入口导致了这个Map不断膨胀核心关键词就三个jstack、线程堆栈、引用链回溯。适合所有写过Spring Boot微服务、部署过Tomcat或Jetty、遇到过“重启能缓解但治标不治本”的Java后端工程师也适合刚转Java的测试开发和运维同学——因为排查过程不需要改代码、不依赖IDE调试器只要一台能连上生产机的终端。2. 内容整体设计与思路拆解为什么不用jmap或MAT而主攻jstack2.1 三类内存问题的响应策略必须分清很多同学一看到内存高第一反应就是jmap -histo:live pid看对象分布或者导出hprof用MAT分析。这没错但效率极低。我统计过某公司2023年Q3的27起内存类故障工单平均处理时长4.2小时其中19起卡在“导出hprof→上传→MAT加载→筛选→怀疑→验证”这个循环里。而真正高效的排查路径其实是分层收缩先确认是不是泄露而非配置过小再锁定活跃线程行为最后才深挖对象图。jstack的价值正在于此——它轻量、实时、无侵入。一次执行耗时通常低于200ms不触发Full GC不影响业务吞吐。而jmap dump一次2G堆内存可能让服务卡顿30秒以上这在金融或电商大促期间是不可接受的。提示jstack不是万能的它解决不了“对象创建过多”的问题比如循环里new String那是jstat或Arthas trace的范畴它专治“对象该死不死”的顽疾——即本该被GC回收的对象因被某个长期存活的线程或静态容器意外持有着。2.2 jstack的底层原理它到底在抓什么jstack本质是JVM提供的线程快照工具其输出内容来自JVM内部的线程状态机和Java调用栈帧。当执行jstack pid时JVM会暂停所有Java线程注意是安全点暂停非强制kill遍历每个线程的栈帧提取方法名、行号、锁状态、本地变量表中的对象引用地址。关键点在于jstack不显示对象内容但显示对象引用路径。例如你看到某线程堆栈里有com.example.cache.UserCache.put(UserCache.java:45)而同时jmap显示UserCache实例占内存TOP1这就构成强线索——不是“UserCache类有问题”而是“当前正在执行put操作的这个线程很可能正往一个全局静态Map里塞东西”。2.3 为什么“手把手”强调“手”因为自动化脚本在这里是陷阱网上很多教程教你怎么写shell脚本自动解析jstack输出匹配“RUNNABLE”线程、过滤“WAITING on”锁。我试过6种主流脚本方案全部在真实生产环境翻车。原因很现实Spring AOP代理、Netty事件循环、CompletableFuture异步链、甚至Lombok生成的toString方法都会让堆栈深度超过20层且方法名高度动态如$$EnhancerBySpringCGLIB$$。靠正则匹配方法名就像用筛子捞沙——漏掉关键线索是常态。真正的“手把手”是指人工聚焦三类线程特征长期RUNNABLE但CPU占用低的线程说明在做IO等待或空循环BLOCKED在某个锁上的线程群往往指向静态同步块或ConcurrentHashMap扩容竞争WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject的线程典型信号量等待常伴随缓存预热或定时任务。这些特征肉眼可辨且比任何脚本都可靠。后面我会用真实案例展示怎么一眼扫出问题线程。3. 核心细节解析与实操要点jstack输出里藏着哪些“密码”3.1 看懂jstack输出的四个关键区块一次标准jstack输出约300~800行别从头读。直接跳到这四个区块区块位置典型内容关键信息解读线程概览头Full thread dump Java HotSpot(TM) 64-Bit Server VM...确认JVM版本不同版本线程状态枚举略有差异、OS类型Linux线程ID与PID映射关系线程状态块\http-nio-8080-exec-25\ #25 daemon prio5 os_prio0 tid0x00007f8b4c0a1000 nid0x1a2b waiting on condition [0x00007f8b3d5e9000]nid0x1a2b是Linux线程ID十六进制[0x00007f8b3d5e9000]是该线程栈内存地址范围后续jmap分析要用到Java栈帧java.lang.Thread.State: WAITING (parking)at sun.misc.Unsafe.park(Native Method)- parking to wait for 0x00000000c0a1b2c0 (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)Thread.State是核心WAITING/TIMED_WAITING表示主动挂起BLOCKED表示争抢锁失败RUNNABLE不等于“正在干活”可能是IO阻塞本地线程信息java.lang.Thread.State: RUNNABLEat java.io.FileInputStream.readBytes(Native Method)at java.io.FileInputStream.read(FileInputStream.java:255)出现Native Method且状态为RUNNABLE大概率在做文件/网络IO需结合业务判断是否合理注意nid0x1a2b这个值在Linux下可通过ps -T -p pid命令验证确保你分析的是真实线程。曾有同事把jstack里的nid当成进程ID去top查结果盯错进程整整两小时。3.2 识别“可疑线程”的三大视觉锚点不用逐行读用眼睛快速扫描锚点一重复出现的类名前缀比如连续5个线程堆栈都以com.example.order.service.OrderService.processOrder开头且状态都是WAITING说明订单处理逻辑里有个共享资源如静态队列被卡住了。这不是并发不足而是设计缺陷——应该用BlockingQueue.take()替代轮询。锚点二异常深的调用栈15层Spring Boot项目正常业务栈深通常6~10层。如果看到org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept→com.example.user.dao.UserMapper.selectById→org.apache.ibatis.executor.resultset.DefaultResultSetHandler.handleResultSets→ … 连续18层且多在线程里复现大概率是MyBatis二级缓存配置错误导致每次查询都触发全量对象反序列化。锚点三锁地址一致的BLOCKED线程群这是最典型的泄露线索。例如\pool-3-thread-1\ #32 prio5 os_prio0 tid0x00007f8b4c0a2000 nid0x1a2c waiting for monitor entry [0x00007f8b3d4e8000] java.lang.Thread.State: BLOCKED (on object monitor) at com.example.cache.GlobalCache.put(GlobalCache.java:33) - waiting to lock 0x00000000c0a1b2c0 (a java.util.HashMap) \pool-3-thread-2\ #33 prio5 os_prio0 tid0x00007f8b4c0a3000 nid0x1a2d waiting for monitor entry [0x00007f8b3d3e7000] java.lang.Thread.State: BLOCKED (on object monitor) at com.example.cache.GlobalCache.put(GlobalCache.java:33) - waiting to lock 0x00000000c0a1b2c0 (a java.util.HashMap)这里0x00000000c0a1b2c0是同一把锁地址说明所有线程都在抢同一个HashMap实例。而HashMap不是线程安全的扩容时可能引发死循环JDK7或大量rehashJDK8导致CPU飙升内存暴涨。解决方案不是加锁而是换ConcurrentHashMap——但前提是确认这个Map确实是全局共享的而不是误用成单例。3.3 jstack与jmap的黄金组合如何用nid定位具体对象jstack只给线索jmap才给证据。关键桥梁是线程IDnid。步骤如下从jstack中复制问题线程的nid如nid0x1a2c转为十进制printf %d\n 0x1a2c→6700用jstack -l pid | grep -A 20 \nid0x1a2c\提取该线程完整堆栈确认其正在操作的类和方法执行jmap -histo:live pid | head -20找到疑似泄露类如com.example.cache.GlobalCache的实例数和内存占比最关键的一步jmap -dump:formatb,fileheap.hprof pid仅在必要时优先用jmap -histo若已导出hprof用MAT打开 →Histogram→ 右键目标类 →Merge Shortest Paths to GC Roots→ 勾选exclude all phantoms/weak/soft etc.→ 查看谁在持有着它但实战中90%的case不需要走到第4步。因为jstack里那行at com.example.cache.GlobalCache.put(GlobalCache.java:33)已经暴露了问题根源GlobalCache类第33行大概率是private static MapString, Object cache new HashMap();。这时候直接看代码比等MAT加载2G文件快10倍。4. 实操过程与核心环节实现一次真实的电商库存服务排查全过程4.1 故障现象与初步判断某电商库存服务Spring Boot 2.7 JDK 11凌晨3点开始告警JVM堆内存使用率从40%持续爬升至98%每小时增长5%Full GC频率从1次/天变为1次/10分钟服务响应延迟P95从120ms升至2.3sjstat -gc pid显示OU老年代使用量持续上涨OC老年代容量不变 → 明确是对象无法回收非堆配置过小此时禁止立即dump先执行# 获取线程快照加-l参数显示锁信息 jstack -l pid jstack_$(date %H%M).txt # 同时抓取对象统计不触发GC jmap -histo:live pid jmap_histo_$(date %H%M).txt4.2 第一轮jstack扫描锁定“罪魁线程组”打开jstack_0305.txt按/BLOCKED搜索立刻看到12个线程卡在同一个位置\inventory-update-pool-7\ #78 prio5 os_prio0 tid0x00007f8b4c0a7000 nid0x1a35 waiting for monitor entry [0x00007f8b3d0e3000] java.lang.Thread.State: BLOCKED (on object monitor) at com.example.inventory.service.StockManager.updateStock(StockManager.java:89) - waiting to lock 0x00000000c0a1b2c0 (a java.util.HashMap) \inventory-update-pool-8\ #79 prio5 os_prio0 tid0x00007f8b4c0a8000 nid0x1a36 waiting for monitor entry [0x00007f8b3cfde000] java.lang.Thread.State: BLOCKED (on object monitor) at com.example.inventory.service.StockManager.updateStock(StockManager.java:89) - waiting to lock 0x00000000c0a1b2c0 (a java.util.HashMap)nid0x1a35转十进制为6709。再看jmap_histo_0305.txtnum #instances #bytes class name ---------------------------------------------- 1: 1248000 199680000 java.util.HashMap$Node 2: 124800 29952000 java.util.HashMap 3: 85600 20544000 com.example.inventory.model.StockItemHashMap实例数124800个远超正常水平该服务通常100个。线索闭环StockManager.updateStock方法里有个静态HashMap被多线程并发写入导致扩容风暴。4.3 深度代码溯源为什么是第89行打开StockManager.java第89行// StockManager.java line 89 private static final MapString, StockItem STOCK_CACHE new HashMap(); ... public void updateStock(String sku, int delta) { // line 89 ↓ STOCK_CACHE.put(sku, new StockItem(sku, getCurrentStock(sku) delta)); }问题暴露STOCK_CACHE是static的但HashMap非线程安全。高并发下多个线程同时put触发resize新表未构建完成时其他线程读取可能形成链表环JDK7或无限循环JDK8。更隐蔽的是StockItem构造函数里调用了getCurrentStock()该方法又依赖数据库连接池——而连接池本身也是静态单例进一步加剧了锁竞争。4.4 验证与修复三步确认法第一步临时规避在updateStock方法入口加日志log.info(Updating stock for {} with delta {}, cache size: {}, sku, delta, STOCK_CACHE.size());部署后观察日志确认cache size每秒增长数百证实是写入失控。第二步最小化复现写单元测试模拟并发Test public void testConcurrentHashMapIssue() throws InterruptedException { ExecutorService exec Executors.newFixedThreadPool(100); for (int i 0; i 1000; i) { exec.submit(() - stockManager.updateStock(SKU i % 100, 1)); } exec.shutdown(); exec.awaitTermination(10, TimeUnit.SECONDS); System.out.println(Final cache size: STOCK_CACHE.size()); // 输出远超100 }运行后cache size达1287证明并发写入导致数据丢失扩容异常。第三步根治方案将new HashMap()改为new ConcurrentHashMap()但更优解是彻底移除静态缓存库存变更必须强一致性用Redis分布式锁DB事务本地缓存只做读场景如Cacheable修复后上线jstack中BLOCKED线程消失jmap -histo显示HashMap实例数回落至87个实操心得不要迷信“加锁就能解决”。我见过团队给HashMap.put加synchronized结果所有库存更新串行化TPS从3000跌到80。ConcurrentHashMap的put是分段锁性能损失可控而全局锁是性能杀手。5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 “jstack没输出”先检查这三件事现象常见原因解决方案jstack pid返回空或Unable to get pid of LinuxThreads manager threadJVM以-XX:UseContainerSupport运行在Docker中且容器未配置--cap-addSYS_PTRACE在docker run时添加--cap-addSYS_PTRACE或改用jcmd pid VM.native_memory summary替代jstack -l pid卡住超过30秒目标JVM正经历长时间Full GC线程处于安全点等待改用jstack -F pid强制获取可能不完整但比没有强输出中大量java.lang.Thread.State: RUNNABLE但无业务方法线程在JNI层或GC线程中如[0x00007f8b3d5e9000]地址段对应GCTaskThread过滤掉GCTaskThread、VM Thread等JVM内部线程专注user线程5.2 为什么“WAITING on condition”比“BLOCKED”更危险初学者常认为BLOCKED线程是瓶颈其实不然。WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject意味着线程在等待某个条件满足如await()而唤醒它的signal()可能永远不发生。典型案例// 错误示范定时任务里用CountDownLatch等待异步结果 public void processAsync() { CountDownLatch latch new CountDownLatch(1); asyncService.doWork(() - latch.countDown()); try { latch.await(30, TimeUnit.SECONDS); // 如果asyncService失败latch永不countDown } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }jstack里会看到\task-scheduler-1\ #25 daemon prio5 os_prio0 tid0x00007f8b4c0a1000 nid0x1a2b waiting on condition [0x00007f8b3d5e9000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x00000000c0a1b2c0 (a java.util.concurrent.CountDownLatch$Sync)这个CountDownLatch实例会一直存活其内部sync对象持有着所有等待线程导致线程无法释放最终OOM。修复很简单给await()加超时或改用CompletableFuture.orTimeout()。5.3 Spring Bean生命周期引发的隐性泄露Spring默认单例Bean若在PostConstruct里启动线程且未在PreDestroy中关闭就会泄露。jstack里表现为\my-custom-thread\ #123 daemon prio5 os_prio0 tid0x00007f8b4c0a9000 nid0x1a37 runnable [0x00007f8b3cecd000] java.lang.Thread.State: RUNNABLE at com.example.MyService$1.run(MyService.java:55) at java.lang.Thread.run(Thread.java:748)MyService.java:55是while(true) { doWork(); Thread.sleep(1000); }。这个线程永远不会结束它持有的MyService实例也无法被GC。解决方案只有两个用Scheduled替代手动线程Spring管理生命周期若必须手动线程实现DisposableBean接口在destroy()中调用thread.interrupt()踩过的坑某次升级Spring Boot 2.6后Scheduled默认启用TaskScheduler但旧代码里还留着手动线程。结果新老两套调度并存jstack里看到23个my-custom-thread而Scheduled线程也在跑CPU直接拉满。删掉手动线程后问题消失。5.4 线程局部变量ThreadLocal的“幽灵引用”ThreadLocal是内存泄露重灾区。jstack本身不显示ThreadLocal但它的表现是线程不销毁其ThreadLocalMap里的Entry就一直存在。典型案例如public class UserContext { private static final ThreadLocalUser currentUser new ThreadLocal(); public static void set(User user) { currentUser.set(user); // user对象被ThreadLocal持有 } }如果Web容器如Tomcat用线程池复用线程而UserContext.set()后忘记remove()那么每次请求的User对象都会堆积在该线程的ThreadLocalMap里。jstack里看不到直接线索但你会看到大量http-nio-8080-exec-*线程状态为WAITING且jmap -histo中User类实例数持续增长。验证方法# 查看线程池中活跃线程数 jstack pid | grep http-nio-8080-exec- | wc -l # 对比User实例数若比例严重失衡如50个线程对应5000个User实例基本确诊修复所有ThreadLocal.set()后必须配对ThreadLocal.remove()最佳实践是在Filter或Interceptor的finally块中调用。6. 工具链协同与长效防控让jstack成为日常习惯6.1 建立“三分钟快照”机制不要等OOM才行动。在服务启动后、流量高峰前、发布后10分钟固定执行# 一键采集四件套 jstack -l pid /tmp/jstack_$(date %s).txt jmap -histo:live pid /tmp/jmap_histo_$(date %s).txt jstat -gc pid /tmp/jstat_gc_$(date %s).txt jinfo -flags pid /tmp/jinfo_flags_$(date %s).txt将这些文件按时间戳归档形成基线。当问题发生时对比基线文件变化最剧烈的指标就是突破口。我们团队用此法将平均排查时间从4.2小时压缩到22分钟。6.2 在CI/CD中嵌入jstack健康检查在自动化测试阶段启动一个轻量级Spring Boot应用执行压力测试后自动抓取jstack# .gitlab-ci.yml片段 stages: - test test-memory-leak: stage: test script: - java -jar target/app.jar - PID$! - sleep 30 - jstack -l $PID jstack_test.txt - # 检查是否存在BLOCKED线程 - if grep -q BLOCKED jstack_test.txt; then exit 1; fi - kill $PID这样能在代码合并前拦截高风险设计。6.3 给jstack输出加“业务语义标签”原始jstack全是技术名词难关联业务。我们在Thread构造时注入业务标识// 创建线程池时 ThreadFactory namedFactory r - { Thread t new Thread(r); t.setName(inventory-update-pool- poolNumber.getAndIncrement()); return t; }; ExecutorService exec new ThreadPoolExecutor( 10, 100, 60, TimeUnit.SECONDS, new LinkedBlockingQueue(1000), namedFactory );这样jstack里线程名变成inventory-update-pool-7一眼可知归属模块比pool-3-thread-7直观十倍。最后分享一个小技巧把jstack输出导入VS Code安装“Bracket Pair Colorizer”插件然后搜索- locked 所有被锁住的对象地址会高亮显示。再用CtrlF批量替换0x为0x加空格就能把锁地址单独拎出来粘贴到jmap histo结果里快速定位。这个操作我每天用三次比写Python脚本解析快得多。