进程与线程：从底层原理到线程池与线上排错实战

1. 一次线上事故引发的思考：分清进程与线程不是选择题而是送分题

先讲个真实经历。去年我们有个Java服务偶发性卡顿，CPU不高但接口RT飙到十几秒，排查时发现JVM里线程数已经飙到了三千多。用jstack抓线程栈，看到大量线程阻塞在一个数据库连接池的获取连接处，但更诡异的是，从系统层面看，这个进程占用的内存并不高，可整个服务器却明显变慢，连top都会卡一下。后来才搞清楚，问题根本不是连接池不够大，而是我们给线程池配了无界队列，请求全堆在队列里，大量线程在等待执行结果，把线程调度和上下文切换拖垮了。

那次事故之后我意识到一件事：很多人写并发代码多年，对“进程”和“线程”的理解其实停留在背面试题层面，能说出来"进程是资源分配的最小单位，线程是CPU调度的最小单位"，但真到了线程池参数调优、锁竞争排查、进程通信方案选型的时候，这些基础知识完全用不上。原因很简单——概念是背的，原理是通的，但中间缺了一层"这东西在操作系统里到底怎么运作"的实感。

这篇文章我想把这层实感补上。从进程和线程的本质差异讲起，延伸到Java线程池、锁、通信机制这些日常最常碰到的实战场景，再分享一些我用过的排查思路和踩坑经历。适合正在学并发编程的初学者，也适合写了好几年业务代码、想在并发这块补补课的后端开发。我不打算把操作系统教材搬过来，而是把每个知识点都挂到实际工程问题上讲，保证你合上文章之后能直接拿去用。

2. 资源所有权与调度权：进程和线程各自的本质定位

2.1 进程是"套间"，线程是"套房里的房客"

我理解进程和线程的区别，喜欢用租房来类比。进程就是一个独立的套间，有自己的门牌号（PID）、独立的电表水表（内存地址空间）、独立的家具家电（文件描述符、打开的文件句柄），你在这个套间里怎么折腾，只要不砸承重墙，跟隔壁邻居一点关系都没有。如果某个进程崩溃了，比如C语言里空指针野指针乱飞导致段错误，顶多就是这一户的灯灭了，其他套间照常亮着。这就是进程隔离带来的稳定性价值。

线程就不一样了。线程是套间里住着的房客，大家共享客厅、厨房、卫生间（堆内存、方法区、文件描述符），但每个人都保留自己的私人物品（线程私有的栈、寄存器状态、程序计数器）。一个房客在厨房里烧水，另一个也能同时炒菜，这是真并行。但如果一个人在煤气灶上放了易燃物（堆里改了共享对象），另一个住户炒菜就可能把整栋楼点着——这就是线程间共享内存带来的数据竞争风险。

理解"进程里有多个线程，线程必须依附于进程存在"这件事，关键在于分清两个层面的所有权：

• 进程拥有的是资源的所有权：地址空间、页表、打开的文件、信号处理器、当前工作目录等。这些资源被进程内所有线程共享。
• 线程拥有的是执行的所有权：一组寄存器值、栈、程序计数器、线程局部存储。这些是线程私有的，切换线程只需要切换这些上下文信息。

这里有个面试常问的冷知识：为什么线程被称为"轻量级进程"？因为创建进程时，操作系统要分配独立的地址空间，要建立新的页表，要复制父进程的资源管理信息；创建线程时，只是在内核里多建一个调度实体，并让这个实体共享进程已有的地址空间。创建线程的开销通常比创建进程小一个数量级，线程切换也一样，上下文切换只需要保存和恢复寄存器、栈指针、程序计数器等轻量信息，不需要动页表，也就省掉了TLB（快表）刷新的开销。

2.2 切换代价背后的系统级差异

很多人对"线程切换成本低"这件事没有量化概念。一次进程切换，涉及到模式切换（用户态到内核态）、保存当前进程的完整上下文（寄存器、程序计数器、栈指针）、切换页表基地址寄存器、刷新TLB、再加载新进程的上下文。其中TLB刷新之后，新进程访问内存几乎每条指令都可能触发一次页表遍历的缺失，代价非常高。而线程切换虽然也要经过内核，但因为地址空间不变，页表不用切，TLB还能继续命中，所以速度快得多。

