进程与线程：从底层原理到线上并发问题排查

做并发编程的人，早晚都要面对这两个词：进程、线程。不管是面试被反复追问“进程和线程的区别”，还是线上接口突然卡死、CPU飙到100%、线程池队列被打满，追根溯源都会落到这俩概念上。我接触并发编程这么多年，见过太多人把进程和线程的关系停留在“进程是资源分配的单位，线程是调度的单位”这种背课本的层面，真到排查问题的时候，线程状态看不懂、堆栈信息不会抓、线程池参数乱配，最后只能靠重启解决。这篇文章就不讲虚的了，从操作系统底层的视角把进程和线程彻底拆开，再把线程池、并发安全、死锁、进程通信这些实战高频问题逐个过一遍，适合正在学并发的初学者，也适合写了好几年业务代码但一直没系统梳理过并发知识的开发人员。

1. 进程与线程：并发世界的地基

1.1 先搞清一个核心问题：进程和线程到底是什么关系

很多人把进程理解成“正在运行的程序”，这个说法对，但不完整。进程是操作系统进行资源分配和隔离的基本单位，它包含了一段完整的地址空间、打开的文件描述符、环境变量、堆栈、代码段数据段，以及操作系统为它维护的各种控制信息。

线程则是进程内部的一条执行路径，是真正被CPU调度执行的最小单位。同一个进程里的多个线程共享这个进程的地址空间和资源，但各自拥有独立的程序计数器、栈和寄存器状态。

我用一个生活化的类比来解释：把操作系统比作一家公司，进程就是公司里的一个个项目组，每个项目组有自己独立的办公室、设备、预算，组与组之间互不干扰。线程就是项目组里的员工，同一个组的员工共享办公室、设备和预算，但每个员工有自己的工位和手头任务。你要新开一个项目组，公司得批办公室、配设备，成本很高；但在项目组里加一个人，只需要安排一个工位就行，成本低得多。进程切换的代价远大于线程切换，道理就在这里——切换进程要换办公室、换预算表，切换线程只是换个员工干活。

从Linux的实现来看，线程本质上是轻量级进程，通过clone系统调用创建，只是共享了地址空间等资源。JVM里所谓的“用户线程”和操作系统的线程还是一一对应的关系。所以搞清楚这个概念，后续看线程池的线程数设置、进程通信的开销、性能调优的方向，才有依据。

1.2 线程的完整生命周期：从新建到终止

线程不是一new出来就开始跑，也不是一调用start就立刻执行。Java线程有六个状态，这个面试常考，但很多人只是背名字，不理解状态迁移的触发条件。

• NEW：刚new出来，还没调用start，此时线程对象存在，但操作系统里还没有对应线程。
• RUNNABLE：调用了start，线程已经在JVM里就绪，等待操作系统调度分配CPU时间片。这里注意，Java的RUNNABLE把操作系统里的就绪（ready）和运行（running）两个状态合并了。
• BLOCKED：线程在等待获取监视器锁，也就是想进入synchronized代码块但锁被别人占着。
• WAITING：线程在等待其他线程唤醒，比如调用Object.wait()、Thread.join()、LockSupport.park()。
• TIMED_WAITING：带超时等待，比如sleep(1000)、wait(1000)、join(1000)。
• TERMINATED：线程执行完run方法或者抛出未捕获异常退出。

最容易混淆的就是BLOCKED和WAITING。简单区分：BLOCKED是“锁被人占着，我进不去”，是竞争同步锁时特有的状态；WAITING是“我主动歇了，等别人叫我”，通常是调wait或join之后。线上抓线程快照时，如果大量线程卡在BLOCKED，基本可以断定是锁冲突热点；如果大量线程卡在WAITING，多半是线程池队列等待、RPC调用等待之类的场景，要结合堆栈具体看。

1.3 进程和线程的经典对比

既然要“彻底搞懂”，那进程和线程的核心区别必须掰开揉碎。下面这个表我从资源、切换、通信、稳定性、开销几个维度做了对比，实际排查问题和做技术选型的时候，这个表可以直接拿来当参照。

这里说一个我踩过坑的点：不要把“线程切换开销小”理解成“线程切换不要钱”。线程切换同样涉及用户态到内核态的切换、上下文的保存恢复，线程数量一旦过千，光上下文切换的CPU开销就能把系统拖垮。所以后面讲线程池，核心目的之一就是限制线程数量，避免无休止地创建线程导致切换风暴。

