线程过多导致系统性能崩坏？从线程池参数到死锁排查全解析

你有没有遇到过这种情况：系统上线前压测一切正常，上线后跑个把小时，线程数噌噌往上涨，几百上千个线程堆在那儿，CPU占用率飙到 90% 以上，接口响应从几十毫秒变成几十秒，最后连健康检查都挂了，整个服务像死了一样。

我之前排查过不少这种问题，根子往往不在业务代码有多复杂，而是线程开得太随意了。很多人有个错觉，觉得“多开线程 = 多核并行 = 性能更好”，实际上线程是操作系统里的重量级资源，每个线程都有独立的栈空间、内核调度实体，线程一多，光上下文切换就能把 CPU 吃干净。这篇文章我就围绕“如何避免线程过多导致的系统性能问题”这个核心，把线程开销的来源、线程池参数怎么配、跨语言场景下的线程管理、死锁与互斥的排查这些内容一次讲透。适合后端开发、客户端开发、运维和所有被线上线程问题折磨过的朋友。

1. 线程一多系统就卡？先弄清楚线程开销花在哪

1.1 线程不是免费的：内存与内核资源开销

先说一个最容易被忽略的事实：线程是操作系统管理的资源，不是你想要就能随便造的。Java 里new Thread()创建一个线程，底层会调用系统线程创建接口，在 Linux 上就是一个pthread，这个线程有自己独立的栈空间、线程局部存储、内核栈，还有一块用于保存线程上下文的内存。

具体占多大？Java 线程默认栈大小在 64 位 JVM 上一般是 1MB，Linux 上的原生线程栈默认是 8MB，C# 的线程栈默认 1MB，Windows 上可调。你算一下，如果 Java 服务开了 1000 个线程，光栈空间就预留了 1GB 虚拟内存，虽然不会全部驻留物理内存，但线程真正使用到的栈深度一旦涨上去，物理内存的消耗就实打实了。更关键的是，每个线程对应一个内核调度实体（无论是 1:1 还是 M:N 模型，现代主流 JVM 基本上都是 1:1 映射到内核线程），内核需要为每个线程维护调度信息，线程数一多，内核本身的开销就上去了。

网上那些“线程数开个几千没问题”的说法，在内存充足、线程空转的场景下也许能撑住，但只要线程真正干活，栈内存和内核对象的压力立刻显现。我自己测过，一个空转线程大概占 300KB 左右的内存，10000 个空转线程就是 3GB 内存消失不见，这还没算线程之间交互带来的锁开销。

1.2 上下文切换是隐藏的性能杀手

线程太多最大的坑其实是上下文切换。CPU 核心数是有限的，假设你机器有 8 核，同时只有 8 个线程能真正执行，其他线程都在等待。操作系统要不停地在这些线程之间切换，每次切换都要保存当前线程的寄存器状态、程序计数器、栈指针，然后加载下一个线程的状态，这个过程叫上下文切换。

上下文切换的成本有多高？一次切换大概是微秒级别的开销，听起来不多，但如果线程数量远超 CPU 核数，每秒会发生成千上万次切换，这些切换本身消耗的 CPU 时间就非常可观。有个经验数据：当线程数是 CPU 核数的 10 倍以上时，线程调度和切换开销可能占到 CPU 总消耗的 30% 甚至更高。

更隐蔽的是缓存失效问题。线程切换后，CPU 的一级缓存、二级缓存、TLB（页表缓存）里存的都是上一个线程的数据，新线程的数据不在缓存里，就要频繁去内存里取，这就是“缓存冷启动”开销。线程切换越频繁，缓存命中率越低，程序实际执行速度越慢。

还有一个连锁反应：线程多了，锁竞争也会加剧。多个线程同时访问共享数据时，为了线程安全需要加锁，线程越多，抢锁的等待时间越长，甚至出现“线程多到都在等锁，活没干多少”的现象。可以说，线程数和性能之间不是线性关系，而是一条先上升后急剧下降的曲线。