操作系统面试题常问"进程和线程的切换过程"，实际工作中没几个人真的去关注那几个汇编级别的步骤，但理解切换成本会直接影响你的工程判断。举个例子：如果你的业务场景是"大量短小任务频繁执行，且任务之间存在数据共享"，那多线程是合理选择——切换成本低，共享数据方便。如果你的场景是"多个任务之间完全独立、需要强隔离、有某个任务挂了不能拖累别人"，那多进程更合适，比如Chrome每个标签页一个进程就是典型。

还有个更现代的问题值得注意：协程和虚拟线程出现之后，"线程一定比进程轻量"这句话越来越不绝对了。Java 21的虚拟线程是JVM在用户态调度的，创建几十万个虚拟线程都没问题，但真正的平台线程（也就是操作系统线程）数量依然受内核资源限制。热搜词里那个"os线程和jvm线程"的问题，问的就是这个映射关系：

• 早期的Java绿色线程是JVM自己调度，不映射到内核线程，但现在已经不是主流。
• 现在的HotSpot虚拟机默认是1:1线程模型，一个Java线程对应一个内核线程。
• 虚拟线程是M:N模型，M个虚拟线程映射到N个内核线程上，由JVM负责调度哪些虚拟线程在哪个载体线程上执行。

理解了这个映射关系，很多问题就能解释。比如你用jstack看到的Java线程栈，其实对应着操作系统里的一个真实内核线程；又比如Java线程在等待synchronized锁时，会让出CPU，对应内核线程进入SLEEPING状态，这就是为什么高并发下线程数越多、操作系统调度压力越大。

3. 当共享引出事故：线程安全的底层来源

3.1 共享内存、竞态条件与三要素

明确了线程共享进程资源之后，线程安全问题的根源就浮出水面了：多线程并发访问共享可变状态，产生了竞态条件。具体说，一个共享变量在代码里的"读-改-写"操作序列，可能被多个线程交错执行，导致最终结果不符合预期。

看这个最简单的案例：

java复制public class Counter {
    private int count = 0;
    public void increment() {
        count++;  // 看起来像一行，实际上是三条指令：读count、加1、写回count
    }
}

两个线程同时执行count++，在字节码层面是：先从堆里把count的值读到栈上，然后把栈上的值加1，再把结果写回堆。两个线程交错执行的路径很多，极端情况下两次increment()执行完，count只增加了1。这就是典型的"检查再执行"或"读取-修改-写入"竞态。

线程安全要解决的三个核心问题是：原子性、可见性、有序性。

• 原子性：一个操作或者多个操作要么全部执行且不被中断，要么全部不执行。count++不是原子操作，所以需要加锁或使用AtomicInteger。
• 可见性：一个线程对共享变量的修改，另一个线程什么时候能看到？由于CPU多级缓存的存在，线程A改了count的值，可能只写到了CPU的L1/L2缓存，还没有刷新到主内存，线程B读到的还是旧值。volatile关键字解决的就是这个问题：写volatile变量时，JVM会插入内存屏障，强制把缓存中的修改刷到主内存；读volatile变量时，强制从主内存重新拉取。
• 有序性：编译器、CPU为了优化可能对指令进行重排，单线程内重排不影响结果，但多线程下可能出问题。经典的DCL单例双重检查锁就是典型的指令重排受害者，所以才需要volatile来禁止重排。

3.2 synchronized、Lock与并发工具类该怎么选

明白了问题来源，锁的用法就好理解了。synchronized和ReentrantLock是Java里最常用的两把互斥锁，我实际工程里总结了这样几条选择标准：

synchronized适合大多数场景。它用法简单，写在哪里就是哪里起作用；JVM层面做了大量优化，锁粗化、锁消除、偏向锁、轻量级锁、重量级锁的升级路径都是自动的；出现异常时JVM会自动释放锁，不用担心死锁（但别忘了，如果代码里自己写了复杂的等待逻辑，该死锁还是会死锁）。

ReentrantLock适合以下场景：

• 需要可中断地获取锁，调用lockInterruptibly()可以在等待锁的过程中响应线程中断。
• 需要尝试非阻塞获取锁，tryLock()拿不到锁就立刻返回false，可以配合超时时间避免无限等待。
• 需要公平锁，new ReentrantLock(true)，让等待时间最长的线程先拿到锁。
• 需要多个条件变量（Condition）精细化等待通知控制。

这里给一份我做并发HTTP调用时常用的代码模板，用synchronized实现一个简单的限流器：

