打开搜索引擎的线程相关热搜词你很容易找到这样的问题线程与进程的区别Java获取当前线程名线程池的阻塞队列怎么选Java 21的虚拟线程死锁怎么排查。这些词说明一个事实线程这个话题看似人人都能聊两句但真正从概念到实现、从原理到应用完整打通的人并没有想象中那么多。我工作头几年就是这样天天写着ExecutorService但被同事问一句你线程池的阻塞队列为什么选有界队列就卡住。后来线上服务出现假死、CPU飙高、日志不打印才逼着我把线程的底层机制彻底啃了一遍。这篇不打算给你背八股而是把我这些年踩过的线程相关的坑、排查思路和调优实践揉在一起讲。整体以Java生态为主但进程线程的区别、状态机、锁、死锁这些原理放到任何一种语言里都成立Python、Go、C的读者同样可以参考。1. 线程的概念说说进程缩小版这个误区错在哪1.1 线程是执行单元进程是资源容器很多人理解进程和线程天然会把它们想成大盒子里套小盒子的包含关系——进程是大盒子线程是里面的小盒子。这个类比帮助入门可以但往深处走就是坑。操作系统的教科书定义很明确进程是资源分配的基本单位线程是CPU调度的基本单位。翻译成大白话就是进程负责管理这个程序拥有的资源——内存地址空间、文件描述符、打开的网络连接、信号处理器等线程负责真正执行代码它是一条独立的指令执行流有自己的程序计数器、寄存器上下文和栈。拿办公室做类比就很好懂进程是一间办公室办公室里所有员工线程共用电话、打印机、茶水间堆内存、文件句柄、静态变量但每个员工都有自己的工位和笔记本电脑线程栈、寄存器。员工可以互相传递纸张线程间通信但一个员工把某张纸攥在手里不放持有锁另一个员工就干等着。这个区别直接决定了并发问题的来源因为线程共享进程的资源所以两个线程可以同时读写同一个全局变量又因为线程的调度是独立的谁先读、谁先写完全不确定于是才有了竞态条件才有了线程安全这一整章的内容。1.2 三种实现路线内核级线程、用户级线程、混合模型线程不是唯一的实现路径。面试和实际工作中最容易被混淆的是线程的三种实现方式模型谁负责调度优点缺点典型案例内核级线程1:1操作系统内核能利用多核阻塞不影响其他线程用户态到内核态切换开销大Java主流线程模型用户级线程N:1用户态库或运行时切换快创建成本低多核利用差一个线程阻塞全进程阻塞Java早期Green Thread混合模型M:N用户态调度 内核态载体兼顾多核与轻量实现复杂并发出错难排查Go的Goroutine你可能会说Java的Thread不是很简单吗new Thread()一下不就创建线程了。其实在HotSpot虚拟机里Thread.start()最终会调用底层pthread_createLinux环境创建一个内核线程所以Java默认是1:1模型。这也是为什么JVM里线程数一多整个系统负载就上来的原因——每个线程都对应一个内核级调度实体。有意思的是JDK 21引入的虚拟线程本质上是把用户级线程的路线又捡了回来用很少的载体线程调度大量虚拟线程这也是我后面要专门展开的话题。1.3 不同语言里的线程长什么样理解了三种实现路线再去看不同语言的并发原语会非常清晰。JavaThread对应内核线程synchronized、ReentrantLock解决互斥ThreadPoolExecutor管理线程生命周期。Python标准threading.Thread也是操作系统线程但因为有GIL全局解释器锁同一时刻只有一个线程在解释器中真正执行字节码所以CPU密集型的Python多线程并不能并行提速。这也是自由线程这个词最近越来越热的原因。Gogoroutine并不是传统的线程它是混合模型下的轻量级调度单元初始栈只有2KB左右由Go运行时自己调度语言层面将其包装成协程体验。应用层的“线程”在实际运行中往往是“编程语言暴露给开发者的并发抽象”。真正的高性能编程很多时候拼的就是你选对了哪一种抽象。2. 从创建到销毁线程状态、调度代价与观测手段2.1 六种线程状态是怎么流转的Java的Thread.State枚举里定义了六种状态NEW、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED。很多人背过这张表但在实际排查问题时容易搞混RUNNABLE和BLOCKED。简单梳理一下NEWnew Thread()之后start()之前。此时线程对象存在但操作系统还没有真正创建对应的线程实体。RUNNABLE调用start()之后。这里是最容易误解的地方它不是正在运行中而是随时可以被调度器选中运行。哪怕你的线程在做极耗时的计算或者处于就绪队列里排队等待CPU时间片状态都是RUNNABLE。BLOCKED线程等待监视器锁。比如两个线程同时竞争synchronized代码块没抢到锁的那个会进入BLOCKED。WAITING无限期等待某个条件典型的是Object.wait()、Thread.join()、LockSupport.park()。TIMED_WAITING带超时时间的等待比如sleep(1000)、wait(1000)、join(1000)。TERMINATED线程执行完毕或者异常退出。我记得有个热搜词是java线程等待都完成对应的就是主线程里调thread.join()。join()的底层其实是wait()机制——主线程进入WAITING状态等待子线程执行完再调用notifyAll()唤醒主线程。如果多个子线程需要并行执行网上很多教程让你循环join()这没问题但如果想统一等待一批任务结束并且带超时控制我更推荐用ExecutorService配合CountDownLatch或者CompletableFuture.allOf()后面讲线程池时会再提到。2.2 上下文切换为什么线程不是越多越好很多人一碰上请求慢就下意识加线程。这是非常危险的做法。线程的本质是并发但并发的代价是上下文切换。所谓上下文切换就是CPU从前一个线程切换到后一个线程时需要保存当前线程的程序计数器、寄存器、栈指针等现场信息然后加载下一个线程的现场信息。内核级线程的切换还要经历用户态到内核态的陷入、再返回。这个开销单次看起来不算大几百纳秒到几个微秒级别但如果是高频率切换比如几百个线程同时抢几个CPU核大量时间会耗在换人上而不是干活上。还有一个容易忽略的问题是缓存亲和性。线程切换到另一个CPU核上运行时L1/L2缓存里的数据可能全部失效需要重新加载这在大型系统里比寄存器保存的开销更可观。热搜词里有一条w11怎么设置一个程序单独占一个线程这个提问本身就说明很多人对调度机制有误解。现代操作系统都是分时抢占式调度你没法让某个程序独占一个线程——系统会把线程视为调度单位自己决定谁在哪个核上跑。你唯一能做的要么是给线程设置CPU亲和性比如Linux的taskset要么是把进程绑定到特定核心但这些都是极端性能场景才需要做的事日常编码完全不用考虑。2.3 排查线程问题的三大观测手段既然线程是黑盒线上出了问题怎么看清它我的经验是三层递进第一层jstack看线程快照。Java服务最常见的排查动作就是jstack pid它会打出所有线程的状态栈。重点看三个信息线程名排查线程要先认人自定义线程池记得用ThreadFactory给每个线程起有意义的名字比如order-notify-thread-1。状态大量线程处于TIMED_WAITING和一个WAITING通常没事大量RUNNABLE且堆栈都在同个代码段可能就是热点死循环或CPU密集计算。锁信息死锁会被jstack直接检测会打印Found one Java-level deadlock。第二层JVM监控工具。以Spark这类大数据场景为例Executor的线程状态直接反映作业的执行情况。Spark UI的Executors页面上能看到每个Executor的Active Tasks、GC Time这些指标如果要看内部线程细节还是要jstack加executor的pid。如果你用的容器或者云环境拿不到pid至少要看监控系统里的threads线程总数、blocked_count阻塞线程数、deadlock_count死锁线程数这几个指标做趋势判断。第三层嵌入式/实时系统的单线程观测。热搜词里qnx查看单个线程的指令确实是个偏门需求。QNX的pidin命令可以查看系统中每个进程和线程的状态比如pidin -p pid -t info能列出某个进程下所有线程的优先级、CPU时间、状态。再配合-F自定义输出字段可以把某个线程的指令指针、栈指针打出来。拿到指令地址后对照编译产物的符号表或者用qnx tail去看地址落在哪个函数里基本能定位到卡在哪个系统调用上。这种能力和jstack异曲同工只是工具链不同。3. 线程安全不是玄学原子性、可见性、锁与死锁3.1 线程安全的三块基石原子性、可见性、有序性线程安全问题归根结底是三个底层问题的排列组合原子性一段操作要么全部执行完要么不执行。典型的不安全案例就是count它不是单条CPU指令而是读取-修改-写入三步两个线程交叉执行就会丢更新。可见性一个线程修改了共享变量另一个线程能否立即看到。CPU有缓存JVM也有JIT优化变量可能先被放在CPU寄存器或线程的本地缓存里没有同步手段时其他线程读到的可能是过期值。有序性编译器/CPU为了性能会对指令重排。单线程内重排不影响结果但多线程场景可能造成代码写得A在前实际执行B在前的诡异效果。Java为此提供了volatile、synchronized、final以及java.util.concurrent包下的各种锁和原子类。理解它们不是背语法而是搞清楚它们分别管上面哪件事。3.2 synchronized、volatile、CAS到底是谁在干活这可能是整个并发编程里被误解最多的地方。先给结论synchronized管原子性可见性。它通过监视器锁Monitor让同一时刻只有一个线程进入临界区同时加锁成功后的线程能看到前面线程释放锁前写下的所有共享变量内容Happens-Before规则。volatile只管可见性和有序性不管原子性。它让变量每次读写都直接走主内存禁止指令重排但对count这种复合操作无能为力。AtomicInteger、LongAdder等原子类底层用CASCompare And Swap实现乐观锁适合读-改-写这种高频小操作。一个典型的错误是很多人觉得只要这个变量是volatile的就线程安全了。不对。举个实际例子我自己早期写过一段统计代码volatile int count 0; // 多线程执行 count;跑了半天发现count的最终值严重偏小原因很简单count分三步两个线程同时读到同样的旧值各自加1再写回其中一个更新就被覆盖了。volatile保证这个覆盖操作最终是可见的但没保证没有覆盖发生。对这种场景要么用synchronized包起来要么直接用AtomicIntegerAtomicInteger count new AtomicInteger(0); count.incrementAndGet();顺带说一个工程经验不要迷信AtomicLong做所有记数高竞争下CAS的自旋会让CPU空转。写入很频繁时用LongAdder做累加用LongAccumulator做自定义聚合读取时再sum()它内部把热点分散到了一组cell上。3.3 时间格式化为什么线程不安全一个被问爆的场景热搜词里有获取当前时间线程安全这确实是生产环境的高频踩坑点。问题通常出在SimpleDateFormat身上它的format()和parse()方法内部使用了Calendar对象而这个Calendar是实例变量多线程共享同一个SimpleDateFormat实例时会互相覆盖字段导致时间错乱甚至抛出NumberFormatException。我自己就遇到过一个导出报表服务本地单线程测试完全正常上了线上偶尔出现时间变成2024年13月45日这种怪值。查半天最后定位到是一个static的SimpleDateFormat被所有请求线程共用。解决方案就三种每次调用都new SimpleDateFormat简单但浪费对象用ThreadLocalSimpleDateFormat每个线程持有自己的实例用JDK 8以后的DateTimeFormatter它是不可变的天然线程安全。现在的项目里我基本只用DateTimeFormatterDateTimeFormatter formatter DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss); String time LocalDateTime.now().format(formatter);不要懒别再用new Date().toString()去拼接字符串时间。3.4 死锁四个必要条件与一次真实排查死锁是面试必考题也是线上稳定性事故的高发类型。它的四个必要条件是互斥、持有并等待、不可剥夺、循环等待。翻译成人话就是共享资源同时只能被一个线程用互斥线程占着A资源不放又去要B资源持有并等待别人不能强行抢走你手里的资源不可剥夺线程们握着的资源形成一个环形链循环等待。我印象最深的一次排查两个服务之间同步调用户信息服务A的线程持有用户缓存锁去等订单锁服务B的线程持有订单锁去等用户缓存锁双方僵持线程池全部占满服务假死。当时第一反应是看监控——线程数飙升但请求成功率下降。排查链路是这样的先找到服务进程的pid一把jstack pid输出重定向到文件搜索Found one Java-level deadlock关键字jstack很给力会直接帮你把死锁链画出来看线程栈里的锁ID找到每个锁是在哪段代码里被持有的再对照源码确认加锁顺序。jstack的输出类似这样简化版http-nio-8080-exec-23: waiting for 0x00000007d6b12345 (a com.demo.OrderLock) http-nio-8080-exec-31: waiting for 0x00000007d6b12367 (a com.demo.UserCacheLock)最后的改法很朴素全局统一加锁顺序所有线程先拿用户缓存锁再拿订单锁循环等待自然被打破。现在我还坚持一个习惯在任何需要同时拿两把锁的代码里写注释标明锁的层级顺序防止后来的同事把顺序写反。3.5 子线程操作UI换线程模型而不是硬拼锁热搜词里有一条易语言子线程怎么让主线程操作ui控件Android那边也经常有人问Fragment开启线程更新UI。这背后的核心问题其实是UI框架的线程模型不允许你在非UI线程操作控件。主线程UI线程持有消息队列任何UI更新都必须排到队列里由主线程逐一执行。如果你在子线程里直接改控件属性轻则不生效重则崩溃或数据错乱。解决思路不是加锁而是切回正确的线程再执行Android用runOnUiThread()或者Handler.post()Java Swing/SWT用SwingUtilities.invokeLater()通用GUI框架无论什么语言基本都是发消息给UI线程这套模型。这其实是个很典型的设计原则不要试图在多个线程之间通过共享UI变量解决同步而是把并发任务的结果通过消息/回调传回UI线程。数据流的方向一旦理顺锁也跟着少了一大半。4. 线程池并发应用层最重要的基础组件4.1 ThreadPoolExecutor的七个参数每一个都有说头线程池为什么重要因为线程的创建和销毁成本太高尤其在高并发场景下每一次new Thread()都是在申请内核资源线程过多还会加剧上下文切换。线程池的本质是把线程的创建和复用集中管理就像预先雇一批人活来了直接派单。ThreadPoolExecutor的构造参数是理解线程池的钥匙参数含义备注corePoolSize核心线程数即使空闲也会保留的线程数量maximumPoolSize最大线程数线程数不能超过这个上限keepAliveTime非核心线程空闲保活时间超过这个时间且线程数大于corePoolSize时回收workQueue任务阻塞队列核心线程全忙时新任务放这里排队threadFactory线程工厂用于定义线程名、是否是守护线程handler拒绝策略队列也满且线程数达到上限时触发它的执行流程用大白话说是这个逻辑来了一个任务如果当前线程数小于corePoolSize就直接新建核心线程执行如果线程数达到corePoolSize新任务塞进workQueue排队如果队列也满了再判断线程数是否小于maximumPoolSize是则继续创建非核心线程救急如果线程数已经到maximumPoolSize且队列已满就触发RejectedExecutionHandler拒单。这里有几个细节容易被忽略。第一ThreadPoolExecutor不会先创建满corePoolSize个线程它是懒创建——有任务来了才建。所以你可以通过重写beforeExecute、afterExecute来监控线程的实际活跃情况。第二allowCoreThreadTimeOut(true)可以让核心线程在空闲时也被回收适合低峰期省资源。第三队列选择直接影响上面第三步的触发时机。4.2 阻塞队列的选型不是随便挑一个线程池的阻塞队列选择能上热搜说明很多人被这个问题卡过。ThreadPoolExecutor的workQueue最常用的有四类ArrayBlockingQueue有界队列必须指定容量。任务多到队列满时才会扩线程到maximumPoolSize。适用场景希望线程数可控、避免任务无限积压压垮内存。LinkedBlockingQueue无界队列可以无限堆积任务当corePoolSize线程全忙新任务全排到队列永远不会触发创建非核心线程。风险是内存被任务塞爆服务OOM。SynchronousQueue同步移交队列队列本身不缓存任务任务直接交给线程。如果没有空闲线程必须立即新建线程。适用场景任务量大且需要快速响应但线程数会飙升。DelayQueue延迟队列任务可以延迟一定时间才被执行适合定时/延迟任务。这里我想专门说说Executors内置线程池的问题。Executors.newFixedThreadPool(n)默认用的是无界LinkedBlockingQueueExecutors.newCachedThreadPool()默认用的是SynchronousQueue且最大线程数是Integer.MAX_VALUE。前者任务堆积可能OOM后者线程爆炸可能把系统拖垮。这也是很多规范里反复强调不要用Executors要手动new ThreadPoolExecutor的根本原因。生产环境我一般这样选如果任务流量的峰值有一定上限用有界ArrayBlockingQueue容量设为预估高峰排队数的1.2到1.5倍再配一个兜底的拒绝策略如果任务本身要求低延迟且能接受大量短线程选SynchronousQueue但一定要限制maximumPoolSize。4.3 核心线程数到底怎么算公式和实操很多人面试时背CPU密集CPU核数1IO密集2*CPU核数1这两个经验值能应付面试但生产环境我建议直接用更基础的公式CPU密集型任务线程数 ≈ CPU核数 1加1个是防止某个线程因缺页中断等被调度出去时造成CPU空转。IO密集型任务线程数 ≈ CPU核数 × (1 平均IO等待时间 / 平均CPU计算时间)。举一个我调过的真实案例一台4核8线程的机器跑一个批量同步服务每个任务要发一次HTTP请求平均耗时80ms然后做约20ms的本机计算。代入公式4 × (1 80/20) 20所以我把核心线程数设成20左右。如果你是通用型业务系统不想算太细也可以用2 * CPU核数起步然后用压测曲线去校准。核心参数的调整不是一次到位。我的习惯是先小流量跑看线程池活跃线程数、队列积压量、响应时间三个指标再逐步调大maximumPoolSize直到响应时间符合预期并且CPU没有长期打满。线程池的参数是活的不是写完就永久不变的。4.4 拒绝策略与优雅关闭这两个细节决定了线上口碑当任务提交超过线程池处理能力时RejectedExecutionHandler会根据策略决定怎么处理这个任务。ThreadPoolExecutor内置了四种策略AbortPolicy直接抛RejectedExecutionException让调用方感知失败CallerRunsPolicy提交任务的线程自己执行这个任务相当于把压力回传给调用方通常能起到削峰效果DiscardPolicy静默丢弃新任务DiscardOldestPolicy丢弃队列里最旧的任务让新任务进来。默认策略是AbortPolicy但线上直接抛异常对调用方不友好。我的默认选择是CallerRunsPolicy它在服务过载时把多余任务交给调用线程慢慢执行既不会丢任务又天然限制提交速度。再就是优雅关闭。每次看到有人直接ExecutorService.shutdown()的代码我都要多看一眼。shutdown()的含义是不再接收新任务但已经提交的任务仍然会执行完而shutdownNow()是尝试中断正在执行的任务并返回未执行的任务列表。正确的关闭姿势是pool.shutdown(); if (!pool.awaitTermination(60, TimeUnit.SECONDS)) { pool.shutdownNow(); if (!pool.awaitTermination(60, TimeUnit.SECONDS)) { // 记录日志说明还有任务没能停止 } }这样主线程可以安心等待所有已提交任务执行完同时防止线程池一直挂着导致JVM无法退出。我最开始提到的java线程等待都完成本质就是在做这种同步收口。5. 新一代线程形态虚拟线程、Actor模型与自由线程5.1 虚拟线程把线程从内核仓库搬到JVM仓库Java 21最大的并发变化就是虚拟线程Virtual Threads。热搜里java21 spring boot 3.5启用虚拟线程说明很多团队已经在尝试了。虚拟线程是JVM维护的用户态线程底层由一组数量有限的载体线程Carrier Thread来执行。和传统内核线程1:1不同虚拟线程与载体线程是M:N的关系。当一个虚拟线程发生阻塞比如IO等待JVM会自动把它从载体线程上卸载把载体线程让给其他虚拟线程用。这样单个进程可以轻松创建几十万甚至上百万个虚拟线程因为它本质上是堆内存里的一个对象而不是操作系统资源。用代码来对比更直观。传统写法ExecutorService executor Executors.newFixedThreadPool(100); for (int i 0; i 10000; i) { executor.submit(() - { // 模拟IO阻塞 TimeUnit.MILLISECONDS.sleep(100); }); }如果想同时跑1万个任务线程池至少得100个线程而且每个线程可能同时跑一个任务其余排队。虚拟线程写法try (var executor Executors.newVirtualThreadPerTaskExecutor()) { for (int i 0; i 10000; i) { executor.submit(() - { TimeUnit.MILLISECONDS.sleep(100); }); } }这里每个任务都对应一个虚拟线程你不用再纠结核心线程数、队列长度这些参数——创建虚拟线程的开销极小系统能撑住海量并发。在Spring Boot 3.5里如果要全局启用虚拟线程配置文件一行就能搞定spring.threads.virtual.enabledtrue但注意虚拟线程不是万能药。它是为解决大量IO阻塞场景下的线程资源浪费设计的对CPU密集型的计算任务没有帮助因为计算任务不会主动让出载体线程反而因为调度成本可能更慢。另一个坑是虚拟线程里如果使用了synchronizedJVM依然可能把虚拟线程阻塞在载体线程上JDK 21里synchronized会固定载体线程所以高并发场景下该用ReentrantLock的地方还是得用ReentrantLock。5.2 Akka线程模型Actor不是线程Dispatcher才是真相热搜词akka线程模型出现了说明很多人也在研究基于Actor的并发框架。Akka用Actor模型把并发单元从线程提升到消息处理者但如果你以为每个Actor一个线程那就理解偏了。Actor本身是轻量对象没有自己专属的线程。Actor的并发能力来自Dispatcher——Dispatcher把Actor mailbox里的消息分配给线程池中的线程执行。默认Dispatcher基于ForkJoinPool可以通过配置调整akka.actor.default-dispatcher.executor fork-join-executor akka.actor.default-dispatcher.throughput 5throughput表示一个线程在切换Actor之前最多连续处理多少条消息调大throughput会减少线程切换次数但单个Actor的处理延迟会上升。Akka线程模型的价值在于它让消息传递替代共享内存锁Actor之间通过发送不可变消息交互状态隔离在Actor内部天然规避了很多线程安全问题。但底层的线程池仍然需要你认真调优——比如按Actor分区共享线程池不能让所有Actor挤在一个默认Dispatcher里互相抢线程。5.3 自由线程Free-ThreadedGIL之后的Python并行路线自由线程这个词热度很高主要源自Python社区对移除GIL的讨论。简单说GILGlobal Interpreter Lock保证CPython解释器中同一时刻只有一个线程执行字节码这让Python多线程对CPU密集任务的加速基本无效。所谓自由线程是指去掉全局锁、允许多个线程真正并行执行Python字节码的解释器实现方向。但这里必须提醒一句自由线程不代表数据竞争消失了。多个线程同时读写一个Python对象照样需要锁或者不可变对象来保证一致性。它解决的是解释器级别的串行瓶颈把并行的能力交还给你而不是替代你写同步代码。如果对Python并发有需求我的建议是分场景IO密集任务用asyncio或者标准ThreadPoolExecutor就够了CPU密集任务用multiprocessing或C扩展、NumPy这类释放GIL的库更实际等到自由线程版本成熟稳定后再评估是否能让多线程真正跑满多核。最后的排查清单和一点体会讲了不少原理最后分享一个我在实际项目里反复使用的排查清单遇到线程问题先用它过一遍线程数异常升高先看是不是线程池队列配置成了无界队列任务积压导致线程数被迫扩张再看是不是有阻塞调用如HttpClient超时时间设太长把线程全部拖在等待上。CPU 100%但业务不报错优先jstack找大量RUNNABLE且栈都指向同一个方法的线程。热点方法如果是纯计算考虑算法优化或改为批量异步。偶发数据错乱优先怀疑共享可变对象。看看代码里有没有static的SimpleDateFormat、有没有多线程操作同一个ArrayList或HashMap。服务假死但能看到线程优先查死锁和阻塞线程占比。jstack输出的Found one Java-level deadlock直接定位循环等待别犹豫立刻按照锁顺序调整代码。线程池拒绝执行检查队列是否太小、线程数上限是否打满、拒绝策略是否适合当前业务。我倾向于CallerRunsPolicy兜底至少任务不会静默丢失。我刚开始接触并发编程的时候以为多线程 快后来才明白多线程 复杂它把系统的时序不确定性放大到了每个变量和每个方法调用上。想要把线程用好能卷的状态机、加锁顺序、队列选型这些基础概念比记住某个框架的API重要得多。希望这篇从概念、实现、原理到应用的梳理能帮你少踩几个我当年踩过的坑。