1.3 线程数量控制在多少才算合适

既然线程太多不行，那多少个才算合理？这取决于任务类型。一般分两类：

• CPU 密集型任务：比如大量计算、编解码、图像处理，这类任务几乎不阻塞，线程数设置为CPU 核数 + 1是比较经典的配置。
• IO 密集型任务：比如网络请求、数据库操作、文件读写，线程大部分时间在等待 IO，可以设置更多的线程，常见经验值是CPU 核数 * 2或者更高，具体可以用公式线程数 = CPU 核数 * (1 + 平均等待时间 / 平均计算时间)来估算。

举个例子，假设一个任务平均计算 20ms，然后要等待数据库查询返回 80ms，那1 + 80/20 = 5，8 核机器就可以开 40 个左右的线程。这个数不是拍脑袋定的，是有依据的：线程数太少，CPU 在等待 IO 的时候空转；线程数太多，上下文切换和锁竞争又把 CPU 消耗掉，所以存在一个最优点。

我之前调过一个服务，接口里要做一次远程 RPC 和一次数据库查询，平均耗时 150ms，其中计算只有 10ms。最初线程池配了 64 个线程，压测 QPS 只有 850；我按公式调成线程池 24 个线程以后，CPU 占用下降 40%，QPS 反而涨到了 1200。原因很简单，线程少了，上下文切换少了，CPU 都在干正事。

2. 线程池：先选型再启动，参数怎么配才算合理

2.1 为什么线程池能解决线程过多问题

靠“自觉控制线程数”在开发阶段还行，但一到生产环境就失控了——有的是并发量突增，有的是代码里漏了回收，线程数直接失控。要根治“线程过多导致的性能问题”，最主流的手段就是线程池。

线程池的思路很简单：提前创建一批线程放在池子里，任务来了直接交给池里的线程执行，执行完线程不销毁，继续接下一个任务。它解决了三个核心问题：

• 限制线程总数：线程池有最大线程数上限，超过这个数的新任务进队列等待或者被拒绝，线程数不会无限膨胀。
• 复用线程：线程执行完任务后不销毁，省去了反复创建和销毁线程的巨大开销。
• 统一管理：线程池可以统一配置核心线程数、队列容量、拒绝策略，还能监控线程池状态。

可以这样理解：线程池就像一个固定的工人团队，生意再好也不临时招几千人，而是把订单放进排队区，等工人空闲了再处理。

2.2 核心参数逐个拆解

Java 的ThreadPoolExecutor是使用最广泛的线程池实现，它有 6 个核心参数：

参数	作用	备注
corePoolSize	核心线程数，常驻线程，不被回收	即使空闲也保留
maximumPoolSize	最大线程数，线程池允许创建的最大线程数量	必须大于等于 corePoolSize
keepAliveTime	非核心线程的空闲存活时间	超过这个时间没任务就会被回收
workQueue	任务阻塞队列	核心线程都在忙时，新任务进队列
threadFactory	线程工厂，用于创建线程	可以用来给线程命名、设置优先级
handler	拒绝策略，队列也满时的处理方式	默认是抛异常

ThreadPoolExecutor处理任务的流程有一个经典的“四步走”逻辑，先看核心线程有没有空闲，没有就尝试往任务队列里放，如果队列也满了，尝试创建新线程直到达maximumPoolSize，最后还不行就走拒绝策略。理解这个流程特别重要，因为很多参数配置错误都出在没搞懂“核心线程”和“队列”的配合顺序上。

举个例子：核心线程数设置 10，队列容量设置 200，最大线程数设置 20。当任务量在 10 个以内时，核心线程处理；任务增加到 10～210 个时，核心线程全部忙，新任务先进队列排队；任务量超过 210 个时，才会创建第 11～20 个线程来处理；如果连 20 个线程都处理不过来，队列也满了，后面来的任务就触发拒绝策略。