2. 线程池：你真正每天都在用的并发设施

2.1 为什么非要用线程池

很多人刚开始写并发，习惯直接new Thread去干活，图省事。但线上系统如果按这个写法，并发一上来基本就要出事。原因是线程的创建和销毁都是有成本的，一个线程从创建到销毁涉及系统调用、内核资源分配、JVM内存分配，频繁创建销毁会导致频繁的GC和系统调用开销。更严重的是，无限制创建线程会耗尽系统内存，因为每个线程默认栈大小1MB（JVM的-Xss配置），1000个线程就是1GB的虚拟内存开销。

线程池的核心思想是池化复用，这和数据库连接池、HTTP连接池是同一个套路：提前建好一批线程放在池子里，有任务就丢给空闲线程执行，没有空闲线程就把任务放进队列等待，线程执行完任务后不销毁，回到池子里继续等待下个任务。这样做的好处是减少了线程创建销毁的频次，同时通过队列起到了削峰填谷的作用，还能统一管理线程的生命周期和异常处理。

从热搜词里也能看到大量关于线程池的讨论，这说明线程池确实是并发编程里最实战的一个点。很多人会背《阿里巴巴Java开发手册》里的规范：“线程池不允许使用Executors去创建，要通过ThreadPoolExecutor的方式”，但真正理解为什么的人不多。Executors.newFixedThreadPool用的是无界LinkedBlockingQueue，任务多了队列无限增长，内存可能被打爆；newCachedThreadPool用的是SynchronousQueue，来一个任务就创建一个线程，任务多了线程数无限扩张。这些坑都是真实发生过的事故。

2.2 线程池核心参数：每一个都别瞎配

ThreadPoolExecutor有七个参数，核心参数是前五个：corePoolSize、maximumPoolSize、keepAliveTime、unit、workQueue。

• corePoolSize：核心线程数。核心线程会一直存活，即使空闲也不会被回收，除非设置了allowCoreThreadTimeOut。
• maximumPoolSize：最大线程数。线程数达到核心数后，如果队列也满了，还会继续创建线程，直到达到这个上限。
• keepAliveTime：非核心线程空闲存活时间。超过这个时间没有任务执行，非核心线程会被回收。
• workQueue：任务队列。核心线程忙不过来时，新任务先放队列。
• threadFactory：线程工厂，统一设置线程名、是否守护线程等。
• handler：拒绝策略。队列满了且线程数达到最大值时，新任务会被拒绝。

这里最常见的实践问题是：核心线程数到底配多少？网上流传的“CPU密集型配CPU核数+1，IO密集型配CPU核数x2”只是一个经验起点，不严谨。更合理的方式是用公式估算。CPU密集型任务，线程数约等于N+1，N是CPU核数；IO密集型任务，线程数可以按 N * (1 + 等待时间/计算时间) 来算。比如一个任务IO等待占80%、计算占20%，那就是 N * (1 + 4) = 5N。但这个公式也是估算，真实线上还要结合压测结果调优，没有银弹。

另一个常被忽略的参数是threadFactory。默认的线程工厂创建出来的线程名字是“pool-1-thread-1”，排查问题时根本看不出这个线程是干什么的。我习惯自定义ThreadFactory，把线程名改成业务相关的名字，比如“order-async-worker-”，这样线上抓线程快照一眼就能定位是哪个业务模块的线程出了问题。

2.3 submit与execute的差异：一个返回值引发的坑

线程池提交任务有两种方式：execute(Runnable)和submit(Callable/Runnable)。很多新手混着用，觉得差不多，但两者的差异非常关键。

execute直接执行任务，没有返回值，任务执行过程中抛出的异常会直接抛给线程池的UncaughtExceptionHandler处理，如果没有自定义handler，异常会被线程的默认处理器捕获并打印到日志里。

submit会把任务包装成RunnableFuture（实际是FutureTask），返回一个Future对象。你调用future.get()的时候能拿到任务执行结果，或者捕获任务内部抛出的异常（ExecutionException包装了一层）。但注意，submit提交的任务如果内部抛异常，这个异常不会直接打印出来，而是被“吃掉”了，只有调用get()的时候才会以ExecutionException的形式暴露。很多线上事故就是用了submit但从不调用get()，任务悄悄失败了，日志里什么都看不到。

