在高并发场景下Java并发编程是提升系统吞吐量和响应速度的核心手段但随之而来的死锁、线程竞争、线程泄漏等问题却常常让开发者陷入困境。这些问题大多具有偶发性、隐蔽性强的特点线下测试难以复现线上出现时又会直接影响业务可用性甚至导致系统崩溃。今天就结合实际开发案例系统梳理并发编程中最常见的三类问题从原理、定位到解决手把手教你快速排查高效修复让你的并发程序既高效又稳定。本文原创发布于2025-08-06收录于《Java 并发编程全解原理、实战与面试攻略》专栏全文基于真实项目实战总结代码可直接运行欢迎收藏转发一起交流学习一、死锁线程间的无限等待陷阱业务停滞的“致命杀手”死锁是并发编程中最经典、最危险的问题之一没有之一。它指的是两个或多个线程相互持有对方所需的资源且都不愿意主动释放最终导致所有相关线程永久阻塞业务完全停滞只能通过重启服务才能恢复。在高并发的支付、订单系统中死锁一旦发生可能直接造成经济损失因此必须提前预防、快速定位。1.1 死锁的4个必要条件缺一不可破坏其一即可避免死锁的产生并非偶然必须同时满足以下4个条件只要破坏其中任意一个就能从根本上杜绝死锁。很多开发者在排查死锁时无从下手核心就是没有吃透这4个条件无法精准定位问题根源。互斥条件资源具有排他性只能被一个线程持有无法被多个线程同时占用。比如Java中的synchronized锁、ReentrantLock都是典型的互斥资源。持有并等待线程已经持有了部分资源同时又在等待其他线程持有的资源且在等待过程中不释放自己已持有的资源。这是死锁产生的核心诱因之一。不可剥夺线程持有的资源只能由线程自身主动释放无法被其他线程强制剥夺。比如一个线程持有synchronized锁后其他线程只能等待它释放无法强行抢占。循环等待多个线程之间形成了相互等待资源的环形链比如线程A等待线程B的资源线程B等待线程C的资源线程C等待线程A的资源形成闭环。1.2 死锁实战示例可直接运行复现死锁场景下面这个案例模拟了实际开发中最常见的死锁场景两个线程相互获取对方持有的锁最终导致永久阻塞。大家可以复制代码运行直观感受死锁的现象。public class DeadLockDemo { // 定义两个互斥锁资源模拟实际开发中的两个资源如订单锁、库存锁 private static final Object LOCK_A new Object(); private static final Object LOCK_B new Object(); public static void main(String[] args) { // 线程1先获取LOCK_A订单锁再尝试获取LOCK_B库存锁 new Thread(() - { synchronized (LOCK_A) { System.out.println(线程1获取到订单锁LOCK_A等待库存锁LOCK_B...); try { // 模拟业务处理耗时放大死锁概率实际开发中可能是查询、计算等操作 Thread.sleep(100); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } // 此时线程1持有LOCK_A等待LOCK_B synchronized (LOCK_B) { System.out.println(线程1获取到库存锁LOCK_B执行订单创建库存扣减完成); } } }, 订单处理线程).start(); // 线程2先获取LOCK_B库存锁再尝试获取LOCK_A订单锁 new Thread(() - { synchronized (LOCK_B) { System.out.println(线程2获取到库存锁LOCK_B等待订单锁LOCK_A...); try { Thread.sleep(100); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } // 此时线程2持有LOCK_B等待LOCK_A形成循环等待 synchronized (LOCK_A) { System.out.println(线程2获取到订单锁LOCK_A执行库存扣减订单确认完成); } } }, 库存处理线程).start(); } }运行结果线程1获取到订单锁LOCK_A等待库存锁LOCK_B... 线程2获取到库存锁LOCK_B等待订单锁LOCK_A...程序会永久阻塞没有后续输出此时死锁已经发生。如果这是线上环境订单和库存相关的业务会完全停滞用户无法下单、无法支付影响极大。1.3 死锁定位3大利器实战必备快速定位问题死锁发生后核心是快速定位哪个线程、持有哪些资源、等待哪些资源。下面这3个工具是Java开发者排查死锁的必备技能从命令行到图形化覆盖不同场景需求。1jstack命令命令行首选快速检测死锁jstack是JDK自带的命令行工具无需额外安装可直接生成Java进程的线程快照并且能自动检测死锁适合线上服务器无图形化界面排查。操作步骤实战分步讲解执行jps命令获取目标Java进程的PID进程ID。比如运行上面的DeadLockDemo后执行jps会输出类似内容jps # 输出示例12345为进程PIDDeadLockDemo为进程名称 12345 DeadLockDemo 9876 Jps执行jstack -l PID生成线程快照-l参数用于显示线程的详细信息包括锁持有情况jstack -l 12345死锁检测关键片段Found one Java-level deadlock: 库存处理线程: waiting to lock monitor 0x00007f8a1c006000 (object 0x000000076b6a6690, a java.lang.Object), which is held by 订单处理线程 订单处理线程: waiting to lock monitor 0x00007f8a1c008c00 (object 0x000000076b6a66a0, a java.lang.Object), which is held by 库存处理线程 Java stack information for the threads listed above: 库存处理线程: at DeadLockDemo.lambda$main$1(DeadLockDemo.java:25) - waiting to lock 0x000000076b6a6690 (a java.lang.Object) # 等待的锁 - locked 0x000000076b6a66a0 (a java.lang.Object) # 已持有的锁 at DeadLockDemo$$Lambda$2/1078694789.run(Unknown Source) at java.lang.Thread.run(Thread.java:748) 订单处理线程: at DeadLockDemo.lambda$main$0(DeadLockDemo.java:14) - waiting to lock 0x000000076b6a66a0 (a java.lang.Object) # 等待的锁 - locked 0x000000076b6a6690 (a java.lang.Object) # 已持有的锁 at DeadLockDemo$$Lambda$1/1324119927.run(Unknown Source) at java.lang.Thread.run(Thread.java:748) Found 1 deadlock.分析jstack会明确标记“Found 1 deadlock”并列出死锁的线程名称、等待的锁和已持有的锁一目了然能快速定位到死锁的代码行如上面的第14行、第25行。2VisualVM图形化工具直观易懂如果是本地开发、测试环境VisualVM会更方便它是JDK自带的可视化监控工具支持线程监控、死锁检测、内存分析等功能操作简单适合非命令行用户。操作步骤启动VisualVM在命令行输入jvisualvm即可启动工具无需额外配置。连接目标进程在左侧“应用程序”列表中找到运行的DeadLockDemo进程双击连接。检测死锁切换到“线程”标签页点击右上角的“检测死锁”按钮工具会自动分析线程状态弹出死锁详情窗口清晰展示线程持有和等待的锁关系。优势图形化界面直观无需分析复杂的命令行输出适合快速排查本地开发中的死锁问题尤其适合新手。3日志与监控提前预警防患于未然死锁往往是偶发性的线上环境可能几天、几个月才出现一次等出现时已经造成损失。因此提前监控、日志追踪才能在死锁发生前预警减少损失。实战技巧在锁的获取和释放处打印详细日志追踪线程的锁操作轨迹。比如// 增强锁操作日志便于追踪线程行为 synchronized (LOCK_A) { log.info(线程{}获取到订单锁LOCK_A当前时间{}, Thread.currentThread().getName(), LocalDateTime.now()); try { // 业务逻辑 } finally { log.info(线程{}释放订单锁LOCK_A当前时间{}, Thread.currentThread().getName(), LocalDateTime.now()); } }结合监控系统如PrometheusGrafana监控锁等待时间。当某个锁的等待时间超过阈值如1秒时触发告警提醒开发者及时排查避免死锁发生。1.4 死锁的解决与预防策略实战落地杜绝死锁排查死锁的最终目的是解决和预防结合前面的4个死锁条件我们可以针对性地破坏其中一个或多个条件从根本上杜绝死锁。下面这3个策略是实际开发中最常用、最易落地的方案。1破坏循环等待统一锁获取顺序最推荐无侵入死锁的核心是“循环等待”只要规定所有线程按相同的顺序获取锁就能打破环形链从根本上避免死锁。这是最推荐的方案代码侵入性低易于维护。修改示例将前面的死锁代码修改为“统一按LOCK_A→LOCK_B的顺序获取锁”// 线程1按LOCK_A→LOCK_B顺序获取不变 synchronized (LOCK_A) { System.out.println(线程1获取到订单锁LOCK_A等待库存锁LOCK_B...); synchronized (LOCK_B) { System.out.println(线程1获取到库存锁LOCK_B执行完成); } } // 线程2修改为按LOCK_A→LOCK_B顺序获取原逻辑修改 synchronized (LOCK_A) { System.out.println(线程2获取到订单锁LOCK_A等待库存锁LOCK_B...); synchronized (LOCK_B) { System.out.println(线程2获取到库存锁LOCK_B执行完成); } }原理此时两个线程都先获取LOCK_A再获取LOCK_B不会形成循环等待。即使线程1先获取到LOCK_A线程2会等待LOCK_A释放不会出现相互等待的情况。实战注意实际开发中锁的顺序可以按资源的唯一标识如订单ID、库存ID排序确保所有线程都按相同顺序获取锁。比如多个线程操作不同的订单和库存时按订单ID的大小顺序获取锁。2破坏持有并等待使用tryLock()避免无限等待synchronized锁是不可中断的一旦线程等待锁就会一直阻塞直到获取到锁。而ReentrantLock提供的tryLock(long timeout, TimeUnit unit)方法可在超时后放弃获取锁并释放已持有的资源打破“持有并等待”条件避免永久阻塞。实战代码示例import java.util.concurrent.TimeUnit; import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; public class TryLockDemo { private static final Lock LOCK_A new ReentrantLock(); // 订单锁 private static final Lock LOCK_B new ReentrantLock(); // 库存锁 public static void main(String[] args) { new Thread(() - { try { // 尝试获取LOCK_A超时时间1秒 if (LOCK_A.tryLock(1, TimeUnit.SECONDS)) { try { System.out.println(线程1获取到订单锁LOCK_A等待库存锁LOCK_B...); // 尝试获取LOCK_B超时时间1秒 if (LOCK_B.tryLock(1, TimeUnit.SECONDS)) { try { System.out.println(线程1获取到库存锁LOCK_B执行完成); } finally { LOCK_B.unlock(); // 释放LOCK_B } } else { System.out.println(线程1获取库存锁LOCK_B超时释放订单锁LOCK_A); } } finally { LOCK_A.unlock(); // 释放LOCK_A } } else { System.out.println(线程1获取订单锁LOCK_A超时放弃执行); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); // 恢复中断状态 } }, 订单处理线程).start(); // 线程2逻辑类似略同样使用tryLock()超时后释放资源 } }优势线程不会无限等待锁超时后会主动释放已持有的资源避免死锁。同时还能通过超时日志及时发现锁竞争激烈的问题提前优化。3破坏持有并等待减少锁持有时间锁持有时间越长线程等待的时间就越长死锁的概率也就越高。通过缩小同步代码块的范围只在核心业务逻辑处持有锁减少锁的占用时间可大幅降低死锁风险。优化对比// 优化前锁持有时间长包含无关操作如读数据、写日志 synchronized (lock) { readData(); // 耗时操作无需加锁 processData(); // 核心逻辑需要加锁 writeLog(); // 无关操作无需加锁 } // 优化后仅在核心逻辑处持有锁减少锁持有时间 readData(); // 锁外执行无需加锁 synchronized (lock) { processData(); // 核心逻辑仅此处加锁 } writeLog(); // 锁外执行无需加锁实战注意优化时要注意核心逻辑必须是原子操作不能拆分到锁外否则会出现线程安全问题如数据不一致。二、线程竞争与资源争用性能损耗的隐形杀手系统卡顿的根源如果说死锁是“致命伤”那么线程竞争就是“慢性病”——它不会导致系统立即崩溃但会导致系统响应缓慢、CPU利用率异常、吞吐量下降长期下去会严重影响用户体验。线程竞争指的是多个线程同时争夺同一资源如锁、CPU、内存导致线程频繁阻塞、上下文切换大量CPU资源被消耗在调度上而非业务处理上。2.1 线程竞争的典型表现快速识别精准判断线上系统出现以下症状时大概率是存在线程竞争问题需要及时排查CPU利用率很高接近100%但业务吞吐量很低响应时间很长如接口响应时间从100ms飙升到1s以上。通过jstack查看线程状态发现大量线程处于BLOCKED阻塞或WAITING等待状态且都是因为争夺同一把锁。系统响应时间波动大时而正常时而卡顿尤其是在高并发峰值时段。示例场景一个电商秒杀系统1000个线程同时竞争一个库存锁导致999个线程处于BLOCKED状态CPU大部分时间用于线程调度上下文切换而非库存扣减、订单创建等核心业务最终导致秒杀接口响应缓慢大量用户下单失败。核心原因锁竞争激烈导致大量线程阻塞等待上下文切换频繁一次上下文切换耗时约1-10微秒高并发下累计耗时惊人消耗大量CPU资源。2.2 线程竞争的定位手段精准找到热点锁对症下药线程竞争的核心是“热点锁”——某一把锁被大量线程争夺。定位线程竞争本质就是找到这把热点锁以及对应的代码然后针对性优化。下面这3种手段覆盖从简单到复杂的排查场景。1jstacktop命令快速定位热点锁结合jstack和top命令可快速统计阻塞线程的数量和原因定位热点锁。操作步骤用top -H -p PID查看目标进程的线程CPU占用情况找到CPU占用高的线程IDLWP。用jstack PID生成线程快照将线程IDLWP转换为十六进制jstack输出的线程ID是十六进制找到对应的线程栈信息。统计阻塞线程的数量如果大量线程因同一把锁处于BLOCKED状态说明该锁是热点锁。jstack线程状态关键片段线程-999 #1000 prio5 os_prio31 tid0x00007f8a1d000000 nid0x1a03 waiting for monitor entry [0x000070000f9f6000] java.lang.Thread.State: BLOCKED (on object monitor) at CompetitionDemo.lambda$main$0(CompetitionDemo.java:10) - waiting to lock 0x000000076b6a66b0 (a java.lang.Object) # 大量线程等待同一把锁 at CompetitionDemo$$Lambda$1/1324119927.run(Unknown Source) at java.lang.Thread.run(Thread.java:748)分析大量线程等待0x000000076b6a66b0这把锁说明该锁是热点锁对应的代码行是CompetitionDemo.java第10行需要重点优化。2jconsole监控实时查看锁竞争情况jconsole是JDK自带的监控工具可实时查看线程状态和锁信息适合监控锁竞争的实时情况。操作步骤启动jconsole连接目标进程。切换到“线程”标签页查看线程状态分布BLOCKED、RUNNABLE、WAITING的线程数量。切换到“VM概要”标签页观察“总锁获取数”“锁争用数”两个关键指标。关键指标解读锁争用率 锁争用数 / 总锁获取数锁争用率越高说明锁竞争越激烈。一般来说锁争用率超过50%就需要优化了。3性能分析工具定位热点方法深入排查对于复杂的系统仅靠jstack和jconsole可能无法精准定位热点锁对应的业务方法此时需要使用专业的性能分析工具生成火焰图直观展示锁等待在CPU耗时中的占比。常用工具AsyncProfiler轻量级性能分析工具可生成CPU火焰图直观展示各个方法的CPU耗时占比。如果Object.wait()、ReentrantLock.lock()等方法在火焰图中占比很高说明锁竞争是性能瓶颈。VisualVM抽样器通过CPU抽样定位因锁竞争导致的热点方法适合本地开发、测试环境排查。火焰图解读技巧火焰图的横轴是方法调用栈纵轴是调用深度颜色越深代表CPU耗时越长。如果某一个锁相关的方法如lock()、wait()占据了大量的横轴空间说明该方法是热点对应的锁竞争激烈。2.3 线程竞争的解决策略实战优化提升性能解决线程竞争的核心思路是“减少锁的竞争强度”——要么减少争夺同一把锁的线程数量要么避免使用锁具体可根据业务场景选择以下策略。1减少锁粒度拆分资源降低竞争将一个大锁拆分为多个小锁让不同的线程争夺不同的小锁从而减少单个锁的竞争强度。这是实际开发中最常用的优化方案典型案例是ConcurrentHashMap的分段锁JDK7及之前。实战代码示例拆分锁优化// 优化前单锁竞争激烈所有线程争夺同一把锁适合低并发 class BigCache { private final Object lock new Object(); private final MapString, Object cache new HashMap(); public void put(String key, Object value) { synchronized (lock) { // 所有线程竞争同一把锁 cache.put(key, value); } } } // 优化后多锁拆分降低竞争适合高并发 class SplitCache { private static final int SEGMENTS 16; // 拆分16个段对应16把锁 private final Object[] locks new Object[SEGMENTS]; private final MapString, Object[] segments new Map[SEGMENTS]; public SplitCache() { // 初始化每段的锁和缓存 for (int i 0; i SEGMENTS; i) { locks[i] new Object(); segments[i] new HashMap(); } } public void put(String key, Object value) { // 按key的哈希值分配到不同的段确保同一key始终落在同一段 int segment Math.abs(key.hashCode() % SEGMENTS); synchronized (locks[segment]) { // 仅竞争该段的锁竞争强度降低16倍 segments[segment].put(key, value); } } }优势拆分后多个线程可以同时操作不同段的缓存无需争夺同一把锁锁竞争强度大幅降低系统吞吐量显著提升。实战注意拆分的段数不宜过多一般等于CPU核心数或2的幂否则会增加锁管理的开销同时要确保同一资源始终落在同一锁下避免数据不一致。2使用无锁数据结构避免锁竞争对于读多写少、或可容忍短暂数据不一致的场景使用无锁数据结构可彻底避免锁竞争提升并发性能。Java并发包中提供了多种无锁数据结构如AtomicInteger、AtomicLong、ConcurrentLinkedQueue等其底层基于CAS比较并交换机制实现无需加锁。实战示例无锁计数器// 优化前锁竞争导致性能低适合低并发计数 class SyncCounter { private int count 0; // 所有线程争夺同一把锁高并发下性能差 public synchronized void increment() { count; } } // 优化后无锁操作支持高并发适合高并发计数 class AtomicCounter { // AtomicInteger底层基于CAS机制无锁操作 private final AtomicInteger count new AtomicInteger(0); public void increment() { count.incrementAndGet(); } // 无锁原子操作 }优势无锁操作无需线程阻塞等待上下文切换少CPU利用率高适合高并发场景如秒杀计数、接口访问量统计。注意事项无锁结构适合简单的原子操作如计数、赋值复杂的业务逻辑如多步操作不适合使用否则会出现数据不一致问题。3读写锁分离读多写少场景的最优解很多业务场景都是“读多写少”如商品详情查询、用户信息查询此时使用ReentrantReadWriteLock读写锁可实现“读共享、写独占”大幅降低锁竞争。读线程之间不互斥可同时访问写线程与读线程、写线程与写线程互斥确保数据一致性。实战代码示例class ReadHeavyCache { // 读写锁读锁共享写锁独占 private final ReadWriteLock rwLock new ReentrantReadWriteLock(); private final Lock readLock rwLock.readLock(); // 读锁 private final Lock writeLock rwLock.writeLock(); // 写锁 private final MapString, Object cache new HashMap(); // 读操作共享锁多个读线程可同时执行 public Object get(String key) { readLock.lock(); try { return cache.get(key); } finally { readLock.unlock(); // 释放读锁 } } // 写操作独占锁仅一个写线程执行读线程需等待 public void put(String key, Object value) { writeLock.lock(); try { cache.put(key, value); } finally { writeLock.unlock(); // 释放写锁 } } }优势读多写少场景下多个读线程可同时访问无需等待大幅提升读性能写操作独占锁确保数据一致性兼顾性能和安全性。4合理设置线程池参数减少资源竞争线程池参数不合理会加剧线程竞争和上下文切换。比如核心线程数过多会导致CPU调度压力增大上下文切换频繁核心线程数过少会导致大量任务排队线程阻塞等待。因此需根据任务类型CPU密集型、IO密集型合理设置线程池参数。实战参数建议CPU密集型任务如计算、排序核心线程数 CPU核心数 ± 1。因为CPU密集型任务主要消耗CPU资源线程数过多会导致上下文切换频繁反而降低性能。IO密集型任务如数据库查询、网络请求核心线程数 CPU核心数 × 2或更高。因为IO密集型任务中线程大部分时间都在等待IO操作完成如等待数据库返回结果此时多设置线程数可提高CPU利用率。注意实际开发中可通过监控线程池的任务排队数、线程空闲时间动态调整线程池参数达到最优性能。三、线程泄漏资源耗尽的隐形推手系统崩溃的“定时炸弹”线程泄漏是容易被忽视但危害极大的并发问题。它指的是线程创建后未正常终止长期占用内存、线程池等系统资源随着时间推移资源被逐渐耗尽最终导致系统抛出OutOfMemoryError无法创建新线程系统崩溃。线程泄漏的隐蔽性很强线下测试很难发现往往在系统运行一段时间后如几天、几周才会爆发排查难度较大。3.1 线程泄漏的3个常见原因精准避坑线程泄漏的本质是“线程生命周期管理不当”以下3个原因是实际开发中最常见的一定要重点规避。线程未正确中断线程在while(true)等无限循环中运行未设置退出条件导致线程永久存活无法被回收。比如一个后台线程用于定时执行任务但未设置停止标记程序退出时线程依然在运行。线程池未关闭程序退出时未调用线程池的shutdown()或shutdownNow()方法线程池的核心线程会一直存活长期占用资源。尤其是临时创建的线程池更容易出现这种问题。阻塞操作无超时线程因Object.wait()、Condition.await()、Thread.sleep(Long.MAX_VALUE)等操作进入永久阻塞状态无法被唤醒也无法被回收。3.2 线程泄漏的定位手段及时发现避免崩溃线程泄漏的核心特征是“线程数量持续增长”因此定位线程泄漏主要是监控线程数量变化结合线程栈信息找到泄漏的线程。1jstack统计线程数量通过jstack PID生成线程快照统计线程总数。如果线程数量随着时间推移持续增长且没有上限说明存在线程泄漏。实战技巧定期执行jstack命令记录线程数量变化绘制趋势图。如果线程数量呈线性增长即可确认存在泄漏。2监控线程创建速率使用JMXJava Management Extensions监控线程创建速率和销毁速率。当线程创建速率长期高于销毁速率时线程数量会持续增加提示存在线程泄漏。也可以通过监控工具如Prometheus配置线程数量告警当线程数量超过阈值时及时提醒开发者排查。3分析线程状态泄漏的线程通常处于两种状态一是RUNNABLE状态无限循环一直在执行二是WAITING状态永久阻塞无法唤醒。结合jstack输出的线程栈信息可定位到泄漏的代码行。示例如果线程栈中显示某线程一直在执行while(true)循环且没有退出条件说明该线程存在泄漏。3.3 线程泄漏的解决策略规范管理杜绝泄漏解决线程泄漏的核心是“规范线程生命周期管理”确保线程创建后能在合适的时机正常终止释放资源。1为线程设置退出条件对于循环运行的线程添加退出标记如volatile修饰的boolean变量在程序退出或不需要该线程时将标记设为false让线程正常终止。实战代码示例public class ThreadLeakDemo { // 退出标记volatile保证可见性 private volatile boolean running true; public void startThread() { new Thread(() - { // 循环条件running为true时继续执行 while (running) { try { // 业务逻辑如定时任务 Thread.sleep(1000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); break; // 中断后退出循环 } } System.out.println(线程正常终止释放资源); }, 后台任务线程).start(); } // 停止线程的方法 public void stopThread() { running false; // 设置退出标记让线程退出循环 } }2正确关闭线程池程序退出时必须调用线程池的shutdown()或shutdownNow()方法确保线程池中的线程正常终止资源被回收。对于临时创建的线程池可使用try-with-resources语法自动关闭线程池。实战代码示例// 方式1手动关闭线程池 ExecutorService executor Executors.newFixedThreadPool(5); try { // 提交任务 executor.submit(() - { /* 业务逻辑 */ }); } finally { // 程序退出时关闭线程池 executor.shutdown(); // 等待所有任务执行完成后关闭 // 若需强制关闭可使用executor.shutdownNow(); } // 方式2try-with-resources自动关闭Java 7 try (ExecutorService executor Executors.newFixedThreadPool(5)) { executor.submit(() - { /* 业务逻辑 */ }); } // 自动调用shutdown()方法关闭线程池3为阻塞操作设置超时避免使用无超时的阻塞方法改用带超时的重载方法防止线程永久阻塞。比如将Object.wait()改为wait(long timeout)将Condition.await()改为await(long timeout, TimeUnit unit)。示例// 优化前无超时可能永久阻塞 synchronized (lock) { lock.wait(); // 无超时若未被notify()线程会永久阻塞 } // 优化后设置超时时间1秒超时后自动唤醒 synchronized (lock) { lock.wait(1000); // 超时1秒后线程自动唤醒避免永久阻塞 }四、总结并发编程问题排查与优化的核心逻辑Java并发编程的核心是“平衡效率与安全”而死锁、线程竞争、线程泄漏正是破坏这种平衡的三大核心问题。通过本文的梳理我们可以总结出一套通用的排查与优化逻辑定位问题结合jstack、VisualVM、AsyncProfiler等工具从线程状态、锁持有情况、CPU耗时等维度精准找到问题根源死锁的循环等待、线程竞争的热点锁、线程泄漏的未终止线程。解决问题针对不同问题采取差异化策略——死锁重点破坏循环等待、持有并等待条件线程竞争重点减少锁竞争强度线程泄漏重点规范线程生命周期管理。预防问题前期设计阶段合理拆分资源、控制锁范围、规范线程和线程池管理线上环境结合监控工具提前预警将并发问题消灭在萌芽状态。并发编程的学习没有捷径需要不断实践、不断踩坑、不断总结。熟练掌握本文介绍的工具和策略能帮你快速应对大部分并发问题编写高效、稳定的并发程序。最后欢迎在评论区留言分享你在并发编程中遇到的坑和排查经验一起交流学习共同进步
并发编程常见问题排查与解决：从死锁到线程竞争的实战指南
发布时间：2026/5/20 18:03:12
在高并发场景下Java并发编程是提升系统吞吐量和响应速度的核心手段但随之而来的死锁、线程竞争、线程泄漏等问题却常常让开发者陷入困境。这些问题大多具有偶发性、隐蔽性强的特点线下测试难以复现线上出现时又会直接影响业务可用性甚至导致系统崩溃。今天就结合实际开发案例系统梳理并发编程中最常见的三类问题从原理、定位到解决手把手教你快速排查高效修复让你的并发程序既高效又稳定。本文原创发布于2025-08-06收录于《Java 并发编程全解原理、实战与面试攻略》专栏全文基于真实项目实战总结代码可直接运行欢迎收藏转发一起交流学习一、死锁线程间的无限等待陷阱业务停滞的“致命杀手”死锁是并发编程中最经典、最危险的问题之一没有之一。它指的是两个或多个线程相互持有对方所需的资源且都不愿意主动释放最终导致所有相关线程永久阻塞业务完全停滞只能通过重启服务才能恢复。在高并发的支付、订单系统中死锁一旦发生可能直接造成经济损失因此必须提前预防、快速定位。1.1 死锁的4个必要条件缺一不可破坏其一即可避免死锁的产生并非偶然必须同时满足以下4个条件只要破坏其中任意一个就能从根本上杜绝死锁。很多开发者在排查死锁时无从下手核心就是没有吃透这4个条件无法精准定位问题根源。互斥条件资源具有排他性只能被一个线程持有无法被多个线程同时占用。比如Java中的synchronized锁、ReentrantLock都是典型的互斥资源。持有并等待线程已经持有了部分资源同时又在等待其他线程持有的资源且在等待过程中不释放自己已持有的资源。这是死锁产生的核心诱因之一。不可剥夺线程持有的资源只能由线程自身主动释放无法被其他线程强制剥夺。比如一个线程持有synchronized锁后其他线程只能等待它释放无法强行抢占。循环等待多个线程之间形成了相互等待资源的环形链比如线程A等待线程B的资源线程B等待线程C的资源线程C等待线程A的资源形成闭环。1.2 死锁实战示例可直接运行复现死锁场景下面这个案例模拟了实际开发中最常见的死锁场景两个线程相互获取对方持有的锁最终导致永久阻塞。大家可以复制代码运行直观感受死锁的现象。public class DeadLockDemo { // 定义两个互斥锁资源模拟实际开发中的两个资源如订单锁、库存锁 private static final Object LOCK_A new Object(); private static final Object LOCK_B new Object(); public static void main(String[] args) { // 线程1先获取LOCK_A订单锁再尝试获取LOCK_B库存锁 new Thread(() - { synchronized (LOCK_A) { System.out.println(线程1获取到订单锁LOCK_A等待库存锁LOCK_B...); try { // 模拟业务处理耗时放大死锁概率实际开发中可能是查询、计算等操作 Thread.sleep(100); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } // 此时线程1持有LOCK_A等待LOCK_B synchronized (LOCK_B) { System.out.println(线程1获取到库存锁LOCK_B执行订单创建库存扣减完成); } } }, 订单处理线程).start(); // 线程2先获取LOCK_B库存锁再尝试获取LOCK_A订单锁 new Thread(() - { synchronized (LOCK_B) { System.out.println(线程2获取到库存锁LOCK_B等待订单锁LOCK_A...); try { Thread.sleep(100); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } // 此时线程2持有LOCK_B等待LOCK_A形成循环等待 synchronized (LOCK_A) { System.out.println(线程2获取到订单锁LOCK_A执行库存扣减订单确认完成); } } }, 库存处理线程).start(); } }运行结果线程1获取到订单锁LOCK_A等待库存锁LOCK_B... 线程2获取到库存锁LOCK_B等待订单锁LOCK_A...程序会永久阻塞没有后续输出此时死锁已经发生。如果这是线上环境订单和库存相关的业务会完全停滞用户无法下单、无法支付影响极大。1.3 死锁定位3大利器实战必备快速定位问题死锁发生后核心是快速定位哪个线程、持有哪些资源、等待哪些资源。下面这3个工具是Java开发者排查死锁的必备技能从命令行到图形化覆盖不同场景需求。1jstack命令命令行首选快速检测死锁jstack是JDK自带的命令行工具无需额外安装可直接生成Java进程的线程快照并且能自动检测死锁适合线上服务器无图形化界面排查。操作步骤实战分步讲解执行jps命令获取目标Java进程的PID进程ID。比如运行上面的DeadLockDemo后执行jps会输出类似内容jps # 输出示例12345为进程PIDDeadLockDemo为进程名称 12345 DeadLockDemo 9876 Jps执行jstack -l PID生成线程快照-l参数用于显示线程的详细信息包括锁持有情况jstack -l 12345死锁检测关键片段Found one Java-level deadlock: 库存处理线程: waiting to lock monitor 0x00007f8a1c006000 (object 0x000000076b6a6690, a java.lang.Object), which is held by 订单处理线程 订单处理线程: waiting to lock monitor 0x00007f8a1c008c00 (object 0x000000076b6a66a0, a java.lang.Object), which is held by 库存处理线程 Java stack information for the threads listed above: 库存处理线程: at DeadLockDemo.lambda$main$1(DeadLockDemo.java:25) - waiting to lock 0x000000076b6a6690 (a java.lang.Object) # 等待的锁 - locked 0x000000076b6a66a0 (a java.lang.Object) # 已持有的锁 at DeadLockDemo$$Lambda$2/1078694789.run(Unknown Source) at java.lang.Thread.run(Thread.java:748) 订单处理线程: at DeadLockDemo.lambda$main$0(DeadLockDemo.java:14) - waiting to lock 0x000000076b6a66a0 (a java.lang.Object) # 等待的锁 - locked 0x000000076b6a6690 (a java.lang.Object) # 已持有的锁 at DeadLockDemo$$Lambda$1/1324119927.run(Unknown Source) at java.lang.Thread.run(Thread.java:748) Found 1 deadlock.分析jstack会明确标记“Found 1 deadlock”并列出死锁的线程名称、等待的锁和已持有的锁一目了然能快速定位到死锁的代码行如上面的第14行、第25行。2VisualVM图形化工具直观易懂如果是本地开发、测试环境VisualVM会更方便它是JDK自带的可视化监控工具支持线程监控、死锁检测、内存分析等功能操作简单适合非命令行用户。操作步骤启动VisualVM在命令行输入jvisualvm即可启动工具无需额外配置。连接目标进程在左侧“应用程序”列表中找到运行的DeadLockDemo进程双击连接。检测死锁切换到“线程”标签页点击右上角的“检测死锁”按钮工具会自动分析线程状态弹出死锁详情窗口清晰展示线程持有和等待的锁关系。优势图形化界面直观无需分析复杂的命令行输出适合快速排查本地开发中的死锁问题尤其适合新手。3日志与监控提前预警防患于未然死锁往往是偶发性的线上环境可能几天、几个月才出现一次等出现时已经造成损失。因此提前监控、日志追踪才能在死锁发生前预警减少损失。实战技巧在锁的获取和释放处打印详细日志追踪线程的锁操作轨迹。比如// 增强锁操作日志便于追踪线程行为 synchronized (LOCK_A) { log.info(线程{}获取到订单锁LOCK_A当前时间{}, Thread.currentThread().getName(), LocalDateTime.now()); try { // 业务逻辑 } finally { log.info(线程{}释放订单锁LOCK_A当前时间{}, Thread.currentThread().getName(), LocalDateTime.now()); } }结合监控系统如PrometheusGrafana监控锁等待时间。当某个锁的等待时间超过阈值如1秒时触发告警提醒开发者及时排查避免死锁发生。1.4 死锁的解决与预防策略实战落地杜绝死锁排查死锁的最终目的是解决和预防结合前面的4个死锁条件我们可以针对性地破坏其中一个或多个条件从根本上杜绝死锁。下面这3个策略是实际开发中最常用、最易落地的方案。1破坏循环等待统一锁获取顺序最推荐无侵入死锁的核心是“循环等待”只要规定所有线程按相同的顺序获取锁就能打破环形链从根本上避免死锁。这是最推荐的方案代码侵入性低易于维护。修改示例将前面的死锁代码修改为“统一按LOCK_A→LOCK_B的顺序获取锁”// 线程1按LOCK_A→LOCK_B顺序获取不变 synchronized (LOCK_A) { System.out.println(线程1获取到订单锁LOCK_A等待库存锁LOCK_B...); synchronized (LOCK_B) { System.out.println(线程1获取到库存锁LOCK_B执行完成); } } // 线程2修改为按LOCK_A→LOCK_B顺序获取原逻辑修改 synchronized (LOCK_A) { System.out.println(线程2获取到订单锁LOCK_A等待库存锁LOCK_B...); synchronized (LOCK_B) { System.out.println(线程2获取到库存锁LOCK_B执行完成); } }原理此时两个线程都先获取LOCK_A再获取LOCK_B不会形成循环等待。即使线程1先获取到LOCK_A线程2会等待LOCK_A释放不会出现相互等待的情况。实战注意实际开发中锁的顺序可以按资源的唯一标识如订单ID、库存ID排序确保所有线程都按相同顺序获取锁。比如多个线程操作不同的订单和库存时按订单ID的大小顺序获取锁。2破坏持有并等待使用tryLock()避免无限等待synchronized锁是不可中断的一旦线程等待锁就会一直阻塞直到获取到锁。而ReentrantLock提供的tryLock(long timeout, TimeUnit unit)方法可在超时后放弃获取锁并释放已持有的资源打破“持有并等待”条件避免永久阻塞。实战代码示例import java.util.concurrent.TimeUnit; import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; public class TryLockDemo { private static final Lock LOCK_A new ReentrantLock(); // 订单锁 private static final Lock LOCK_B new ReentrantLock(); // 库存锁 public static void main(String[] args) { new Thread(() - { try { // 尝试获取LOCK_A超时时间1秒 if (LOCK_A.tryLock(1, TimeUnit.SECONDS)) { try { System.out.println(线程1获取到订单锁LOCK_A等待库存锁LOCK_B...); // 尝试获取LOCK_B超时时间1秒 if (LOCK_B.tryLock(1, TimeUnit.SECONDS)) { try { System.out.println(线程1获取到库存锁LOCK_B执行完成); } finally { LOCK_B.unlock(); // 释放LOCK_B } } else { System.out.println(线程1获取库存锁LOCK_B超时释放订单锁LOCK_A); } } finally { LOCK_A.unlock(); // 释放LOCK_A } } else { System.out.println(线程1获取订单锁LOCK_A超时放弃执行); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); // 恢复中断状态 } }, 订单处理线程).start(); // 线程2逻辑类似略同样使用tryLock()超时后释放资源 } }优势线程不会无限等待锁超时后会主动释放已持有的资源避免死锁。同时还能通过超时日志及时发现锁竞争激烈的问题提前优化。3破坏持有并等待减少锁持有时间锁持有时间越长线程等待的时间就越长死锁的概率也就越高。通过缩小同步代码块的范围只在核心业务逻辑处持有锁减少锁的占用时间可大幅降低死锁风险。优化对比// 优化前锁持有时间长包含无关操作如读数据、写日志 synchronized (lock) { readData(); // 耗时操作无需加锁 processData(); // 核心逻辑需要加锁 writeLog(); // 无关操作无需加锁 } // 优化后仅在核心逻辑处持有锁减少锁持有时间 readData(); // 锁外执行无需加锁 synchronized (lock) { processData(); // 核心逻辑仅此处加锁 } writeLog(); // 锁外执行无需加锁实战注意优化时要注意核心逻辑必须是原子操作不能拆分到锁外否则会出现线程安全问题如数据不一致。二、线程竞争与资源争用性能损耗的隐形杀手系统卡顿的根源如果说死锁是“致命伤”那么线程竞争就是“慢性病”——它不会导致系统立即崩溃但会导致系统响应缓慢、CPU利用率异常、吞吐量下降长期下去会严重影响用户体验。线程竞争指的是多个线程同时争夺同一资源如锁、CPU、内存导致线程频繁阻塞、上下文切换大量CPU资源被消耗在调度上而非业务处理上。2.1 线程竞争的典型表现快速识别精准判断线上系统出现以下症状时大概率是存在线程竞争问题需要及时排查CPU利用率很高接近100%但业务吞吐量很低响应时间很长如接口响应时间从100ms飙升到1s以上。通过jstack查看线程状态发现大量线程处于BLOCKED阻塞或WAITING等待状态且都是因为争夺同一把锁。系统响应时间波动大时而正常时而卡顿尤其是在高并发峰值时段。示例场景一个电商秒杀系统1000个线程同时竞争一个库存锁导致999个线程处于BLOCKED状态CPU大部分时间用于线程调度上下文切换而非库存扣减、订单创建等核心业务最终导致秒杀接口响应缓慢大量用户下单失败。核心原因锁竞争激烈导致大量线程阻塞等待上下文切换频繁一次上下文切换耗时约1-10微秒高并发下累计耗时惊人消耗大量CPU资源。2.2 线程竞争的定位手段精准找到热点锁对症下药线程竞争的核心是“热点锁”——某一把锁被大量线程争夺。定位线程竞争本质就是找到这把热点锁以及对应的代码然后针对性优化。下面这3种手段覆盖从简单到复杂的排查场景。1jstacktop命令快速定位热点锁结合jstack和top命令可快速统计阻塞线程的数量和原因定位热点锁。操作步骤用top -H -p PID查看目标进程的线程CPU占用情况找到CPU占用高的线程IDLWP。用jstack PID生成线程快照将线程IDLWP转换为十六进制jstack输出的线程ID是十六进制找到对应的线程栈信息。统计阻塞线程的数量如果大量线程因同一把锁处于BLOCKED状态说明该锁是热点锁。jstack线程状态关键片段线程-999 #1000 prio5 os_prio31 tid0x00007f8a1d000000 nid0x1a03 waiting for monitor entry [0x000070000f9f6000] java.lang.Thread.State: BLOCKED (on object monitor) at CompetitionDemo.lambda$main$0(CompetitionDemo.java:10) - waiting to lock 0x000000076b6a66b0 (a java.lang.Object) # 大量线程等待同一把锁 at CompetitionDemo$$Lambda$1/1324119927.run(Unknown Source) at java.lang.Thread.run(Thread.java:748)分析大量线程等待0x000000076b6a66b0这把锁说明该锁是热点锁对应的代码行是CompetitionDemo.java第10行需要重点优化。2jconsole监控实时查看锁竞争情况jconsole是JDK自带的监控工具可实时查看线程状态和锁信息适合监控锁竞争的实时情况。操作步骤启动jconsole连接目标进程。切换到“线程”标签页查看线程状态分布BLOCKED、RUNNABLE、WAITING的线程数量。切换到“VM概要”标签页观察“总锁获取数”“锁争用数”两个关键指标。关键指标解读锁争用率 锁争用数 / 总锁获取数锁争用率越高说明锁竞争越激烈。一般来说锁争用率超过50%就需要优化了。3性能分析工具定位热点方法深入排查对于复杂的系统仅靠jstack和jconsole可能无法精准定位热点锁对应的业务方法此时需要使用专业的性能分析工具生成火焰图直观展示锁等待在CPU耗时中的占比。常用工具AsyncProfiler轻量级性能分析工具可生成CPU火焰图直观展示各个方法的CPU耗时占比。如果Object.wait()、ReentrantLock.lock()等方法在火焰图中占比很高说明锁竞争是性能瓶颈。VisualVM抽样器通过CPU抽样定位因锁竞争导致的热点方法适合本地开发、测试环境排查。火焰图解读技巧火焰图的横轴是方法调用栈纵轴是调用深度颜色越深代表CPU耗时越长。如果某一个锁相关的方法如lock()、wait()占据了大量的横轴空间说明该方法是热点对应的锁竞争激烈。2.3 线程竞争的解决策略实战优化提升性能解决线程竞争的核心思路是“减少锁的竞争强度”——要么减少争夺同一把锁的线程数量要么避免使用锁具体可根据业务场景选择以下策略。1减少锁粒度拆分资源降低竞争将一个大锁拆分为多个小锁让不同的线程争夺不同的小锁从而减少单个锁的竞争强度。这是实际开发中最常用的优化方案典型案例是ConcurrentHashMap的分段锁JDK7及之前。实战代码示例拆分锁优化// 优化前单锁竞争激烈所有线程争夺同一把锁适合低并发 class BigCache { private final Object lock new Object(); private final MapString, Object cache new HashMap(); public void put(String key, Object value) { synchronized (lock) { // 所有线程竞争同一把锁 cache.put(key, value); } } } // 优化后多锁拆分降低竞争适合高并发 class SplitCache { private static final int SEGMENTS 16; // 拆分16个段对应16把锁 private final Object[] locks new Object[SEGMENTS]; private final MapString, Object[] segments new Map[SEGMENTS]; public SplitCache() { // 初始化每段的锁和缓存 for (int i 0; i SEGMENTS; i) { locks[i] new Object(); segments[i] new HashMap(); } } public void put(String key, Object value) { // 按key的哈希值分配到不同的段确保同一key始终落在同一段 int segment Math.abs(key.hashCode() % SEGMENTS); synchronized (locks[segment]) { // 仅竞争该段的锁竞争强度降低16倍 segments[segment].put(key, value); } } }优势拆分后多个线程可以同时操作不同段的缓存无需争夺同一把锁锁竞争强度大幅降低系统吞吐量显著提升。实战注意拆分的段数不宜过多一般等于CPU核心数或2的幂否则会增加锁管理的开销同时要确保同一资源始终落在同一锁下避免数据不一致。2使用无锁数据结构避免锁竞争对于读多写少、或可容忍短暂数据不一致的场景使用无锁数据结构可彻底避免锁竞争提升并发性能。Java并发包中提供了多种无锁数据结构如AtomicInteger、AtomicLong、ConcurrentLinkedQueue等其底层基于CAS比较并交换机制实现无需加锁。实战示例无锁计数器// 优化前锁竞争导致性能低适合低并发计数 class SyncCounter { private int count 0; // 所有线程争夺同一把锁高并发下性能差 public synchronized void increment() { count; } } // 优化后无锁操作支持高并发适合高并发计数 class AtomicCounter { // AtomicInteger底层基于CAS机制无锁操作 private final AtomicInteger count new AtomicInteger(0); public void increment() { count.incrementAndGet(); } // 无锁原子操作 }优势无锁操作无需线程阻塞等待上下文切换少CPU利用率高适合高并发场景如秒杀计数、接口访问量统计。注意事项无锁结构适合简单的原子操作如计数、赋值复杂的业务逻辑如多步操作不适合使用否则会出现数据不一致问题。3读写锁分离读多写少场景的最优解很多业务场景都是“读多写少”如商品详情查询、用户信息查询此时使用ReentrantReadWriteLock读写锁可实现“读共享、写独占”大幅降低锁竞争。读线程之间不互斥可同时访问写线程与读线程、写线程与写线程互斥确保数据一致性。实战代码示例class ReadHeavyCache { // 读写锁读锁共享写锁独占 private final ReadWriteLock rwLock new ReentrantReadWriteLock(); private final Lock readLock rwLock.readLock(); // 读锁 private final Lock writeLock rwLock.writeLock(); // 写锁 private final MapString, Object cache new HashMap(); // 读操作共享锁多个读线程可同时执行 public Object get(String key) { readLock.lock(); try { return cache.get(key); } finally { readLock.unlock(); // 释放读锁 } } // 写操作独占锁仅一个写线程执行读线程需等待 public void put(String key, Object value) { writeLock.lock(); try { cache.put(key, value); } finally { writeLock.unlock(); // 释放写锁 } } }优势读多写少场景下多个读线程可同时访问无需等待大幅提升读性能写操作独占锁确保数据一致性兼顾性能和安全性。4合理设置线程池参数减少资源竞争线程池参数不合理会加剧线程竞争和上下文切换。比如核心线程数过多会导致CPU调度压力增大上下文切换频繁核心线程数过少会导致大量任务排队线程阻塞等待。因此需根据任务类型CPU密集型、IO密集型合理设置线程池参数。实战参数建议CPU密集型任务如计算、排序核心线程数 CPU核心数 ± 1。因为CPU密集型任务主要消耗CPU资源线程数过多会导致上下文切换频繁反而降低性能。IO密集型任务如数据库查询、网络请求核心线程数 CPU核心数 × 2或更高。因为IO密集型任务中线程大部分时间都在等待IO操作完成如等待数据库返回结果此时多设置线程数可提高CPU利用率。注意实际开发中可通过监控线程池的任务排队数、线程空闲时间动态调整线程池参数达到最优性能。三、线程泄漏资源耗尽的隐形推手系统崩溃的“定时炸弹”线程泄漏是容易被忽视但危害极大的并发问题。它指的是线程创建后未正常终止长期占用内存、线程池等系统资源随着时间推移资源被逐渐耗尽最终导致系统抛出OutOfMemoryError无法创建新线程系统崩溃。线程泄漏的隐蔽性很强线下测试很难发现往往在系统运行一段时间后如几天、几周才会爆发排查难度较大。3.1 线程泄漏的3个常见原因精准避坑线程泄漏的本质是“线程生命周期管理不当”以下3个原因是实际开发中最常见的一定要重点规避。线程未正确中断线程在while(true)等无限循环中运行未设置退出条件导致线程永久存活无法被回收。比如一个后台线程用于定时执行任务但未设置停止标记程序退出时线程依然在运行。线程池未关闭程序退出时未调用线程池的shutdown()或shutdownNow()方法线程池的核心线程会一直存活长期占用资源。尤其是临时创建的线程池更容易出现这种问题。阻塞操作无超时线程因Object.wait()、Condition.await()、Thread.sleep(Long.MAX_VALUE)等操作进入永久阻塞状态无法被唤醒也无法被回收。3.2 线程泄漏的定位手段及时发现避免崩溃线程泄漏的核心特征是“线程数量持续增长”因此定位线程泄漏主要是监控线程数量变化结合线程栈信息找到泄漏的线程。1jstack统计线程数量通过jstack PID生成线程快照统计线程总数。如果线程数量随着时间推移持续增长且没有上限说明存在线程泄漏。实战技巧定期执行jstack命令记录线程数量变化绘制趋势图。如果线程数量呈线性增长即可确认存在泄漏。2监控线程创建速率使用JMXJava Management Extensions监控线程创建速率和销毁速率。当线程创建速率长期高于销毁速率时线程数量会持续增加提示存在线程泄漏。也可以通过监控工具如Prometheus配置线程数量告警当线程数量超过阈值时及时提醒开发者排查。3分析线程状态泄漏的线程通常处于两种状态一是RUNNABLE状态无限循环一直在执行二是WAITING状态永久阻塞无法唤醒。结合jstack输出的线程栈信息可定位到泄漏的代码行。示例如果线程栈中显示某线程一直在执行while(true)循环且没有退出条件说明该线程存在泄漏。3.3 线程泄漏的解决策略规范管理杜绝泄漏解决线程泄漏的核心是“规范线程生命周期管理”确保线程创建后能在合适的时机正常终止释放资源。1为线程设置退出条件对于循环运行的线程添加退出标记如volatile修饰的boolean变量在程序退出或不需要该线程时将标记设为false让线程正常终止。实战代码示例public class ThreadLeakDemo { // 退出标记volatile保证可见性 private volatile boolean running true; public void startThread() { new Thread(() - { // 循环条件running为true时继续执行 while (running) { try { // 业务逻辑如定时任务 Thread.sleep(1000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); break; // 中断后退出循环 } } System.out.println(线程正常终止释放资源); }, 后台任务线程).start(); } // 停止线程的方法 public void stopThread() { running false; // 设置退出标记让线程退出循环 } }2正确关闭线程池程序退出时必须调用线程池的shutdown()或shutdownNow()方法确保线程池中的线程正常终止资源被回收。对于临时创建的线程池可使用try-with-resources语法自动关闭线程池。实战代码示例// 方式1手动关闭线程池 ExecutorService executor Executors.newFixedThreadPool(5); try { // 提交任务 executor.submit(() - { /* 业务逻辑 */ }); } finally { // 程序退出时关闭线程池 executor.shutdown(); // 等待所有任务执行完成后关闭 // 若需强制关闭可使用executor.shutdownNow(); } // 方式2try-with-resources自动关闭Java 7 try (ExecutorService executor Executors.newFixedThreadPool(5)) { executor.submit(() - { /* 业务逻辑 */ }); } // 自动调用shutdown()方法关闭线程池3为阻塞操作设置超时避免使用无超时的阻塞方法改用带超时的重载方法防止线程永久阻塞。比如将Object.wait()改为wait(long timeout)将Condition.await()改为await(long timeout, TimeUnit unit)。示例// 优化前无超时可能永久阻塞 synchronized (lock) { lock.wait(); // 无超时若未被notify()线程会永久阻塞 } // 优化后设置超时时间1秒超时后自动唤醒 synchronized (lock) { lock.wait(1000); // 超时1秒后线程自动唤醒避免永久阻塞 }四、总结并发编程问题排查与优化的核心逻辑Java并发编程的核心是“平衡效率与安全”而死锁、线程竞争、线程泄漏正是破坏这种平衡的三大核心问题。通过本文的梳理我们可以总结出一套通用的排查与优化逻辑定位问题结合jstack、VisualVM、AsyncProfiler等工具从线程状态、锁持有情况、CPU耗时等维度精准找到问题根源死锁的循环等待、线程竞争的热点锁、线程泄漏的未终止线程。解决问题针对不同问题采取差异化策略——死锁重点破坏循环等待、持有并等待条件线程竞争重点减少锁竞争强度线程泄漏重点规范线程生命周期管理。预防问题前期设计阶段合理拆分资源、控制锁范围、规范线程和线程池管理线上环境结合监控工具提前预警将并发问题消灭在萌芽状态。并发编程的学习没有捷径需要不断实践、不断踩坑、不断总结。熟练掌握本文介绍的工具和策略能帮你快速应对大部分并发问题编写高效、稳定的并发程序。最后欢迎在评论区留言分享你在并发编程中遇到的坑和排查经验一起交流学习共同进步