很多人有个误区，以为先开满最大线程数再进队列，实际上线程池的默认流程恰恰相反：优先用队列缓冲任务，队列满了才增加线程数。这一点直接决定了你在突发流量下是“排队等”还是“多开线程跑”，要根据业务特性来取舍。

2.3 参数配置经验：别照搬网上的公式

线程池参数没有银弹，必须结合任务类型来配。网上常见的公式可以作为起点，但一定要结合压测结果调优。

我自己的经验是这样：

• 核心线程数（corePoolSize）：根据“平时大多数时间”的并发量来设置，让绝大多数请求在线程池常态运行时不触发额外的线程创建。一般取CPU 核数 * 2作为起点，如果是 IO 密集型且等待时间占比高，可以适当加大。
• 最大线程数（maximumPoolSize）：根据“高峰期最大能接受多少并发”来设置，一般不超过核心线程数 * 2，再往上增加的吞吐收益很小，反而会增加上下文切换。
• 队列容量：这是很多人忽略的参数。如果用的是无界队列（比如默认的LinkedBlockingQueue不设容量），意味着任务永远不会满，拒绝策略永远不会触发，maximumPoolSize形同虚设。我强烈不建议生产环境用无界队列，一旦任务积压，线程池里的任务会越堆越多，内存被打爆，服务直接 OOM。

拿一个真实项目举例：一个消息推送服务，平时每秒推送 200 条消息，每条消息要做一次远程 HTTP 调用，耗时约 100ms。当时的配置是：