我的建议是：不需要返回值就统一用execute，需要返回结果或者需要显式捕获任务异常就统一用submit并调用get()。如果用的是submit但确实不关心返回值，也建议在任务内部自己try-catch处理异常，避免异常被吞。

2.4 阻塞队列选择：LinkedBlockingQueue还是ArrayBlockingQueue

workQueue的选择直接决定线程池的缓冲策略。常用的有这几种：

• LinkedBlockingQueue：默认无界，可以指定容量。JUC里默认newFixedThreadPool用的就是无界版本，任务无限排队，最大线程数形同虚设。
• ArrayBlockingQueue：有界队列，必须指定容量。容量大小需要结合业务的峰值消息量估算。
• SynchronousQueue：不存储任务，每个插入操作必须等待另一个线程的移除操作。newCachedThreadPool用的就是它。
• PriorityBlockingQueue：支持优先级排序的任务队列，适用于任务有优先级差异的场景。

选择的核心判断标准只有一个：是否允许任务排队，以及允许排多长队。有界队列更安全，可以防止任务积压导致内存膨胀，代价是触发拒绝策略，需要配合合理的拒绝策略兜底。无界队列在任务突增的时候看似“稳定”，其实是把压力转嫁给了内存，最后可能OOM。

拒绝策略也有四种：AbortPolicy（直接抛异常，默认）、CallerRunsPolicy（调用者线程自己执行任务）、DiscardPolicy（静默丢弃）、DiscardOldestPolicy（丢弃最老任务）。我习惯用CallerRunsPolicy，任务被拒绝时由提交任务的线程自己执行，天然起到了限流的作用——提交线程忙着执行任务，就没法继续疯狂提交了。这个策略在大多数业务场景下比直接抛异常友好得多。

3. 并发正确性：原子性、可见性、有序性

3.1 三大问题的现场还原

并发编程的难点不在于“多个线程同时跑”，而在于多个线程同时访问共享数据时，如何保证结果的正确性。这背后是三个经典问题：原子性、可见性、有序性。

原子性：一个操作或者多个操作要么全部执行成功，要么全部不执行，中间不能被其他线程打断。i++这行代码看起来是一条语句，但在字节码层面其实是先把i加载到栈，再+1，再写回，至少三步。两个线程同时执行i++，都读到了同一个旧值，然后各自写回，最终结果就丢了一次更新。

可见性：一个线程修改了共享变量，另一个线程可能看不到。因为CPU有缓存、编译器有优化，线程操作变量时不一定直接操作主内存，而是先读到自己线程的缓存里。加了volatile或者synchronized之后，修改会强制写回主内存，其他线程读取时也会强制从主内存读。

有序性：编译器为了优化性能，会调整指令执行顺序。在单线程下这没问题，因为最终结果不变。但在多线程下，指令重排可能导致一个线程看到另一个线程的操作顺序和预期不一致。最经典的例子就是双重检查锁单例模式里，instance = new Singleton() 这一步在底层可能被重排成“先分配内存，再赋值引用，再初始化对象”，另一个线程在中间时刻读到了非null的引用，但对象还没初始化完。

这三个问题不是独立的，通常混合出现。比如一个共享计数器，既要保证i++的原子性，又要保证多次修改的可见性，还要防止指令重排带来的乱序。Java的解决方案也是一整套组合拳：synchronized和Lock解决原子性，volatile解决可见性和一定程度的有序性，final和happens-before规则保证有序性。

3.2 锁、volatile与线程安全类

synchronized是Java内置的锁，可以修饰方法、代码块。它有几个关键点：是可重入的，同一个线程可以多次获取同一把锁；是互斥的，同一时刻只能有一个线程持有；锁的释放是自动的，无论是正常执行完还是抛异常，都会自动释放。

ReentrantLock和synchronized相比，功能更丰富：支持公平锁（按等待时间排队获取）、支持超时获取锁（tryLock(timeout)）、支持多个条件变量（Condition）、支持中断响应。性能上现在两者差距不大，synchronized经过锁升级优化后，无竞争场景下开销很小。选择上我的经验是：功能简单的场景用synchronized，代码更简洁；需要超时控制、公平性、多个条件队列时用ReentrantLock。