java复制public class SimpleRateLimiter {
    private final int maxRequestsPerSecond;
    private int tokens;
    private long lastRefillTime;

    public SimpleRateLimiter(int maxRequestsPerSecond) {
        this.maxRequestsPerSecond = maxRequestsPerSecond;
        this.tokens = maxRequestsPerSecond;
        this.lastRefillTime = System.currentTimeMillis();
    }

    public synchronized boolean tryAcquire() {
        long now = System.currentTimeMillis();
        // 按时间窗口补充令牌
        if (now > lastRefillTime) {
            long elapsedMs = now - lastRefillTime;
            int refill = (int) (elapsedMs / 1000.0 * maxRequestsPerSecond);
            tokens = Math.min(maxRequestsPerSecond, tokens + refill);
            lastRefillTime = now;
        }
        if (tokens > 0) {
            tokens--;
            return true;
        }
        return false;
    }
}

在实际工程里，我的建议是：能用并发工具类就不用显式锁。ConcurrentHashMap替代手动加锁的HashMap、AtomicInteger替代synchronized保护的计数器、BlockingQueue替代自己用锁和条件变量实现的队列，这些都是经过反复锤炼的轮子。手写锁的最常见错误场景，就是在分布式锁还没引入时，用synchronized去锁一个多实例部署的服务里的本地对象——那只能锁住自己进程里的线程，对集群里的其他节点没有任何约束力。

3.3 从jstack看锁和线程状态的真实面貌

纸上谈兵半天，落到实践最重要的是能观察。当线上出问题时，我第一反应是执行jstack <pid>抓线程快照。线程的状态会告诉你它是死锁了、饥饿了、还是纯粹在等待IO。

bash复制jstack 12345 > jstack_20250115.log

重点关注几类状态的分布：

• RUNNABLE：线程正在执行，但注意，JVM层面的RUNNABLE不代表线程真的在CPU上跑，可能在等待IO，也可能因为操作系统时间片轮转暂时没拿到CPU。
• BLOCKED：线程在等待monitor lock进入synchronized块。如果大量线程BLOCKED在同一个锁对象上，说明锁竞争很激烈，需要考虑优化临界区范围或者改用读写锁。
• WAITING：线程调用了wait()、join()、park()等，在等待被唤醒。这个状态下不消耗CPU。
• TIMED_WAITING：在等待有超时的操作，比如sleep()、带超时的wait()。

死锁的jstack最直观，最后会打印一行"Found one Java-level deadlock"，并且明确指出两个线程各持有什么锁、在等待什么锁。排查思路就是顺着线程栈找到每个线程持有的锁和等待的锁，看能否构成环。

4. 线程池的核心参数与阻塞队列选型：别让线程管理变成事故现场

4.1 为什么手动new Thread是慢性自杀

为了控制线程数量、复用线程、统一管理生命周期，Java里诞生了线程池。但很多团队的代码里，线程池配置是拍脑袋写的，核心线程数是不是合理完全没验证。手动new Thread()导致的问题是：每次请求都创建新线程，线程创建和销毁开销大；高并发下线程数无限膨胀，操作系统调度的开销急剧上升，最终内存耗尽或者触发操作系统的线程限制；而且没有队列缓冲，瞬间流量洪峰直接打垮应用。

线程池解决了以上问题，但配置不合理又会带来新问题。先说一个最常见也最基本的误区——任务在ThreadPoolExecutor中的执行流程被太多人记反了。正确的流程是：

1. 提交任务后，如果当前运行的线程数小于corePoolSize，创建新线程执行任务（即使有空闲线程也会先建新的）。
2. 如果运行的线程数达到了corePoolSize，新任务会被放入阻塞队列等待。
3. 如果队列满了，且运行的线程数小于maximumPoolSize，创建新的非核心线程执行任务。
4. 如果队列满了，且运行的线程数达到maximumPoolSize，执行拒绝策略。

注意第二步到第三步的条件关系：先入队，队列满了才尝试创建新线程到maximumPoolSize。这是很多人搞错的点——他们以为核心线程满了就直接创建新线程，实际上中间还有一个"塞队列"的步骤。

4.2 核心线程数与队列的配合逻辑

线程池的核心参数本质上是同一类问题的三个开关：任务提交速率、线程处理速度、队列缓冲能力。配置核心线程数和队列长度时，要先想清楚业务场景：

