企业官网建设流程全解析

我先说一个我自己的经历。早期做订单系统时，为了保证同一个用户的操作日志不乱序，代码里到处是Executors.newSingleThreadExecutor()。当时觉得这个方案简单可靠，直到有一天线上日志顺序错乱，排查下来才发现是有个地方每次调用都新建了一个线程池，根本没有复用。后来切换到了Kotlin协程，我才彻底想明白问题出在哪：线程池太“重”了，而且它把“串行”这件事绑定在了一个线程的生命周期上。Kotlin协程里恰好有一个专门干这个事的API——limitedParallelism，尤其是Dispatchers.IO.limitedParallelism(1)，在业务上能替代单线程池，实现串行、轻量、又不用手动关线程池的效果。这篇文章我就从原理到实战，把为什么它可以替代单线程池、具体怎么用、有哪些坑，一次性讲清楚。

1. 单线程池为什么会让Java代码又慢又乱

1.1 单线程池真正解决的是“乱”，不是“慢”

先理清一个概念：很多并发问题的本质，是多个线程同时操作同一个资源导致数据“乱”了，而不是系统本身不够快。比如多个请求同时修改同一个账户余额、多个线程同时追加同一条日志文件、多个请求同时访问一个不安全的第三方SDK。解决方案无非就几类：加锁、CAS、或者干脆串行化。而Java里最简单粗暴的串行化方案，就是单线程池。

Executors.newSingleThreadExecutor()内部其实是一个核心线程数为1、队列无界的ThreadPoolExecutor。提交给它的所有任务都会进入队列，由唯一一个线程依次执行。这种设计从源头消灭了并发，不存在多线程竞争，也不需要考虑锁的粒度、死锁、活性问题，项目里很多资深的工程师都偏爱用它来处理一些“需要严格保证顺序”的场景。

在Java面试里，如果被问到“什么时候用单线程池”，很多人的第一反应是“并发量低的时候”。这个回答其实不太准确。并发量低但任务之间没有共享资源，用普通线程池甚至直接同步执行都可以。真正适合单线程池的场景只有一个核心特征：多个任务之间必须按提交顺序执行，且任务之间不能并发。比如我要保证同一个用户的订单创建日志一定出现在支付日志之前，那我只需要把这两个日志提交到同一个单线程池里，剩下的交给队列就好。

1.2 单线程池的硬伤：一个线程堵住，全队列卡死

单线程池好用，但代价也摆在明面上。最大的问题就是：这一个线程承担了所有串行任务，一旦某个任务长时间阻塞，队列里所有后续任务全部被卡住。

举个例子，如果单线程池里的某个任务调用了外部的HTTP接口，而这个接口响应很慢，甚至超时等待了30秒，那么这30秒内，队列里其他任务即使都是五六毫秒就能跑完的轻量任务，也只能排队等着。这个现象在Java异步里面有一个自嘲的说法：单线程池的“队头阻塞”。线程虽然只有一个，但是无界队列可以无限接任务，最后堆积的是延迟和内存。

第二个问题是线程资源太昂贵。JVM里每个线程默认栈大小通常在512KB到1MB之间，创建100个单线程池，光是线程栈就占掉差不多100MB的虚拟内存。更麻烦的是，线程不是“用完即走”的，如果没有正确调用shutdown()，线程会一直在后台存活。在Web容器或者Android应用里，线程泄漏是常有的事，最终导致OutOfMemoryError。热词里经常出现的java: outofmemoryerror: insufficient memory，有相当一部分就是这种乱创建线程导致的。

第三个问题是“一个池只能串行一种资源”。如果系统里有十几种需要分别保证顺序的资源，你难道要建十几个单线程池？线程数量会直接爆炸。所以有人会做分桶，按某个key取模分到固定数量的池子里，比如：

ExecutorService[] pools = new ExecutorService[4]; for (int i = 0; i < pools.length; i++) { pools[i] = Executors.newSingleThreadExecutor(); } void submitOrderEvent(long userId, Runnable task) { pools[(int) (userId % pools.length)].submit(task); }

分桶可以缓解线程数量问题，但同时引入了一个新的风险：任务之间如果存在依赖关系，比如A池的任务提交给了B池并等待结果，而B池的线程又在等待A池执行完，就容易出现线程饥饿甚至死锁。单线程池本身不会产生死锁，但它和多个池的编排组合在一起，就很容易踩到这些坑。

1.3 为什么切到协程后单线程池就不香了

如果项目里还是纯Java，上面这些坑你可以用各种工程手段规避。但如果项目已经引入了Kotlin协程，再回去用单线程池，就会觉得特别拧巴。