volatile是更轻量级的同步机制，它保证了两点：对一个volatile变量的写会立即对其他线程可见；禁止对这个变量相关的指令重排。但volatile不能保证原子性。经典误区是拿volatile修饰一个int然后做i++，这依然是非线程安全的。volatile的适用场景是：一个变量被多个线程读，但只有少数线程写，且写操作是原子的。比如状态标志位、开关控制。

除了锁，Java并发包还提供了很多线程安全的类和工具，这是我在实际开发中最推荐的方案——能用工具类解决的，就不要自己造锁。比如AtomicInteger解决计数器问题，ConcurrentHashMap解决并发Map，CopyOnWriteArrayList解决读多写少的场景。这些类内部已经用CAS、分段锁等手段解决了并发问题，比自己写synchronized要高效得多。

3.3 死锁是如何发生的

死锁是并发编程里最让人头疼的问题之一。四个必要条件缺一不可：互斥条件、持有并等待、不可剥夺、循环等待。

一个经典的死锁场景：线程A持有锁1，等待锁2；线程B持有锁2，等待锁1。两个线程都不释放自己手里的锁，互相等对方，程序就卡死了。

排查死锁有两个入口。一是用jstack抓线程快照，死锁的部分会明确显示“Found one Java-level deadlock”，并列出被锁住的线程和锁的持有者。二是arthas的thread -b可以快速找出阻塞了其他线程的线程。

避免死锁的常用手段：第一，尽量降低锁的粒度，不要一个方法里同时持有多个锁；第二，如果必须持有多把锁，保证所有线程按相同的顺序加锁；第三，使用tryLock超时机制，获取不到锁就放弃并释放已有锁，而不是无限等待；第四，能用无锁方案（CAS、原子类、并发容器）尽量用无锁方案。

4. 进程间通信与线程协作

4.1 进程间通信（IPC）的主流方式

进程之间是资源隔离的，一个进程没法直接访问另一个进程的内存，所以进程间通信（IPC）必须靠操作系统提供的机制。面试和实战中经常遇到的是这几种。

管道是最古老的IPC方式，分匿名管道和命名管道。匿名管道通常用于父子进程之间、具有亲缘关系的进程之间的单向通信，核心思想是“一端写、一端读”，数据在内核缓冲区里流动，Linux里用竖杠管道的命令行用法就是这种机制的体现。命名管道（FIFO）则允许无亲缘关系的进程通信，因为它在文件系统里有名字，通过一个路径来标识。

消息队列是内核维护的一个链表，进程往队列里投放消息，另一个进程从队列里读取消息。消息有类型和优先级，比管道更灵活。但消息队列有数据大小限制，且在内核和用户态之间拷贝有性能开销。

共享内存是所有IPC方式里效率最高的，因为它让多个进程直接映射到同一块物理内存，读写不需要通过内核拷贝。但问题是多个进程同时写会出现竞争，所以共享内存通常要配合信号量做同步互斥。这也是游戏引擎、高频交易系统等低延迟场景的惯用方案。

信号量不是用来传输数据的，而是用来控制多个进程对共享资源的访问同步。Socket则是最通用的手段，可以实现跨机器的进程通信，也就是网络通信。

我在实际项目里遇到过“孤儿进程”和“僵尸进程”的问题，这虽然不是通信问题，但和进程生命周期管理相关。子进程被父进程启动后，如果父进程挂了，子进程就变成孤儿进程，被init进程收养；如果子进程终止但父进程没有调用wait回收它的退出状态，子进程就变成僵尸进程。排查这类问题，用ps -ef看进程状态，STAT字段为Z的就是僵尸进程，解决办法是让父进程去wait，或者直接kill父进程让init帮忙清理。

4.2 线程间协作：等待通知与生产者消费者

线程之间的通信和进程不同，因为线程共享进程的内存空间，所以通信非常直接，难点在于协作的时机控制——如何让一个线程在合适的时候停下来等条件，在合适的时机被唤醒。

Java里最经典的是wait/notify机制。wait会让当前线程释放锁并进入WAITING状态，notify会唤醒一个在该锁上等待的线程，notifyAll唤醒全部。这个机制必须放在synchronized代码块中使用，因为wait和notify操作的都是对象监视器锁。

生产者消费者模式是wait/notify最典型的应用场景：一个线程负责生产数据，一个线程负责消费数据，中间用一个有界缓冲区衔接。缓冲区满时生产者wait，消费一个后notify；缓冲区空时消费者wait，生产一个后notify。