• CPU密集型任务：核心线程数建议设为CPU核心数 + 1或CPU核心数。因为CPU密集任务几乎不会主动让出CPU，线程数超过核心数时，额外线程只会增加上下文切换开销。如果你机器是8核，给CPU密集任务配20个核心线程是灾难。
• IO密集型任务：线程处理过程中有大量阻塞等待（网络请求、磁盘IO、数据库查询），线程在等待时CPU是空闲的，可以多放几个线程提高CPU利用率。经验值是CPU核心数 * 2，或者更精细的公式：CPU核心数 / (1 - 阻塞系数)，其中阻塞系数在IO密集型场景通常在0.8~0.9之间，算出来大约就是CPU核心数的5~10倍。
• 混合型任务：如果能拆分，把CPU密集部分和IO密集部分拆成不同的线程池分别调优。如果无法拆分，按IO密集来配，但要对线程池的任务执行时间做监控。

队列选型也直接决定了系统的削峰行为。看一张常用的对比表：

我曾经犯过一个经典错误：给IO密集场景配了一个无界LinkedBlockingQueue，核心线程数8、最大线程数16。结果某天大促流量进来，任务提交速度远超处理速度，队列快速积压了几百万个任务，内存直线上升，最后GC把CPU吃满，服务直接假死。那次事故教育了我：队列长度一定要有界，配合合理的拒绝策略，宁可丢弃一部分流量也不能让JVM被队列拖死。

4.3 拒绝策略不是终点，而是兜底

当队列满了、线程数也到上限了，新提交的任务就会触发拒绝策略。ThreadPoolExecutor提供了四种内置策略：

我个人最常用的组合是：有界ArrayBlockingQueue + CallerRunsPolicy。有界队列把内存占用控制住；CallerRunsPolicy在任务满时会让提交任务的线程自己执行，等于变相背压——上游线程在忙着执行任务时，自然不会再继续狂发请求，系统的吞吐会被自动调节到可承受的速率。对于不能丢消息的业务，可以用自定义的RejectedExecutionHandler把任务转存到消息队列里做异步补偿，而不是直接丢弃或原地执行。

5. 进程间通信与线程间通信：从数据共享到协作模式

5.1 为什么进程通信要绕那么多弯子

进程和线程的另一个核心差异是通信方式。线程之间共享进程的内存空间，只要做好同步（锁、volatile、并发工具类），数据传递是直接的。有的线程改一个变量，另一个线程立刻就能读到新值（前提是可见性被正确处理）。这种通信方式的优点是快，缺点是程序员要为共享数据的正确性负责。

进程之间则拥有独立的地址空间，一个进程的变量在另一个进程里根本不存在，所以必须由操作系统或运行时提供专门的通信机制。热搜词里的“进程通信（IPC）”指的就是这些方案：管道（Pipe）、消息队列（Message Queue）、共享内存（Shared Memory）、信号量（Semaphore）、信号（Signal）、套接字（Socket）。

这里有个判断不同IPC方案优劣的通用思路——本质上是"拷贝次数"和"同步复杂度"的权衡：

• 管道：数据在内核缓冲区里流动，写端拷贝一次到内核，读端从内核拷贝一次到用户态。两次拷贝，实现简单，适合单向、流式的数据传输。命令行里的ps aux | grep java就是典型的管道用法。
• 消息队列：数据以消息为单位，内核帮忙做了一次消息边界管理，但同样是两次拷贝，而且消息大小受限。
• 共享内存：最原始也最快——双方把同一块物理内存映射到各自的地址空间，通过指针直接读写。数据零拷贝，延迟最低，但必须配合信号量或锁来保证同步，否则就是两个人同时改同一块白板，互相覆盖。

做高性能本地通信时我首选共享内存，比如交易系统里需要极低延迟的行情转发或信号传递，一个进程把最新行情写到共享内存，另一个进程直接读，性能能达到几十纳秒级别。但在大部分分布式系统中，进程往往分布在不同的物理机上，共享内存没有用武之地，这时Socket（尤其是TCP）成为最通用的IPC桥接方案。这就是为什么现在很多应用之间"进程通信"和"网络通信"被混为一谈——因为物理隔离后，两者本质上都是通过网络协议栈拷贝数据。

5.2 线程通信的正确姿势与经典陷阱

线程间通信不只是共享变量这一个维度，还有"一个线程完成某件事后通知另一个线程"的场景。Java里最原始的方案是wait()/notify()，配合synchronized使用；更优雅的方案是Condition；再往上则是各种封装好的并发工具，比如CountDownLatch、CyclicBarrier、Semaphore、CompletableFuture。

