Java并发编程实战：从线程状态到线程池的避坑指南

1. 为什么JavaSE系列到第十一篇才进入并发先说说前置积累1.1 并发不是新语法而是一种新的思考方式写这个系列写到现在前面十篇基本都在处理单线程世界的事你自己写好的代码按顺序执行一个方法返回了再进下一个方法程序员的直觉总是线性的。但真实的业务系统几乎不可能一直单线程。你写一个报表导出接口用户一点按钮几万行数据要查库、要写Excel如果全放在一次请求里同步去做前端界面会一直转圈最后超时你写一个定时对账任务上游推过来几万个文件一个一个处理要跑到天亮你给系统做了缓存预热发现每次重启后第一次访问还是慢慢吞吞因为加载是顺序的不能并行拉取。这些场景里的共同答案就一个并发。所以我才会把并发放到第十一篇。并不是因为它是压轴知识点而是因为它依赖前面很多东西你得知道HashMap在多线程下会出什么问题才能理解为什么并发容器必要你得知道异常怎么传播才能排查线程池里消失的异常你得对IO、集合、泛型有手感才能判断一段逻辑哪些部分可以并行、哪些部分必须串行。这些铺垫没到位直接看并发很容易变成背面试题。1.2 先补上并发编程要解决的三个问题很多人以为并发难在API多、调用复杂其实API只有那么几个。真正难的是并发引入了三个单线程编程里根本不存在的变量原子性、可见性、有序性。原子性比较好理解就是一个操作不可以被中途打断。经典例子就是i你写的是读-加-写三步但在两个线程同时执行时可能两个线程都读到了旧值1分别加1写回去最后结果是2而不是3。可见性更像缓存与内存之间的信息差。每个线程在CPU核上运行时并不总是直接读写主内存它可能把共享变量复制到工作内存里改完之后还没同步回主内存另一个线程读到的永远是旧值。结果就是你明明改了状态别的线程却看不到。有序性更隐蔽。CPU和编译器为了性能会对指令重排单线程下重排不影响结果一旦多线程共享数据重排可能导致一个线程看到的执行顺序和代码顺序完全不一样。这三个问题不是背概念是你查线上并发Bug时真正要去对照的。所有并发工具无论synchronized、volatile、Lock、原子类本质都在解决这三者中的某一个或某几个。这篇后面每一节都会对应回这三个问题来说明。2. 线程状态迁移从创建到终结每个状态背后都有一堆坑2.1 六种状态与它们之间的转移条件Java把线程生命周期定为六种状态对应java.lang.Thread.State枚举。我先给个总表然后挑容易搞错的地方展开。状态说明进入条件退出方式NEW创建了Thread对象还没startnew Thread()调用start()RUNNABLE可运行/正在运行等待CPU时间片start()后或从等待中唤醒获得CPU进入执行执行结束BLOCKED阻塞在synchronized锁上等待监视器尝试进入同步块但锁被其他线程持有获取到锁WAITING无限期等待必须由其他线程显式唤醒wait()、join()、LockSupport.park()notify()、notifyAll()、目标线程结束TIMED_WAITING带时限的等待sleep(ms)、wait(timeout)、join(ms)时间到或被唤醒TERMINATED执行完或异常退出run()返回或抛出未捕获异常无我最常看到的一个误解是把sleep中的线程说成阻塞状态。严格来说它是TIMED_WAITING不持有任何锁也没关系CPU时间片让出去了但锁如果持有着还继续拿着。这个区分在排查死锁和性能问题时非常有用看线程dumpjava.lang.Thread.State: TIMED_WAITING (sleeping)和BLOCKED (on object monitor)代表完全不同的情况。另一个细节RUNNABLE状态在JVM里并不区分正在CPU上执行和在就绪队列里排队。所以你看一个线程长时间停在RUNNABLE不代表它一直在运行可能它只是大量占着CPU时间在算也可能是GC线程把它压住了。用一段小代码就能把状态变化打印得很直观Thread t new Thread(() - { try { Thread.sleep(500); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }); System.out.println(t.getState()); // NEW t.start(); System.out.println(t.getState()); // RUNNABLE通常如此 Thread.sleep(100); System.out.println(t.getState()); // TIMED_WAITING t.join(); System.out.println(t.getState()); // TERMINATED2.2 sleep、wait、join、yield到底谁让出CPU这几个方法表面上都是停下来等一等但语义完全不同很多人用错是因为只记住了让线程歇一下。Thread.sleep是纯延时它不释放已经持有的锁。所以你在同步块里写sleep(10)想让其他线程趁这个空隙进来拿锁是没用的锁还在你手里其他线程只能继续BLOCKED。Object.wait则完全不同。调用wait的前提是你已经持有了该对象的监视器也就是处在synchronized块或方法内。wait执行后当前线程释放锁并进入该对象的等待集直到另一个线程调用同一个对象的notify或notifyAll唤醒它。唤醒后它重新竞争锁。这就是等待/通知机制也是线程间协作最原始的手段。join是让当前线程进入WAITING/TIMED_WAITING直到目标线程结束。它底层其实也是基于wait做的。很多人用sleep(1000)去等另一个线程跑完这是最典型的负面写法你无法保证1秒内对方跑完也无法提前结束等待。正解是thread.join()。yield是最容易混淆的。它只是向线程调度器发出一个让出执行机会的提示线程从RUNNABLE回到RUNNABLE但调度器完全不理会也是合法的。它几乎不用于业务代码某些锁的自旋优化里可能出现。一句话总结sleep是暂停倒计时wait是放弃锁等待信号join是等对方跑完yield是礼貌让一下但不保证。3. 数据安全边界从可见性到synchronized与锁升级3.1 JMM与volatile让一个共享变量被看见Java内存模型JMM描述的是线程之间如何通过内存交互核心规则就是每个线程有自己的工作内存变量的读写都先落到工作内存再同步到主内存。这模型是为了在多核CPU上获得性能但它直接带来了可见性问题。volatile关键字的两个作用一是保证一个线程的修改对其他线程立即可见二是禁止指令重排。注意它不保证原子性。经典的可见性bug如下class FlagHolder { volatile boolean flag true; } public class StopDemo { public static void main(String[] args) throws InterruptedException { FlagHolder holder new FlagHolder(); Thread worker new Thread(() - { long count 0; while (holder.flag) { count; } System.out.println(stopped, count count); }); worker.start(); Thread.sleep(200); holder.flag false; // 不加volatileworker可能永远看不到 worker.join(); } }如果flag不加volatile这个程序长期跑很可能停不下来因为worker线程在自己的工作内存里缓存了旧值。加了volatile之后主线程的修改会立即同步到主内存worker线程每次判定时也能拿到最新值循环才能退出。但你要清醒volatile解决不了抢锁问题。两个线程同时对同一个volatile变量做i结果还是可能丢更新因为i不是一步操作。所以volatile的典型用法是一个线程写多个线程读的状态开关不是计数器。3.2 synchronized的锁升级JVM对性能的现实妥协synchronized在以前被叫作重量级锁很多老代码里能用单例就不用它生怕性能被拖垮。但现代JDK里synchronized已经做了大量优化其中最核心的就是锁升级偏向锁 - 轻量级锁 - 重量级锁。实现这些优化的地方在对象头的Mark Word里。每个Java对象头部有一段标记数据记录当前锁的状态锁状态主要机制适用场景无锁无同步无竞争偏向锁在Mark Word记录持有线程ID重入不再CAS同一个线程反复进入同步块轻量级锁通过CAS抢占Mark Word指针少量线程短时间交替竞争重量级锁由操作系统互斥量支持未抢到线程阻塞大量线程长时间竞争偏向锁的思路很取巧大多数同步块在整个生命周期里只有一个线程访问那何必每次进都做CAS直接把线程ID写进Mark Word这个线程再次进来时比对一下一致就直接通过。如果有另一个线程来竞争偏向锁才撤销并升级。轻量级锁则是用CAS去抢对象头的锁记录指针抢到的线程保持运行抢不到的进入自旋或阻塞。锁竞争更激烈时就膨胀成重量级锁未抢到的线程在操作系统的锁队列里睡眠等释放时再唤醒。线程阻塞唤醒涉及用户态和内核态切换所以才重。我在实际调优中最大的体会是别一上来就想要不要换Lock先查是不是真在锁上有大量竞争。很多服务是IO密集锁只保护很小一段操作用同步synchronized就够了。锁升级是自动的但也意味着一旦频繁竞争它最终会走到最重的档位所以核心是减少临界区的请求量而不是折腾锁实现。3.3 我见过最隐蔽的锁失效问题可变锁对象有一个问题面试很少问但工作里特别容易踩用来充当锁的对象必须稳定且固定。我在一次排查你看我明明加锁了数据还是乱了的案例时发现有人这么写private Integer lock 0; public void add() { synchronized (lock) { count; } }问题在于如果代码里有lock或者lock 1锁对象就被替换成了另一个Integer对象。Ineteger属于不可变对象任何数值运算都会生成新对象。两个线程先后拿到了不同锁实例同步自然失效。更隐蔽的是用字符串常量当锁字符串常量池里同一个字符串在JVM中是同一对象两个不同模块如果都锁同一个字符串字面量会出现毫无关联的业务被互相锁住的乌龙。反过来如果动态拼出来的字符串内容相同但来自不同类加载器锁对象又可能不是同一个导致锁不住。我的建议很简单锁都用私有final对象private final Object lock new Object();如果是为了实现同一个订单Id的请求互斥可以用ConcurrentHashMap按业务维度维护锁对象但一定记得处理完移除不然锁对象集合越积越大。4. JUC的另一条路CAS、Lock与并发容器4.1 原子类与CAS乐观锁是怎么自旋的java.util.concurrent包里有一整套原子类AtomicInteger、AtomicLong、AtomicBoolean、AtomicReference。它们的核心是CASCompare And Swap也就是比较并交换。CAS做的事一句话就能说明白调用compareAndSet(expected, newValue)时只有当当前值和expected相同才把值更新为newValue这个操作由底层CPU指令保证原子性。整个流程是乐观的——先假设没人抢失败了再重试重试就是自旋。看AtomicInteger.incrementAndGet()的实现思路它实际上是一个循环AtomicInteger counter new AtomicInteger(0); public int safeIncrement() { return counter.incrementAndGet(); }底层大致是读当前值计算新值然后CAS提交如果CAS失败说明别的线程改过了重新读重新算。竞争不激烈的时候这个自旋很快比让线程挂起阻塞划算得多。竞争非常激烈时大量线程不断自旋空转CPU占用会很高所以CAS不是万金油虽然它比锁轻但轻的前提是冲突少。CAS还有一个著名问题ABA。假设变量初值是A线程1读到A准备改成C这个过程中线程2先把A改成B又改回A。线程1的CAS比较发现还是A认为没人动过更新成功。但没人动过这个假设已经错了。如果变量是普通计数器ABA影响不大如果是对象引用、并且过程依赖未被修改的语义就需要用AtomicStampedReference带版本号解决。4.2 ReentrantLock与synchronized该选谁不该迷信谁ReentrantLock 是JDK提供的显式锁功能确实比synchronized多可以tryLock(timeout)设置等待时间可以lockInterruptibly支持中断可以构造公平锁可以有多个Condition队列做精细化等待通知。但它有使用成本最重要的一条解锁必须手动写否则出错时锁不释放直接死锁或卡住。规范写法是try-finallyReentrantLock lock new ReentrantLock(); lock.lock(); try { // 临界区 } finally { lock.unlock(); }我个人的选型经验是受保护逻辑很简短或者只是方法级同步直接synchronized代码简单不容易写错。需要超时获取、需要可中断、需要公平排队、需要多个等待条件时才升级到ReentrantLock。比如做一个超过2秒拿不到锁就放弃的防重入处理synchronized做不到ReentrantLock的tryLock就是为这个场景设计的。另外要注意公平锁听上去很好实际上因为要先检查队列吞吐量通常低于非公平锁。没有特别强的业务公平需求默认非公平锁就够了。4.3 并发容器ConcurrentHashMap和CopyOnWriteArrayList的设计思路普通HashMap在多线程并发写时会丢数据极端情况下扩容头插法会形成循环链表导致CPU飙到100%这是JDK 7时代大家非常心痛的一个问题。所以并发场景要用并发容器。ConcurrentHashMap在JDK 8之后的实现是分段锁的粗粒度改成了桶级CAS synchronized。读操作基本无锁写操作时如果桶为空就用CAS初始化桶已存在则只锁住该桶的头节点。当单个桶里链表超过阈值会转成红黑树防止极端hash冲突下性能退化。所以它的并发度不再受段数限制理论上是每个桶都能独立并发写。CopyOnWriteArrayList的思路更暴力每次修改add、set、remove都复制一份新数组改完再把引用指过去读操作一直读旧数组完全不加锁。所以它读性能极好写性能极差只适合读多写极少的数据比如配置项列表、监听器注册表。补充一个反面例子Collections.synchronizedMap(map)返回的包装类每个方法都加了synchronized但并发下只是串行化读和写互相竞争同一个锁。写少读多的场景它远比不上ConcurrentHashMap。很多人图省事用它结果压测一高就暴露短板。5. 线程池最常用的入口也是最多人踩坑的深渊5.1 为什么要有线程池它到底池化的是什么创建线程本身不是new对象这么轻量。每次new Thread().start()都会触发操作系统创建原生线程分配内核资源结束后又要回收。业务高峰时频繁建线程、销毁线程系统开销甚至比业务代码本身还大。线程池解决的第一个问题就是复用提前建好一批worker线程任务扔进队列哪个线程空出来就取一个执行线程本身一直活着省去重复创建销毁的成本。线程池还能做并发度控制。无脑开线程的下场是CPU核数有限线程开多了大部分时间花在上下文切换上延迟反而升高。线程池的固定线程数让并发瓶颈可控可预测。另外它的队列天然提供了缓冲。任务来太快消费跟不上可以先排队而不是直接把系统打爆。这也是它被大量用于异步解耦的原因。5.2 七个参数与执行流程先入队还是先加线程ThreadPoolExecutor构造函数有七个参数我建议所有使用者都手动去写一遍而不是抄个配置就完事ThreadPoolExecutor executor new ThreadPoolExecutor( 4, // corePoolSize 核心线程数 8, // maximumPoolSize 最大线程数 30, TimeUnit.SECONDS, // 非核心线程空闲存活时间 new ArrayBlockingQueue(1000), // 有界任务队列 new ThreadFactory() { private final AtomicInteger seq new AtomicInteger(1); Override public Thread newThread(Runnable r) { Thread t new Thread(r, batch-worker- seq.getAndIncrement()); t.setDaemon(true); return t; } }, new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略 );执行流程很多人背岔了真实逻辑是提交任务先看当前线程数是否小于corePoolSize是就直接新建线程执行如果线程数已到corePoolSize任务进队列队列满了再看线程数是否小于maximumPoolSize是就新建非核心线程执行队列满且线程数已经到maximumPoolSize执行拒绝策略。要点是核心线程满了先入队队列满了才加线程而不是线程数不够就加线程。这个顺序意味着如果你设置一个很大的无界队列线程数永远涨不到maximumPoolSize多余的线程配置形同虚设。线程数到底设多少没有公式能套准。我的经验是先区分任务类型CPU密集任务线程数接近CPU核数 1IO密集任务因为大量时间在等待网络和磁盘线程数可以放宽常见做法是核数 * 2再加一些但最终都要压测调整。还要看任务队列能容忍多大延迟如果任务要求秒级处理队列就不能太长否则排队时间直接导致超时。5.3 Executors工具类为什么被很多人嫌弃Executors提供了一堆现成线程池工厂写起来很省事但生产环境我建议慎用。它最大的问题是隐藏了关键参数让你以为配置完成实际上埋了很多雷。工厂方法队列最大线程数隐患newFixedThreadPool(n)无界LinkedBlockingQueuen任务无限制堆积内存OOMnewSingleThreadExecutor()无界LinkedBlockingQueue1同上newCachedThreadPool()SynchronousQueueInteger.MAX_VALUE来多少任务就建多少线程资源耗尽newScheduledThreadPool(n)DelayedWorkQueueInteger.MAX_VALUE同上newFixedThreadPool的故事最典型看起来固定线程数以为很安全但它的队列是无界的。有一天接口调慢了任务生产速度大于消费速度每个任务都进队列排队内存里越堆越多最后OOM而且OOM前没有任何拒绝机制告诉你系统已经扛不住了。newCachedThreadPool则是另一个极端SynchronousQueue不存任务来一个就尝试建新线程最大线程数是Integer.MAX_VALUE线程数量完全不受控。任务量突增时几万个线程同时跑每个线程分到的时间片少得可怜系统可能直接假死。所以我现在统一手动创建ThreadPoolExecutor并且给线程池命名。线上排查时线程dump里能看到batch-worker-3比看到pool-16-thread-3有用得多。5.4 拒绝策略四种姿势与自定义方案当队列满了且线程数达到maximumPoolSize时新任务会交给拒绝策略处理。四种内置策略我列一下策略行为适合场景AbortPolicy直接抛RejectedExecutionException默认让调用方感知失败CallerRunsPolicy由提交任务的线程自己执行该任务利用调用方线程做缓冲天然限流DiscardPolicy静默丢弃任务不推荐失败无感知DiscardOldestPolicy丢弃队列中最旧的任务再尝试提交可接受部分任务被丢弃我的实践里默认的AbortPolicy不是不能用但线上一定要配合异常捕获和监控。更多时候我用CallerRunsPolicy它有一个很有意思的效果当线程池饱和时提交任务的线程会被拉来干活这时候提交方线程被占用后续任务的生产速度自然降下来从需求端把压力怼回去。如果业务不允许丢任务也不允许调用方阻塞可以自定义拒绝策略。比如把被拒任务记录到MQ里稍后重试或者打一条告警日志。自定义很简单new ThreadPoolExecutor.RejectedExecutionHandler() { Override public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) { // 记录任务信息发告警或放入重试队列 System.err.println(task rejected: r); } }但自定义策略务必考虑死循环重试的风险。我有一次在拒绝策略里直接executor.execute(r)重试饱和状态下立刻又被拒绝递归下去日志刷了几百万条服务更慢了。正确的重试要带去重和退避。6. 线程池实战踩坑记录三个典型的故障现场与排查链路6.1 任务堆积导致服务超时一次从监控指标入手的排查有一次我在维护一个数据同步任务入口是定时从上游拉取文件每个文件交给一个任务处理。刚开始跑得很稳突然有几天业务方开始反馈数据延迟严重接口响应时间从百毫秒涨到几十秒。我第一反应不是去改业务代码而是看线程池的运行指标活跃线程数、队列大小、完成的任务数。结果很清晰线程数一直稳定在核心线程数四个worker队列大小从最初几百涨到十几万。也就是说任务一直在进队worker消费速度跟不上。再看单任务耗时偶发任务因为网络抖动从几百毫秒涨到三五秒队列的排队时间随之线性膨胀。这种问题用无界队列时最难察觉因为它不报错只是延迟一点点变大。改成有界队列之后队列到阈值立刻触发拒绝策略至少会让你再往里塞的行为立刻显形而不是温水煮青蛙。我最后的调整是把线程数从4提到10队列改为有界ArrayBlockingQueue(2000)拒绝策略用CallerRunsPolicy。这样参数会形成一个自我调节的闭环任务多了调用线程也被拉来消耗生产速率下降系统不至于崩也没有任务被静默丢掉。改动上线后延迟稳定在可接受范围。6.2 submit吞掉异常日志里什么都没有的灵异事件另一个让我印象深刻的坑在任务提交方式上。当时业务系统里大量用executor.submit(task)去提交异步任务但没有一个人调用submit返回的Future去取结果。后来有次某个任务内部抛了异常处理到一半的账务数据少了一批日志里却干干净净什么都没记录。这是因为submit提交的任务内部包装成FutureTask异常被捕获后存进了Future里只有调用future.get()时才会重新抛出。如果你从来不拿这个Future异常就永远沉睡在对象里对日志系统来说就是没发生过异常。从那以后我定了一个内部规范不需要返回结果的任务用execute而不是submit这样异常会直接抛给线程池能被未捕获异常处理器捕获并记录如果确实要用submit那就在finally里调用future.get()即使结果用不上也为了把异常捞出来Future? future executor.submit(task); try { future.get(); } catch (ExecutionException e) { // 拿到任务内部异常记录日志 log.error(task failed, e.getCause()); }同时给线程池设置一个全局的未捕获异常处理器Thread.setDefaultUncaughtExceptionHandler((t, e) - System.err.println(uncaught exception at thread t.getName() : e));组合起来任务异常才真正暴露在日志和监控里。6.3 ThreadLocal加线程池内存泄漏是怎么发生的ThreadLocal 是个方便的线程内传值工具但它和线程池搭配时有个特别容易忽略的坑。我遇到过这么个场景一个项目里用 ThreadLocal 保存请求链路ID请求结束后没有remove。这个代码在普通来一个请求创建一个线程的架构下没事因为线程处理完请求就销毁ThreadLocalMap随之回收。但挪到线程池后线程是复用的线程对象一直活着ThreadLocalMap也一直活着。key指向ThreadLocal对象是弱引用value却是强引用。一旦业务代码没有显式remove而ThreadLocal对象被置空value就永远挂在线程上线程池里有几十个线程就泄漏几十份数据长期跑下来产生大面积GC压力。正确写法必须是在finally里removeThreadLocalString traceIdHolder new ThreadLocal(); try { traceIdHolder.set(traceId); // 业务逻辑 } finally { traceIdHolder.remove(); }我见过很多代码真是只用不删。如果是请求上下文、用户信息这类数据我的经验是宁可每次在入口设置出口统一清理也不要靠线程结束自动回收这种侥幸。线程池本身不会帮你清理ThreadLocal的。到这里JavaSE系列并发部分的核心零件算是都过了一遍。说实话这些内容看十遍文档不如亲手复现一遍把线程状态打出来看看把无界队列撑爆一次把submit的异常藏起来试试。我在实际项目里最感激这些踩坑经历因为并发问题一旦到线上表现往往是最难猜的那一类。希望这篇能把你的启动成本降低一些。