但官方其实更推荐使用JUC包里现成的工具，而不是自己写wait/notify循环。BlockingQueue就是为生产者消费者模式设计的，put和take自带阻塞效果，不需要手动加锁和wait/notify。所以后来我写业务代码，用BlockingQueue的场景远比手动wait/notify多。只有需要在多个条件之间灵活切换、或者需要精细控制等待唤醒时机时，才会考虑Condition。

守护线程也是一个经常被问到的概念。守护线程（Daemon Thread）是为主线程服务的，当JVM中所有非守护线程都退出后，守护线程会自动终止，不管它是不是执行到一半。典型应用是垃圾回收线程、监控统计线程。但注意，守护线程的“自动终止”是没法保证优雅退出的，如果它持有某些资源没释放，随JVM退出可能会丢失数据。所以涉及写日志、写数据库之类的操作，不建议用守护线程。

5. 从理论到排查：线上并发问题怎么管

5.1 看懂线程状态，快速定位卡顿

理论讲再多，最终都要落到“线上出问题怎么查”。我之前遇到过一个接口偶发超时的案例，表现是高峰期时大量请求耗时飙升，但重新调用又好了。当时我的排查路径是：先用jps拿到Java进程号，然后jstack输出线程快照，重点看线程状态分布。结果发现大量业务线程卡在BLOCKED状态，再往下看是集中在同一个对象监视器锁上，进一步处理，定位到一个工具类的静态SimpleDateFormat上——这是典型的线程安全问题，SimpleDateFormat不是线程安全的，多个线程同时format就把内部状态搞坏了。修复方式是改成ThreadLocal包装，或者直接用DateTimeFormatter。

这个案例说明，遇到并发问题，第一步不是猜，而是抓证据。jstack是最基本的手段，它能输出当前JVM所有线程的状态、调用栈、锁持有情况。拿到快照后，优先看TIMED_WAITING的线程数量是否异常多，再看BLOCKED的线程都卡在哪些锁上，最后看WAITING的线程在等什么条件。

arthas是阿里开源的诊断工具，比jstack更实时和灵活。启动arthas后，dashboard面板能实时查看所有线程的CPU占用和状态，thread -n 3可以查看CPU占用最高的三个线程，thread -b可以直接找出死锁阻塞的线程，watch、trace这些命令还能追踪具体方法的调用耗时和参数。我之前多次排查线上问题，arthas基本是首选，jstack作为补充。

5.2 查看进程与线程数量的实用命令

进程线程这层东西，光看理论图没用，要学会在系统里实际观测。Linux下查看进程和线程数量的命令是基本功，但很多人实际用不熟。

查看进程整体信息用ps aux，看PID、CPU占用、内存占用、启动时间、命令等。ps -eLf可以列出线程级别的信息，每一行是一个线程，LWP列就是线程号，NLWP是线程数量。

单独的线程树用top -H -p PID，可以实时显示指定进程内所有线程的CPU占用，配合jstack一起用，能快速定位CPU飙高的线程是哪个业务逻辑。具体做法是top -H拿到占用CPU最高的线程号（十进制），转成十六进制，再到jstack输出的线程栈里搜这个十六进制线程号，就能看到这个线程正在执行的代码。

查系统总线程数可以用ps -eLf | wc -l，或者cat /proc/loadavg里的第三个数字（当前可运行的线程数）。这些命令在排查“线程数是否过高”的时候非常有用，如果发现线程数异常暴涨，多半是线程池没复用好，或者有创建线程的代码在被反复执行。

5.3 典型问题与排查思路速查

结合我实战中的经验，整理了一些高频并发问题的排查思路，这些场景几乎每个做后端开发的人都会遇到。

这个表只是一个起点，真正遇到问题时，一定要结合日志、监控、线程快照综合判断。我见过太多人一上来就重启解决，重启确实能解决“症状”，但没解决“病因”。下次问题复现，还是要靠这些排查手段去定位根因。

最后分享一个实操中的小技巧：在Java服务中，建议启动参数里加上-XX:+HeapDumpOnOutOfMemoryError，并在代码里把线程池的线程名都设置成有业务含义的名字。这两个动作成本极低，但线上出故障时能让你的排查效率提升好几倍。另外，不管用不用容器技术，都要对进程和线程的资源占用敏感，多掌握几个Linux排查命令，很多看起来莫名其妙的故障，其实都是进程或线程层级的资源问题。