new ThreadPoolExecutor( 16, // 核心线程数 32, // 最大线程数 60L, TimeUnit.SECONDS, // 非核心线程空闲 60 秒后回收 new ArrayBlockingQueue<>(1000), // 有界队列，容量 1000 new NamedThreadFactory("push-thread"), // 自定义线程工厂 new CallerRunsPolicy() // 拒绝策略：调用者执行 );

这个配置计算逻辑是：要支撑每秒 200 条消息，每条耗时 100ms，需要并发线程数为200 * 0.1 = 20个左右，所以核心线程 16 略低，但配合队列容纳突发流量是足够的。最大线程 32 是为了应对突然的流量高峰，如果再高就会因为 HTTP 连接数限制而失去意义。队列 1000 是为了给突发流量一个缓冲，同时也有限流作用，超过 1000 就触发拒绝策略。

2.4 阻塞队列怎么选：这是个关键决策

线程池的性能和稳定性，很大程度上取决于队列的选择。这往往是新手最容易踩的坑，我单独拿出来详细说。

• ArrayBlockingQueue：有界数组阻塞队列，容量固定，必须指定大小。适合用来限制任务积压数量，防止内存爆炸。默认使用非公平锁，可以通过构造函数指定公平锁策略，但会牺牲一部分吞吐量。这是我最推荐的生产环境队列。
• LinkedBlockingQueue：链表阻塞队列，默认容量是Integer.MAX_VALUE，也就是无界。如果用它作为线程池队列，意味着线程池永远不会触发拒绝策略，任务会一直堆积直到 OOM。如果你一定要用，请务必在构造时指定容量。
• SynchronousQueue：同步队列，不存储任务，每个插入操作必须等待另一个线程的移除操作，相当于“手递手”交接。配合比较大的maximumPoolSize使用，可以实现“无线程可复用就直接创建新线程”的效果。适合任务本身比较重、不希望在队列中等待的场景。
• PriorityBlockingQueue：优先级队列，任务可以按优先级执行，但要注意同一个线程池里放不同优先级的任务，低优先级任务也有可能被饿死。

队列的选择直接决定了线程池面对突发流量时的表现。如果你的业务不希望请求在队列里等待太久，可以用SynchronousQueue+ 大最大线程数；如果希望削峰填谷，就选较大的有界队列；如果宁可丢弃一些非核心任务也不愿意拖垮系统，就选无界队列配拒绝策略——但这里说的无界是“容量很大的有界”，不是完全无界。

2.5 拒绝策略的取舍

拒绝策略在线程池里有四种：

• AbortPolicy（默认）：直接抛RejectedExecutionException异常。坏处是调用方可能没处理这个异常，导致任务丢失，甚至业务报错。
• CallerRunsPolicy：任务直接在调用方的线程里执行，相当于“谁提交的谁执行”。好处是不丢任务，而且能起到反向压力作用——调用方被占用了，自然会放慢提交速度。坏处是影响调用方自身的响应时间。
• DiscardPolicy：静默丢弃任务，不报错。坏处是任务无声无息地丢了，排查问题非常困难。
• DiscardOldestPolicy：丢弃队列里最老的任务，然后尝试重新提交新任务。适合希望保留最新任务的场景。

实际项目中我几乎不用默认的AbortPolicy，因为生产环境的接口调用方不会每个都处理这个异常，很容易变成 500 错误。我用的最多的是CallerRunsPolicy，它不像丢弃策略那样丢失任务，又能通过调用线程被占用来实现天然限流。但要注意它的一个副作用：如果调用方是热路径上的请求线程，响应时间会被拉长，所以要在压测时确认这个影响在可接受范围内。

3. 线程池配置完只是开始：任务拆分、隔离与监控

3.1 按业务类型拆分多个线程池，而不是一个大而全的池

很多人图省事，整个应用只创建一个全局线程池，所有业务任务往里丢。这在并发量低时没太大问题，一旦某个业务出现慢查询或者依赖的接口变慢，所有使用同一个线程池的业务都会被拖垮。这就是“线程池污染”，也叫“雪崩效应”。

正确的做法是按业务类型隔离线程池。举个例子，一个电商系统里，订单查询接口依赖数据库，支付回调接口依赖第三方 HTTP，日志上报接口依赖本地磁盘 IO。这三个接口的延迟特征完全不同，如果混用一个线程池，支付回调的阻塞会占满线程池里的线程，导致订单查询被阻塞，甚至日志上报也受影响。

我负责过的一个后台管理服务就遇到过这种情况：用户导出报表的任务特别重，一旦有人导出大批量数据，线程池里几乎所有的线程都被导出任务占住，其他列表查询接口全部超时。后来把导出任务单独放到一个线程池，核心线程只有 2 个，最大线程 4 个，队列容量 100，其他接口用另一个线程池。之后再出现大导出，也只影响导出本身，其他接口稳如老狗。

3.2 给线程起好名字，配好异常处理

这是个小技巧但对排查问题帮助极大。用ThreadFactory给线程池里的线程命名，比如order-pool-thread-1、push-pool-thread-2。这样出问题时，用jstack或者 Arthas 查看线程栈，一眼就能看出是哪个业务池子出了问题，不需要去对照线程 ID 猜。

ThreadFactory namedThreadFactory = new ThreadFactory() { private final AtomicInteger idx = new AtomicInteger(0); @Override public Thread newThread(Runnable r) { Thread t = new Thread(r); t.setName("order-pool-thread-" + idx.incrementAndGet()); t.setDaemon(false); t.setUncaughtExceptionHandler((thread, throwable) -> { // 记录异常日志，可以做告警 }); return t; } };

同时一定要给线程设置UncaughtExceptionHandler，否则线程执行过程中抛出的未捕获异常会被线程池吞掉，任务失败了你根本不知道。

3.3 线程池监控：不监控的池子等于裸奔

线程池配好了，如果没有监控，就像一个没装仪表盘的发动机。线程池运行到瓶颈、任务积压、拒绝策略触发，这些都需要监控才能及时发现。

常见的监控指标有这些：

• getPoolSize()：当前线程池中的线程数量，可以观察线程数是否一直处于最大线程数。
• getActiveCount()：正在执行任务的线程数量，如果长期接近线程池大小说明线程不够用。
• getQueue().size()：阻塞队列中积压的任务数，增长过快说明处理能力跟不上。
• getTaskCount()：累计任务数，可以用来计算吞吐量。
• getCompletedTaskCount()：已完成任务数，和上面的差值就是未完成任务数。
• 拒绝次数：这个指标需要自己统计，在拒绝策略里加计数器。

可以起一个后台定时任务，每 30 秒打印一次这些指标，或者接入监控系统发送告警。我习惯的告警规则是：

• 队列积压数超过队列容量的 80%，告警；
• 拒绝策略触发，立即告警（说明系统快撑不住了）；
• 活跃线程数长期超过最大线程数的 80%，告警。

有一次线上服务出现轻微超时，我就是通过监控发现线程池队列积压从 0 涨到了 700，而最大线程数的活跃度只有 40%。这说明不是线程不够，而是某个任务的执行时间变长了——查下去果然发现依赖的下游接口响应从 50ms 涨到了 2 秒。

3.4 参数动态调整：不要重启就能调优

线上环境改线程池参数是需要重启的，重启意味着短暂的服务中断，这在核心业务上没法接受。所以如果你的系统允许，可以预留参数动态调整的能力。

比如在线程池外面包一层ThreadPoolExecutor的管理器，暴露调整corePoolSize和maximumPoolSize的方法。Java 的ThreadPoolExecutor原生支持通过setCorePoolSize()和setMaximumPoolSize()动态调整，改完立即生效。

我在生产环境一般预留一个内部的管理接口，运维或开发同学通过控制台就能调整线程池参数，不需要发布代码。调整的原则是“小步慢调”，每次调整幅度不超过 20%，观察几分钟再决定是否继续调，避免一次调过头引起新的问题。

4. Java 之外：C++、C#、Python、Linux 下的线程管理

4.1 C++ 场景：线程池与大数组读写

C++ 里写多线程比 Java 更贴近底层，线程管理没有现成ThreadPoolExecutor可以用，需要自己封装或者用第三方库（如ThreadPool、BS::thread_pool）。但线程过多的问题是一样的，甚至更严重，因为 C++ 线程默认栈大小更大，没有 JVM 帮忙做任何回收优化。

C++ 里常见的一个场景是“两个线程分别读写一个大数组”。比如一个线程负责从网卡收包写入数组，另一个线程负责从数组读取数据进行计算。这里最容易出问题的是数据竞争，需要在读写之间做同步。经验做法：

• 用std::mutex加锁保护共享索引，或者用无锁队列（如boost::lockfree::spsc_queue）做单生产者单消费者模型。
• 做大数组分块处理时，注意“伪共享”问题。两个线程操作同一个缓存行上的不同数据，会导致缓存行频繁失效，性能断崖式下降。解决方法是让两个线程操作的数据每隔 64 字节错开。

struct alignas(64) PaddedCounter { std::atomic<int> value{0}; };

这段代码用alignas(64)强制按缓存行对齐，避免伪共享。很多 C++ 性能问题，不一定在锁，而是锁背后隐藏的缓存一致性问题。

4.2 C# 场景：Task、WaitOne 与线程安全集合

C# 里现在一般用Task而不是直接操作Thread，Task默认跑在线程池上，线程调度由运行时管理，但依然要小心线程过多的问题。

C# 开发者经常会遇到一个场景：多个任务并行执行，需要等待所有任务完成。用Task.WaitAll()可以等待一组任务全部完成，但如果等待的任务太多，占用的线程也多，主线程阻塞等待时，如果线程池排队较长，也可能出现死锁。更安全的做法是Task.WhenAll()用异步方式等待，不阻塞任何线程。

C# 里还有一个常见的坑是“线程安全 List”。很多人写多线程程序时图方便，直接用List<T>做共享集合，高并发下会出各种奇奇怪怪的问题。正确的选择是这样：

• ConcurrentBag<T>：适合高频添加、偶尔取出的场景；
• ConcurrentQueue<T>：适合先进先出的队列场景；
• ConcurrentDictionary<TKey, TValue>：适合键值对存储；
• 或者用List<T>加lock自己控制同步。

简单说来，不要用裸集合做跨线程共享，这是所有语言的通病，C# 的WaitOne和互斥体Mutex也是常用的同步手段，多个线程需要按顺序访问资源时，使用AutoResetEvent/ManualResetEvent要注意设置超时，避免某个线程卡死导致所有等待线程永久阻塞。

4.3 Python 场景：GIL 下的线程真相

Python 的多线程和 Java、C++ 有着本质区别，因为 CPython 解释器有 GIL（全局解释器锁），同一时刻只有一个线程能执行 Python 字节码。这意味着 Python 多线程对 CPU 密集型任务是无效的，还会因为线程切换增加开销。

对于 I/O 密集型任务（爬虫、接口调用、文件操作），Python 多线程依然有用，因为线程在等待 I/O 时会让出 GIL，其他线程可以执行。Python 的concurrent.futures.ThreadPoolExecutor用法和 Java 的线程池类似，同样要注意线程数不能开太多，线程切换开销一样存在。

from concurrent.futures import ThreadPoolExecutor def fetch_url(url): # 模拟 IO 操作 pass with ThreadPoolExecutor(max_workers=20) as executor: list(executor.map(fetch_url, urls))

Python 适合 CPU 密集型的正确姿势是多进程（如ProcessPoolExecutor/multiprocessing），因为每个进程有独立的 GIL，可以并行执行。但要记住进程比线程更重，进程数一般取 CPU 核数即可，不要盲目多开。

4.4 Linux 下的线程条件变量与守护线程

在 Linux 环境下，无论用什么语言写的服务器，最终都跑在pthread之上。Tomcat 里一个线程对应一个 Linux 线程，这就是最典型的 1:1 线程模型。所以 Tomcat 配置的maxThreads如果设得太大，比如 1000，那操作系统里就会有 1000 个线程等着被调度，性能反而上不去。

Linux 多线程编程中，线程条件变量（pthread_cond_t）是常用的同步原语，它配合互斥锁使用，让线程可以等待某个条件成立再继续执行。条件变量设计得好，能避免线程忙等浪费 CPU，但如果使用不当，比如没有正确加锁就调用pthread_cond_signal，会导致未定义的行为，卡死或者错过唤醒。

Linux 里还有守护线程的概念（pthread_detach），把线程设为分离状态后，线程结束时会自动释放资源，不需要pthread_join。进程主线程退出时，进程内所有线程都会被终止，所以守护线程的设计要格外注意生命周期管理。

5. 线程互斥与死锁：多线程“打架”的排查与预防

5.1 死锁是怎么产生的

线程调度和资源竞争不仅带来性能问题，还会带来正确性问题，其中最典型的就是死锁。死锁一旦发生，线程永久阻塞，CPU 占用可能不高但系统功能完全瘫痪。

死锁的产生需要同时满足四个条件：互斥、持有并等待、不可剥夺、循环等待。这个概念教科书上都讲了，但实际项目中还是反复出现，最常见的就是“两个锁的获取顺序不一致”。

经典场景是：线程 A 持有锁 1 等待锁 2，线程 B 持有锁 2 等待锁 1，两者互不相让，陷入死锁。用代码表示就是这样：

// 线程 A synchronized(lockA) { // 做一些事 synchronized(lockB) { ... } } // 线程 B synchronized(lockB) { // 做一些事 synchronized(lockA) { ... } }

这种问题还常常跟业务代码纠缠在一起，比如一个方法内部先调用 A 服务再调用 B 服务，另一个方法先调用 B 再调用 A，两个服务内部又有锁。排查起来特别费劲。

5.2 Java 环境下的死锁排查实操

Java 中排查死锁最直接的手段是jstack。拿到卡住的 Java 进程 PID，执行jstack PID，输出文件里如果发现类似这样的信息：

Found one Java-level deadlock: ============================= "thread-B": waiting to lock monitor 0x00007f8a3000b800 (object 0x00000000d5bf1a48, a java.lang.String), which is held by "thread-A" "thread-A": waiting to lock monitor 0x00007f8a3000b800 (object 0x00000000d5bf1b50, a java.lang.String), which is held by "thread-B"

这就说明 JVM 已经检测到了死锁，并且明确指出了参与死锁的线程和锁对象。拿到这个信息之后，再结合业务代码去分析锁获取顺序，问题就很好定位了。

除了jstack，用jconsole或jvisualvm也可以看到死锁检测，界面里会直接标红提示。如果生产环境不能随便用这些工具，可以提前在代码里做监控：用ThreadMXBean定时检测死锁，发现死锁后输出线程栈并告警。

ThreadMXBean tmb = ManagementFactory.getThreadMXBean(); long[] deadlockedThreads = tmb.findDeadlockedThreads(); if (deadlockedThreads != null) { // 输出死锁线程信息 }

5.3 避免死锁的设计策略

死锁的排查成本远高于预防成本，所以把预防做在前面是最划算的。

第一，统一锁的顺序。所有需要获取多个锁的地方，必须按照同一个全局顺序获取锁。比如规定必须先获取锁 A 再获取锁 B，就不允许出现先获取 B 再获取 A 的代码。这个规则要用代码评审来卡，不能只靠自觉。

第二，使用超时锁。ReentrantLock支持tryLock(timeout)，获取锁时设置超时时间，超时后主动释放已持有的锁，避免无限等待。数据库连接池的获取连接、分布式锁的获取，都应该设置超时时间。

第三，减少锁粒度。锁的范围越小，发生死锁的概率越低。比如只锁共享数据的那一小段操作，不要把一个方法整体锁住。JDK 8 之后，可以通过 CAS、原子变量、读写锁等手段减少锁竞争。

第四，合理设计线程池。线程池里如果同一个任务嵌套提交到同一个线程池，而线程池已经没有空闲线程，就可能出现“线程池饥饿”导致的死锁。遇到这类问题，要么用无界队列，要么对嵌套任务单独开一个线程池，总之不能让父任务占着线程等子任务，而子任务永远没机会执行。

5.4 线程互斥的其他注意点

互斥锁在保证安全的同时，也会引入性能损耗。锁的粒度越粗，线程并行的程度越低；锁的竞争越激烈，线程等待的时间越长。所以在设计共享数据访问时，可以考虑无锁或者读写锁：

• 数据量不大且读多写少，用ReadWriteLock或者 JDK 的StampedLock；
• 单个变量的更新，用AtomicInteger、AtomicLong等无锁原子类；
• 多个变量需要保持一致的更新，再考虑加锁保护。

还有一种常见问题是“锁内做了耗时操作”。比如锁内发了个 HTTP 请求，其他所有需要这个锁的线程都被迫等待，吞吐量直线下降。这里可以做的是把锁内的耗时操作移出去，先复制一份数据做快照，释放锁后再处理耗时操作，保证锁不会成为系统的性能瓶颈。

6. 踩坑实录：常见线程性能问题排查速查表

6.1 我的几个线上案例

案例一：线程数暴涨导致 CPU 飙升。某个服务上线后，运行三个小时，线程数从 200 涨到 2000，CPU 从 30% 飙升到 95%。用jstack一看，大量线程堆积在某个 HTTP 客户端的调点上，再查代码发现这个 HTTP 客户端没有设置连接池和超时时间，每次请求都新建连接，而且连接一直不释放，线程全部阻塞在等待连接上。解决方法是给 HTTP 客户端配置合理的连接池、连接超时和读取超时，同时把执行任务的线程池按业务拆细，避免互相影响。

案例二：CallerRunsPolicy引发的响应时间恶化。线上一个支付回调接口，线程池满了之后走了CallerRunsPolicy，回调请求直接在 Tomcat 的线程里执行，导致 Tomcat 线程被占满，其他接口全部超时。后来改成了自定义的拒绝策略：任务进入一个降级队列，异步落库记录，后续再由定时任务补处理。核心思路是“高峰可以延迟处理，但不能把主流程阻塞掉”。

案例三：线程池队列无界导致 OOM。这个是最典型的，一个后台导出任务使用了默认的LinkedBlockingQueue，没有指定容量，一个运营同学点了大批量导出，瞬间几万条任务全部堆积在队列里，内存被任务对象占满，服务 OOM。后来改成有界队列 + 丢弃策略，并对导出类任务做并发控制，单个用户同时只能有一个导出任务，再也没出现过问题。

案例四：死锁隐藏得很深。一个消息队列消费服务，用了两个线程池，分别在处理消息时获取同一个分布式锁，两个线程池的任务互相等待对方的锁，服务整体卡死。jstack显示线程全部处于WAITING状态。解决方法是统一锁的获取顺序，并且给分布式锁加超时时间，获取不到就直接抛异常中止任务，让消息重新进入队列。

6.2 速查表：从现象到解决方案

现象	可能原因	排查手段	解决方案
CPU 占用率高但 QPS 不高	线程数过多，上下文切换频繁	jstack看线程数，top -H看线程 CPU 占比	限制线程池大小，检查是否有线程空转或忙等
线程数持续增长不下降	任务执行时间过长，或线程泄漏	jstack定位线程堆积位置	检查阻塞调用是否有超时，线程池使用后是否正确回收
接口响应变慢，任务积压	队列积压，线程池不够用	查看线程池活跃线程数、队列大小	合理加大线程数或减小任务耗时，必要时扩容
OOM 异常	无界队列任务堆积	查看堆转储，统计任务对象数量	改为有界队列，设置容量上限
系统整体无响应	死锁或线程阻塞	jstack检测死锁	统一锁顺序，加超时锁
数据错乱或抛出异常	线程安全问题	代码评审，加锁验证	使用线程安全集合，加锁保护共享数据

6.3 一些独家避坑技巧

线程池的最大线程数不要拍脑袋设很大，压测时一定测“线程数翻倍”的场景。我曾经帮人排查过一个系统，线程池最大线程数设了 500，压测时发现 500 线程跑起来的吞吐量只有 200 线程的一半，原因就是上下文切换和缓存失效把收益吃掉了。

线程池的keepAliveTime不要设成 0。如果你设成 0，意味着非核心线程一旦空闲就立刻回收，这样在流量有波动的时候，线程反复创建销毁的开销非常大。一般设成 60 秒比较合适。

用监控工具观察线程池的状态。我在所有核心线程池上都加了指标采集，每 10 秒记录一次线程池大小、活跃线程数、队列积压数。这样做的好处是，问题发生后不用翻日志找证据，直接看监控曲线就能定位到是什么时候开始恶化的。

线程池里的任务一定要做超时控制。不管是 HTTP 调用、数据库操作还是 RPC 调用，都加上超时时间。否则一个下游服务挂了，所有线程都会阻塞在那里，线程池很快被耗尽，这就是“线程池耗尽雪崩”。

写代码时不要图方便直接new Thread().start()。像 Java 的Executors.newCachedThreadPool()这种快捷方法也尽量别在生产用，因为它是无界线程池，线程数可以无限增长。要用就用ThreadPoolExecutor显式地配置所有参数，确保你能掌控线程总数。

最后再分享一个很容易被忽略的细节：如果你们用的是 Tomcat 这类 Web 容器，server.tomcat.threads.max这个参数也要关注。它决定了 Web 容器能处理的最大并发请求数，如果设得太大，Tomcat 的线程数也会成为系统瓶颈，和业务线程池的问题如出一辙。我习惯把 Tomcat 的线程数控制在 200 以内，再结合业务线程池做分层限制，这样任何一个层面的问题，都不会把系统整体拖垮。