最大的拧巴点是：单线程池的execute(Runnable)没法直接执行suspend函数。你要么在里面套一层runBlocking，要么额外包一个CoroutineScope。而runBlocking放在单线程池里，相当于那个唯一的线程直接在等待协程结束，一旦协程内部再有挂起操作，这个线程就被占用，后面排队的任务全部卡住。这种“两层世界”的别扭感，很多人应该都有体会。

协程最核心的思维是“挂起而不是阻塞”。同样的串行需求，在协程里可以把“限制并发”这件事交给调度器，而不是交给一个独占线程。这也是limitedParallelism出现的原因：它希望用协程的方式来解决并发限制问题，又不想让业务方去关心线程生命周期。

2. Kotlin协程调度器：一个更好的“串行化底座”

2.1 协程不上线程，挂起不等于阻塞

先给不太熟悉协程的朋友补个基础。协程本质上是一种“可挂起”的计算单元，它运行在线程之上，但又不和线程绑定。线程在运行一个协程时，如果协程执行到suspend函数，线程并不会傻傻等着，而是会被释放出来，去执行别的协程。等挂起的条件满足了，协程再从上次挂起的地方继续执行。

这有点像银行柜台。线程是柜台窗口，每个窗口配一个营业员。传统线程模型里，一个客户办理业务办了半小时，营业员就一直陪着，后面所有人排队。协程模型里，这个客户可以先填单、交资料，然后回家等短信通知，营业员马上接待下一个人。过一会儿短信来了，客户再回到某个窗口继续办理。

所以协程可以用非常少的线程承载非常多的并发任务。JVM上创建一个线程可能要分配512KB到1MB的栈空间，而创建一个协程对象可能只需要几百字节到几KB。你可以放心地创建几万个协程，但如果创建几万个线程，内存直接扛不住。这也是为什么协程特别适合IO密集场景。

举个最简单的例子：

fun main() = runBlocking { val start = System.currentTimeMillis() repeat(10_000) { launch { delay(1000) } } println("cost ${System.currentTimeMillis() - start} ms") }

这段代码创建一万个协程，每个挂起1秒。如果换成一万个线程，同样逻辑内存和CPU都会很吃力。但协程几乎零压力地跑完。原因就是delay是挂起操作，不会占用线程。

2.2 Dispatchers.IO 和 Dispatchers.Default：别用错调度器

协程最终还是要跑在线程上的，这个“决定协程运行在哪类线程上”的东西就是CoroutineDispatcher。Kotlin协程在JVM上提供了几个内置调度器，需要先弄清楚它们的分工。

Dispatchers.Default主要用于大量计算、排序、解析等纯CPU密集操作，默认并发度跟CPU核心数有关，通常不会超过核数太多，因为计算密集任务一旦超过核数反而会因为上下文切换变慢。

Dispatchers.IO则是为数据库访问、网络请求、文件读写这类任务设计的。它的默认并发上限早期是64，后来版本允许通过kotlinx.coroutines.io.parallelism系统属性调整，上限可以非常大，理论最大能到65535。需要说明的是，JVM上Dispatchers.IO和Dispatchers.Default底层会共享线程资源，这样可以减少线程切换开销。

很多初学者会把“调度器”和“线程池”混为一谈，其实不完全是。调度器是一套任务分配策略，底层确实有线程池，但协程的挂起能力让它有了更多主动权。Dispatchers.IO本身也只是一个特殊的“受限调度器”，它限制并发量，但底层线程是按需扩缩的。理解了这一点，再看limitedParallelism就会非常顺。

3. limitedParallelism(1) 的正确打开方式

3.1 limitedParallelism 内部做了什么

limitedParallelism是kotlinx.coroutines从1.6.0开始提供的一个扩展函数，定义很简单：

fun CoroutineDispatcher.limitedParallelism(parallelism: Int): CoroutineDispatcher

它会基于当前调度器返回一个新的调度器视图，这个视图只允许指定数量的任务同时执行。本质上，它在原来的调度器前面加了一道“限量闸门”。

我拿Dispatchers.IO.limitedParallelism(1)举例。这个表达式返回的调度器，底层仍然使用Dispatchers.IO的线程池，但同一时间最多只有一个任务在这个调度器上运行。其余任务会在闸门外排队，等前一个任务执行完再进入。

实现上，这个调度器使用类似信号量或原子计数的方式来控制并发。任务执行前尝试获取许可，获取到了就执行，执行完释放。所以你可以同时创建多个受限调度器：