举一个用CompletableFuture组织线程协作的真实案例。我们需要并发调三个下游接口——查用户信息、查订单列表、查优惠券，三个都完成了再聚合结果返回给前端。用new Thread + CountDownLatch虽然能实现，但代码又长又容易出问题；用CompletableFuture简洁得多：

java复制public CompletableFuture<UserDetailResponse> buildUserDetail() {
    CompletableFuture<UserInfo> userInfoFuture = CompletableFuture
            .supplyAsync(() -> userClient.getUserInfo(userId), userInfoPool);
    CompletableFuture<List<Order>> orderFuture = CompletableFuture
            .supplyAsync(() -> orderClient.listOrders(userId), orderPool);
    CompletableFuture<List<Coupon>> couponFuture = CompletableFuture
            .supplyAsync(() -> couponClient.listCoupons(userId), couponPool);

    return CompletableFuture.allOf(userInfoFuture, orderFuture, couponFuture)
            .thenApplyAsync(ignored -> {
                UserDetailResponse response = new UserDetailResponse();
                response.setUser(userInfoFuture.join());
                response.setOrders(orderFuture.join());
                response.setCoupons(couponFuture.join());
                return response;
            }, composePool);
}

线程协作最常见也最隐蔽的陷阱是"无界等待与死锁的孪生兄弟"。场景是这样的：线程A持有了锁L1，正在等待线程B的结果；线程B执行时需要锁L1才能完成计算，但锁被A占着。两个线程互相等待，形成死锁。这类问题在线程池里更阴险——如果你的任务在线程池里又向同一个线程池提交了子任务并等待子任务的结果，子任务永远没有空闲线程去执行，整个池子会慢慢全部阻塞。这就是线程池饥饿死锁，排查jstack时看到所有线程WAITING在自己的Future.get()上基本就是了。

解决方案有三个方向：

1. 父子任务拆分到不同的线程池，根据任务特点分别调优。
2. 使用异步回调而不是同步阻塞等待，避免占着线程等结果。
3. 对Future.get()和CompletableFuture.get()设置超时时间，宁可超时失败重试也不要无限期等下去。

我的经验是，第三条是保底做法，任何涉及Future.get的地方都建议设置超时。哪怕你确认逻辑不会死锁，也挡不住下游服务挂掉导致线程永远得不到结果。

6. 进程/线程实战排错实录：从启动失败到无法终止

6.1 Windows下"终端进程启动失败"与ConPTY的锅

搜索热词里有几条Windows环境的高频问题，比如"终端进程启动失败: 启动期间发生本机异常(无法启动 conpty)"和"已移除 winpty"。这两个问题我确实遇到过，值得单独聊聊。

ConPTY是Windows用来支持伪终端（Pseudo Console）的机制，很多编辑器集成的终端、以及Git Bash、WSL终端，底层都是走ConPTY来模拟Linux终端行为的。出现"无法启动ConPTY"的报错，常见原因有这几个：

• 终端程序本身不是以管理员权限运行的，而ConPTY需要访问一些系统资源被拦截。
• Windows Terminal版本过旧，与当前系统的ConPTY接口不兼容。
• 有第三方程序劫持或干扰了终端创建进程的调用链。

Winpty则是Windows上一个开源的工具，作用是让MSYS2/Git Bash里的程序（比如Python、Node的交互式shell）能正常在Windows终端里运行。Git Bash 2.7版本之前默认使用winpty适配交互式程序，后来新版Git Bash逐渐移除了对winpty的依赖，转而使用原生ConPTY。所以如果你用的终端版本和Git Bash版本之间有错位，就可能出现"已移除winpty"的提示。

这类问题的通解思路是：先看是终端本身启动失败还是终端里跑的程序启动失败，再围绕ConPTY版本兼容排查，必要时更新Windows Terminal和Git for Windows到最新。这个案例的通用价值不在于解决ConPTY本身，而在于提醒大家：很多所谓"进程启动失败"不是你的代码问题，而是宿主环境对进程创建的方式做了限制。在Windows上跑Java进程、跑Python脚本遇到类似问题，先检查执行终端是否兼容，再检查是不是杀毒软件或安全策略拦了进程创建。

6.2 "进程被占用无法删除"和"无法杀死进程"的Windows排查链路

Windows下删除文件提示"被另一程序占用"，或者想结束进程但任务管理器没权限，这类问题几乎每周都有人问。完整排查流程我建议这样走：

1. 用tasklist列出所有进程，根据文件名定位可疑的占用进程。
2. 更精准的方式是用微软官方的handle.exe（Sysinternals工具包）搜索哪个进程持有该文件的句柄：

