重构的起点：为什么需要多线程优化？

说实话，我见过太多项目在重构时栽在多线程这个坑里了。

几年前我接手过一个支付核心系统，单线程跑得好好的，日均处理几十万笔交易。老板说：「小王，明年业务量要翻五倍，你看着办。」我当时一拍脑袋——加线程啊！结果呢？上线第一天，死锁、数据错乱、CPU 飙到 99%，差点把生产环境搞崩。

嗯，从那以后我明白了一个道理：多线程不是银弹，但不用多线程，你连银弹的影儿都摸不着。

从单线程到多线程：为什么非变不可？

你想想看，单线程程序就像一个人在流水线上干活。活儿简单的时候，一个人管一条线，效率挺高。可一旦任务变复杂、数据量暴增，这个人就忙不过来了——CPU 在等 I/O，I/O 在等磁盘，磁盘在等网络……整个系统就在那干等。

我个人的习惯是，先看系统的瓶颈在哪。一般来说，三种情况会逼着你上多线程：

• CPU 密集型：计算量大，一个核跑满了，其他核在闲着。比如视频编码、图像处理。
• I/O 密集型：大部分时间花在读写文件、数据库查询、网络请求上。比如 Web 服务器、消息队列。
• 混合型：既有计算又有 I/O，比如实时推荐系统。

说白了，单线程的瓶颈就是「等」。多线程的核心思路就是：让 CPU 在等的时候，去干别的事。

项目重构中引入多线程的常见场景

我在项目中遇到过不少典型场景，这里列几个最常见的：

场景	单线程痛点	多线程方案
批量数据处理	100 万条记录逐条处理，耗时 30 分钟	分片 + 线程池并行处理，耗时降到 5 分钟
高并发 Web 服务	请求排队，响应时间飙升	线程池处理请求，提高吞吐量
异步任务处理	主线程被阻塞，用户等待	异步线程处理，主线程立即返回
实时数据聚合	多个数据源串行拉取，延迟高	并行拉取 + 合并结果

举个例子，我之前重构过一个报表系统。原来是一个线程跑所有报表，用户点一下「生成」，得等 40 秒。重构后，我把每个报表的生成任务丢到线程池里并行跑，结果 8 秒就出完了。用户反馈说：「你们系统是不是换了个新的？」——其实只是加了多线程。

引入多线程后的常见痛点

但是，多线程不是请客吃饭。我踩过的坑，说出来都是泪：

痛点一：数据竞争与线程安全

这是最经典的坑。多个线程同时读写同一个变量，结果数据就乱了。

// 错误示例：多个线程同时执行 count++
int count = 0;
// 线程A：读取 count=0，计算 count=1，写回
// 线程B：读取 count=0，计算 count=1，写回
// 结果：count=1，但期望是 2

我曾经在一个交易系统中犯过这个错。两个线程同时扣减库存，结果库存变成了负数。嗯，那天晚上我加班到凌晨三点修 Bug。

痛点二：死锁

线程 A 拿着锁 1 等锁 2，线程 B 拿着锁 2 等锁 1。两个线程就这么互相等着，谁也不让谁。

我记得有一次，线上服务突然全部挂起，所有请求都超时。一查线程栈，好家伙，四个线程两两死锁，整个系统直接瘫痪。

痛点三：性能反而下降

你可能会觉得奇怪：加了多线程，性能怎么还变差了？

原因很简单：线程切换是有成本的。如果线程数太多，CPU 大部分时间都在做上下文切换，真正干活的时间反而少了。

痛点四：调试与排查困难

单线程程序出 Bug，复现起来很容易。多线程程序出 Bug？那得看运气。有时候跑 100 次才出现一次，而且每次出现的现象还不一样。

我有个同事，为了复现一个多线程的 Bug，写了个脚本跑了整整一个周末。结果周一回来发现——Bug 没复现，但脚本把测试数据库写满了。

多线程优化的知识体系

说了这么多，其实多线程优化不是一上来就写代码。我习惯先画一张图，把整个知识体系理清楚：

这张图是我自己总结的。你看，多线程优化不是孤立的技术，它需要你同时掌握理论、安全、协作和性能四个维度。缺一个，就容易出问题。

重构时的心态准备

最后我想说几句掏心窝子的话。

重构引入多线程，本质上是在用复杂度换性能。你想想看，一个单线程程序，出了问题你从头到尾看一遍就能找到原因。但多线程程序，Bug 可能是偶发的、不可复现的、跟时间有关的。

所以我的建议是：能不引入多线程，就别引入。如果非要引入，先从最简单的模型开始——比如线程池 + 无状态任务。等跑通了，再考虑更复杂的并发控制。

嗯，这一章就到这里。下一章我们聊聊线程池——这个 Java 并发编程里最常用、也最容易用错的工具。