val serialA = Dispatchers.IO.limitedParallelism(1) val serialB = Dispatchers.IO.limitedParallelism(1) launch(serialA) { log("A") } launch(serialB) { log("B") }

serialA和serialB各自最多只有一个任务在跑，但它们底层共享Dispatchers.IO的线程池。两个受限调度器之间互不影响。这比创建两个单线程池要节省资源，因为单线程池是两个固定线程，即使任务全部挂起，线程也一直在那里；而协程的受限调度器在线程空闲时，底层线程可以被其他协程复用。

在Kotlin协程出现早期，如果大家想限制并发度，通常会自己写一个信号量：

val gate = Semaphore(1) suspend fun <T> serial(block: suspend () -> T): T = gate.withPermit { block() }

这种写法能用，但它把限制逻辑散落到业务代码里，而且只控制“临界区”，并不参与调度器对线程的选择。一旦线程阻塞而不是挂起，信号量保护不了线程资源。limitedParallelism则把并发限制内聚到了调度器这一层，使用方不需要额外包一层，代码更干净，语义也更清晰。

顺带提一个容易踩坑的细节：limitedParallelism(0)是非法的，源码会直接抛IllegalArgumentException。0没有意义，因为并发度至少是1。传1表示“单飞”，传n表示“最多n飞”。

3.2 为什么是 limitedParallelism(1)，而不是 limitedParallelism(0)

很多刚接触这个API的同学会有一个疑问：我要求“单线程”，为什么不传0？原因很简单：并发度0意味着什么任务都不能执行，这显然不合理。limitedParallelism里的参数是并发任务数的上限，而不是线程编号。所以“单线程串行”对应的参数就是1。

那limitedParallelism(1)和直接用Dispatchers.Default或者Dispatchers.IO有什么区别？区别在于：底层调度器允许的并发量很大，可能同时有64个IO任务在执行。而limitedParallelism(1)给这整条链路加了一道闸门，同一时间只放一个任务进去。你可以想象成一条多车道的公路，你的调度器原本允许60辆车并行，现在你给某个方向单独开了条“单车道”，只允许一辆车依次通行。

还有一点很有用：limitedParallelism可以突破底层调度器的默认并发限制。比如你的机器只有4核，Dispatchers.Default默认并发度可能只有4，如果你执行一些需要更多并行IO的场景，可以用Dispatchers.Default.limitedParallelism(8)显式把并发上限放大到8。当然，并发放大不意味着性能一定提升，线程一多，上下文切换成本也上来了。但是在某些场景下，这确实比自己去维护一个8线程的线程池简洁得多。

3.3 对比Java单线程池：一次全面的对照

把Executors.newSingleThreadExecutor()和Dispatchers.IO.limitedParallelism(1)放在一起，做一个直接对比：

从业务效果上看，两者都解决了“串行执行”的问题。但从资源占用和运维成本来看，差别非常明显。单线程池是“我为这个串行需求专门雇一个营业员”，不管业务忙不忙，这个人都得在窗口坐着；limitedParallelism(1)是“我允许这个通道同一时间只能有一个客户办理”，但营业员是从共用团队里临时抽调过来的，办完可以立刻去忙别的。

所以在协程项目里，我基本不再创建单线程池了。凡是需要串行化的地方，要么用limitedParallelism(1)，要么按业务维度分片后每个片一个limitedParallelism(1)。

4. 实战改造：把单线程池换成limitedParallelism

4.1 改造场景：按用户串行写审计日志

假设现在有一个订单系统，每个用户会触发多个审计事件，比如“创建订单”“支付成功”“退款申请”。审计日志必须保证同一个用户的事件顺序是准确的，否则后续对账排查都会出问题。如果同一个用户的两个事件同时到达，而底层写入是线程不安全的，就会乱序。

最朴素的Java实现，通常会给每个用户分配一个单线程池：

Map<Long, ExecutorService> userExecutors = new ConcurrentHashMap<>(); void writeLog(long userId, LogEntry entry) { ExecutorService executor = userExecutors.computeIfAbsent( userId, id -> Executors.newSingleThreadExecutor() ); executor.execute(() -> saveLog(entry)); }

这个实现有几个问题。用户量大时，每个用户一个线程，线程数爆炸。如果忘记shutdown()，线程会一直存活，造成泄漏。而且saveLog如果是一个阻塞的IO操作，那个线程就会被一直占用。更麻烦的是，这种代码在协程环境里用起来很别扭，没法直接写suspend逻辑。

4.2 改造后代码：从单线程池到协程调度器

换成协程后，同样的逻辑可以这样写：