bash复制handle.exe 你要删除的文件路径

3. 定位到PID后，用taskkill强制结束：

bash复制taskkill /F /PID 12345

如果强制结束也被拒绝，可能原因是：进程以System权限运行、当前用户没有SeDebugPrivilege权限、或者进程在更高级别的会话里。此时可以用openfiles命令查看系统打开的远程文件，或者直接重启操作系统解决（最后一招，通常在开发环境用）。

Linux下的对应问题是"文件已在其他程序打开"，排查用lsof：

bash复制# 查看某个文件被哪个进程占用
lsof /path/to/file

# 查看某个进程打开了哪些文件
lsof -p 12345

实战中我遇到最多的情况是：Java应用在用FileOutputStream写日志时抛了"文件被占用"，排查后发现是日志框架的异步Appender持有文件句柄没有释放。这类问题的本质是"资源生命周期没人管"，所以排查之后不要只杀进程了事，要回头检查代码里有没有正确关闭文件流、连接池、临时文件。顺手说一句，Java 7之后建议所有IO资源都用try-with-resources，可以少踩一半资源泄露的坑。

6.3 Linux下如何查看和管理进程与线程数量

Linux系统排查线程问题，最实用的是这几条命令：

bash复制# 查看某进程下的所有线程（显示线程ID）
ps -eLf | grep java

# 实时查看进程内各线程的CPU占用（相当于Linux下的jstack加强版）
top -Hp 12345

# 查看系统总线程数
cat /proc/sys/kernel/threads-max

遇到CPU飙高的问题，我的排查顺序是：先用top定位到CPU吃满的进程PID，再用top -Hp把这个进程的线程按CPU占用排序，找到异常线程的TID。TID是十进制，但Java线程栈里的nid是十六进制，需要换算。比如printf "%x\n" 12345得到十六进制TID，再去jstack日志里搜索对应的nid=0x...，就能定位到具体是哪个Java线程在烧CPU。

很多"线程数爆炸"的故障，在Linux下的表现就是ps -eLf看到某个进程的线程数几百上千。Java标准线程栈默认1MB，三千个线程意味着至少3GB虚拟内存被划给了线程栈，虽然物理内存不会一次全占，但对内存的碎片化影响是实实在在的。这也呼应了我开头讲的线上事故：无界队列导致任务积压，每个任务都睡在Future.get()上等结果，线程池不得不不断新建线程处理看似源源不断的请求，最终线程数爆表。

在排查线程、进程问题时，有一个隐藏的基本功值得反复强调：区分系统视角和语言运行时视角。操作系统看到的线程不等于Java线程。Java线程可能会在JVM内部做一些用户态的调度和包装，所以OS层面看到一个进程线程数高，先别急着强行杀死线程，要用jstack看这些线程在干什么，是业务任务、GC线程、还是编译线程（JIT Compiler），再决定怎么处理。

7. 我的实操体会与三个值得长期坚持的习惯

整个并发编程的知识体系铺开讲完，我自己实际操作中最深刻的体会是：进程线程这块知识，广度不重要，深度才重要。不需要背几千条API，但一定要能回答"为什么"——为什么线程池要用有界队列？为什么线程共享内存却容易出数据问题？为什么进程通信的代价明显高于线程通信？这些"为什么"想通了，碰到线上故障才有推理的依据，而不是瞎猜乱试。

最后分享三个我长期坚持的习惯，算是给这篇文章收个尾。

第一个习惯是：写任何并发代码之前，先画清楚线程模型。哪怕是粗略画一下有几个线程池、任务在它们之间怎么流转、共享状态在哪里，也能拦住大量潜在的线程安全设计缺陷。很多并发Bug不是代码写错了，而是从设计那一刻起就没想清楚谁在写、谁在读、谁在等。

第二个习惯是：凡是涉及阻塞等待的地方，永远不让它"永远等待"。Future.get()要设超时，Redis连接池读写要有timeout，消息队列消费要设置消费超时。并发场景下，一个无超时的等待，轻则拖慢响应，重则把整条调用链拖死。

第三个习惯是：平时多存几个jstack快照作为"参照物"。服务正常时的线程快照、CPU高时的快照、慢调用时的快照，每种异常各留一份。下次再出问题时拿异常快照和正常快照对比，往往一眼就能看出哪个线程池不对劲、哪个锁竞争是新出现的。我的故障排查经验里，一半以上都是靠这个对比方法快速定位的。