Android多线程方案全解析：从Thread到协程的选型与避坑指南

1. 多线程不是“开个线程就完事”：先把问题拆清楚

Android 上聊多线程，很多人第一反应是new Thread().start()，或者随手丢一个AsyncTask进去跑。真到线上出了问题——界面卡顿、数据错乱、内存泄漏、线程池打满——回头再翻代码，才发现当初根本没想清楚“为什么要开这个线程”。我见过太多项目，多线程代码写得像撒胡椒面，到处是匿名Runnable，最后没人说得清哪个任务跑在哪个线程上。

这篇内容想干的事很明确：把 Android 里实现多线程的几种主流方式掰开揉碎讲清楚，包括Thread、HandlerThread、ExecutorService线程池、IntentService（历史方案）、Kotlin协程，以及AsyncTask这类已经过时但老项目里还大量存在的写法。重点不是罗列 API，而是讲清楚每种方式解决什么问题、在什么场景下用、坑在哪里。适合已经能写 Android 界面、但对并发调度还停留在“能跑就行”阶段的开发者，也适合想系统梳理一遍线程模型的老手对照检查。

先说一个贯穿全文的判断标准：Android 多线程的核心矛盾，永远是“后台干活”和“主线程更新 UI”之间的分工与通信。主线程（UI 线程）负责渲染和响应输入，任何超过 16ms 的阻塞都可能掉帧；而网络、数据库、大文件读写这些耗时操作必须挪到工作线程。但工作线程又不能直接碰 UI 控件。所以每一种多线程方案，本质上都在回答两个问题：任务在哪跑？结果怎么回到主线程？把这两个问题想明白，选型就不会乱。

下面按“从原始到现代、从手动到托管”的顺序展开，中间穿插我实际项目里踩过的坑和选型逻辑。

2. 最原始的 Thread 与 Runnable：能跑，但别拿它当主力

2.1 Thread 的两种写法与它们的真实差别

Java 层面创建线程最直接的方式就两种：继承Thread重写run()，或者实现Runnable接口再交给Thread执行。代码上差别不大：

// 方式一：继承 Thread class MyTask extends Thread { @Override public void run() { // 耗时操作 } } new MyTask().start(); // 方式二：实现 Runnable Runnable task = new Runnable() { @Override public void run() { // 耗时操作 } }; new Thread(task).start();

很多人纠结选哪个。我的结论很直接：优先用Runnable。原因不是性能，而是职责分离——Runnable只描述“要做什么”，线程只是“在哪做”的载体。用Runnable意味着这个任务以后可以丢给线程池、丢给HandlerThread、甚至丢给协程调度器，复用性更好。继承Thread则把任务和线程绑死了，Java 单继承的限制还会让你没法再继承别的类。

但这里有个容易被忽略的点：Runnable的run()方法不能抛受检异常，也不能返回值。如果你需要任务执行完拿回结果，就得用Callable+Future，这是后面线程池部分要讲的。实际项目里我见过有人为了拿返回值，在Runnable里塞一个AtomicReference或者成员变量，写法别扭还容易出并发问题，不如一开始就用对工具。

2.2 直接 new Thread 的三个致命问题

new Thread().start()在 Demo 里没问题，但在真实 App 里当主力用，迟早出事。我总结三个最要命的：

第一，线程创建销毁成本高。每new一个线程，JVM 要分配栈空间（默认 1MB 左右）、做系统调用注册到操作系统。频繁创建销毁，CPU 大量时间花在调度和上下文切换上，而不是干活。一个列表页滑动时如果每个 item 都起一个线程加载图片，滑动卡顿几乎是必然的。

第二，线程数量完全失控。没有统一管理，代码里到处new Thread，谁也不知道同时跑着多少个。Android 单个进程的线程数是有上限的（受虚拟内存和系统限制），线程爆炸会直接导致OutOfMemoryError: pthread_create failed。这个报错我在老项目里见过不止一次，排查起来非常痛苦，因为堆栈指向的是创建线程那一行，看不出全局问题。

第三，无法复用、无法取消、无法统一异常处理。一个裸线程跑起来，你想在页面销毁时取消它，只能靠一个volatile boolean标志位轮询；线程里抛了未捕获异常，默认行为是打印堆栈然后线程死掉，App 可能毫无感知地处于半坏状态。

所以Thread的正确用法是：作为最底层的执行单元存在，但业务代码不应该直接创建它。真正该用的是线程池，Thread只是线程池内部的生产资料。

2.3 主线程通信：为什么不能直接改 UI

工作线程算完结果要更新界面，新手最容易犯的错是直接在子线程里textView.setText(...)。Android 的 UI 工具包不是线程安全的，所有 View 的操作都必须在创建它们的线程（也就是主线程）上进行。子线程直接改 UI，轻则界面错乱，重则抛CalledFromWrongThreadException。

正确的回主线程方式，最基础的是Handler+Looper：

Handler mainHandler = new Handler(Looper.getMainLooper()); new Thread(() -> { String result = doHeavyWork(); mainHandler.post(() -> textView.setText(result)); }).start();

Handler的本质是往目标线程的MessageQueue里投递消息，Looper不断从队列取消息分发给Handler处理。主线程的Looper是系统在ActivityThread.main()里准备好的，所以Looper.getMainLooper()永远拿得到。这套机制是后面HandlerThread、AsyncTask、协程主线程调度器的共同底座，理解它比记住 API 重要得多。

注意：Handler持有外部类引用时容易内存泄漏。如果Handler是匿名内部类且postDelayed了长延时任务，Activity 销毁后消息还在队列里，Handler持有 Activity 引用导致无法回收。标准做法是静态内部类 + 弱引用，或者在onDestroy里removeCallbacksAndMessages(null)。

3. HandlerThread：给“串行后台任务”一个专属线程

3.1 HandlerThread 到底解决了什么

有些场景不需要并发，反而要求任务严格串行执行。比如本地日志写入、数据库的批量操作、某个硬件传感器的连续读取。这些任务如果并发跑，会互相干扰（日志顺序错乱、数据库锁竞争）。用线程池并发执行不合适，用裸Thread又没法方便地投递后续任务。

HandlerThread就是为这个场景生的。它本质是一个自带Looper的Thread，你启动它之后，它就进入消息循环，等着你通过Handler往它的队列里投任务。任务按投递顺序串行执行，天然有序。

HandlerThread workerThread = new HandlerThread("db-worker"); workerThread.start(); Handler workerHandler = new Handler(workerThread.getLooper()); workerHandler.post(() -> { // 这个任务跑在 db-worker 线程上 database.insert(record); });

对比一下：裸Thread跑完就结束了，你想再让它干第二件事，得重新创建；HandlerThread一直活着，随时可以post新任务，直到你调用quit()或quitSafely()。

3.2 生命周期管理：quit 与 quitSafely 的区别

HandlerThread用完必须退出，否则线程一直挂着，Looper一直循环，白白占资源。退出有两个方法：

• quit()：立即终止消息循环，队列里还没处理的消息全部丢弃。
• quitSafely()：处理完队列里已有的消息（不含延时未到期的）再退出。

我的经验是优先quitSafely()，尤其是涉及数据写入的场景。用quit()可能把还没落盘的任务直接扔掉，造成数据丢失。只有在明确要快速释放、且队列里的任务都无所谓的情况下才用quit()。

还有一个坑：HandlerThread的getLooper()在start()之后不一定立刻有值。如果start()后马上getLooper()，可能拿到null，因为线程还没真正跑起来初始化Looper。稳妥写法是等Looper就绪，或者干脆在start()之后通过一个同步机制确认。实际项目里我一般封装一个工具类，在getLooper()返回null时做短暂等待或回调，避免偶发的空指针。

3.3 适用边界：别把它当线程池用

HandlerThread只有一个线程，所有任务串行。这意味着如果某个任务特别慢，后面的任务全被堵住。所以它适合任务量可控、单任务耗时稳定、且需要顺序保证的场景。如果你有一堆可以并行的下载任务，用HandlerThread就是自找麻烦，该上线程池。

另外，HandlerThread的优先级默认和普通线程一样，如果做的是对延迟敏感的后台任务，可以通过Process.setThreadPriority()调整，但一般业务场景用不上。我个人的判断标准很简单：需要“一个专属的后台队列”时用HandlerThread，需要“多个任务并行抢资源”时用线程池。

4. ExecutorService 线程池：真正该作为主力的方案

4.1 为什么线程池是绝大多数场景的正解

前面说了裸Thread的三大问题，线程池恰好一一对应解决：复用线程避免频繁创建销毁、限制最大并发数防止线程爆炸、提供统一的任务提交/取消/异常处理接口。Android 里所有“正经”的后台任务，默认都应该走线程池。

Java 的ExecutorService体系核心是ThreadPoolExecutor，它的构造函数有七个参数，每个都影响行为：

ThreadPoolExecutor executor = new ThreadPoolExecutor( corePoolSize, // 核心线程数 maximumPoolSize, // 最大线程数 keepAliveTime, // 非核心线程空闲存活时间 TimeUnit.SECONDS, workQueue, // 任务队列 threadFactory, // 线程工厂 rejectedHandler // 拒绝策略 );

理解它的调度逻辑是关键：新任务来了，如果当前线程数小于corePoolSize，直接开新线程跑；如果核心线程都在忙，任务进队列排队；如果队列满了且线程数小于maximumPoolSize，开非核心线程；如果连最大线程数都满了，触发拒绝策略。

这个逻辑决定了队列类型的选择极其重要。用无界队列（如LinkedBlockingQueue不设容量），maximumPoolSize基本形同虚设，因为任务永远进得了队列，线程数永远停在corePoolSize。很多“线程池配置了 10 个最大线程却只跑 2 个”的困惑，根源就在这里。

4.2 四种常见线程池的选型对照

Executors工厂类提供了几个预设，但它们的适用场景差别很大，不能混用：

实际项目里，newCachedThreadPool要慎用，它的最大线程数是Integer.MAX_VALUE，理论上能创建海量线程，遇到突发流量直接拖垮进程。newFixedThreadPool的无界队列在任务生产速度长期大于消费速度时会持续堆积。所以生产环境我更倾向于手动new ThreadPoolExecutor，显式指定有界队列和拒绝策略，把风险控制在明面上。

4.3 拒绝策略与异常处理：最容易被忽略的两块

拒绝策略有四种：AbortPolicy（抛异常，默认）、CallerRunsPolicy（提交任务的线程自己跑）、DiscardPolicy（静默丢弃）、DiscardOldestPolicy（丢最老的再试）。默认的AbortPolicy会抛RejectedExecutionException，如果调用方没 catch，任务就悄悄失败了。我一般对不能丢的任务用CallerRunsPolicy，让提交者自己执行形成背压；对可丢的日志类任务用DiscardPolicy，但要打点监控丢弃量。

异常处理是另一个大坑。ThreadPoolExecutor里任务抛出的异常，如果用的是execute()提交，异常会传到线程的UncaughtExceptionHandler；如果用submit()提交，异常被包在返回的Future里，不调用get()就永远看不到。我见过线上任务批量失败却毫无告警的情况，就是因为用了submit()又没人get()。解决办法要么统一用execute()，要么在submit()后妥善处理Future，要么给线程工厂设置统一的异常处理器。

ThreadFactory factory = r -> { Thread t = new Thread(r, "app-pool-" + counter.incrementAndGet()); t.setUncaughtExceptionHandler((thread, e) -> { // 统一上报异常 reportCrash(e); }); return t; };

4.4 线程数到底设多少：一个可落地的估算

线程数不是拍脑袋。经验公式分两类：

• CPU 密集型（大量计算、加密、图像处理）：线程数 ≈ CPU 核心数 + 1。多了只会增加上下文切换开销。
• IO 密集型（网络请求、文件读写、数据库）：线程数 ≈ CPU 核心数 × (1 + 平均等待时间 / 平均计算时间)。等待占比越高，线程可以越多。

实际在手机上，CPU 核心数用Runtime.getRuntime().availableProcessors()拿。但要注意，这个值在低端机上可能是 4 或 6，高端机 8，不能写死。我一般给 IO 池设核心数 × 2起步，再根据压测调整。另外，不同业务用不同的池，别所有任务共用一个池——一个慢任务把池占满，会拖垮所有依赖它的功能。图片加载、网络请求、数据库操作，各自独立池，互不干扰。

5. AsyncTask 与 IntentService：老方案为什么被淘汰

5.1 AsyncTask 的设计初衷与它的原罪

AsyncTask曾经是 Android 官方推荐的“后台任务 + 主线程回调”一站式方案，封装了线程切换，用起来确实方便：

new AsyncTask<Void, Integer, String>() { @Override protected String doInBackground(Void... params) { return doHeavyWork(); // 工作线程 } @Override protected void onPostExecute(String result) { textView.setText(result); // 主线程 } }.execute();

但它的原罪在于生命周期不受控。AsyncTask持有 Activity 引用，Activity 销毁后任务还在跑，回调时操作已销毁的 View，直接崩溃或泄漏。而且早期版本AsyncTask是串行执行的（SERIAL_EXECUTOR），后来才支持并行，版本行为不一致导致很多兼容性问题。加上它内部就是一个静态线程池，多个AsyncTask共享，任务之间互相影响。

官方从 API 30 开始正式废弃AsyncTask，理由就是“容易出错、API 混乱”。老项目里如果还有，建议逐步替换成协程或线程池 + 主线程回调。新代码绝对不要再用。

5.2 IntentService 的“自动停止”特性与它的局限

IntentService解决的是“后台任务执行完自动停止服务”的问题。它内部用HandlerThread串行处理Intent，任务跑完自己stopSelf()，省去了手动管理 Service 生命周期的麻烦。适合“一次性、短时、串行”的后台任务，比如上传日志、同步数据。

但它的局限也很明显：串行执行（一个任务堵住后面所有）、不能并行、Android 8.0 之后后台服务受限、Android 11 之后基本被WorkManager取代。现在做后台任务调度，标准答案是WorkManager，它考虑了电量、网络、重启恢复等系统级因素，IntentService已经是历史名词。这里提它，主要是让维护老代码的人知道它是什么、为什么不该再用。

6. Kotlin 协程：现代 Android 并发的默认答案

6.1 协程相比线程池，赢在哪

协程不是“更轻量的线程”这么简单，它是一套结构化并发的编程模型。核心优势有三个：

第一，用同步写法写异步逻辑。线程池里嵌套回调的“回调地狱”，协程用suspend函数 + 顺序代码就解决了：

viewModelScope.launch { val user = repository.fetchUser() // 挂起，不阻塞线程 val orders = repository.fetchOrders(user.id) textView.text = "${user.name}: ${orders.size}" }

fetchUser()是suspend函数，它在 IO 线程执行，但代码看起来是顺序的。挂起时线程被释放去干别的，恢复时自动切回来，没有回调嵌套。

第二，结构化并发保证不泄漏。viewModelScope绑定 ViewModel 生命周期，ViewModel 销毁时所有协程自动取消。lifecycleScope绑定 Activity/Fragment 生命周期。再也不用担心“页面关了任务还在跑”。

第三，取消是协作式的、彻底的。协程取消会传播到所有子协程，suspend函数在挂起点检查取消状态，配合withTimeout可以优雅处理超时。

6.2 调度器选择：Dispatchers 的正确用法

协程的调度器决定代码跑在哪个线程：

• Dispatchers.Main：主线程，更新 UI 用。
• Dispatchers.IO：IO 线程池，网络、文件、数据库用。它内部是一个弹性线程池，按需扩容。
• Dispatchers.Default：CPU 密集型计算用，线程数等于 CPU 核心数。
• Dispatchers.Unconfined：不切换线程，慎用，容易出意外。

一个常见错误是在Dispatchers.IO里做 CPU 密集计算，或者在Default里做阻塞 IO。前者浪费了 IO 池的弹性，后者会占满计算线程导致其他计算任务饿死。正确做法是按任务性质选调度器，withContext切换：

suspend fun processImage(bitmap: Bitmap): Bitmap = withContext(Dispatchers.Default) { // CPU 密集的图像处理 applyFilter(bitmap) }

6.3 协程的坑：不是用了就万事大吉

协程也有它的问题。第一，GlobalScope滥用。GlobalScope.launch创建的协程不绑定任何生命周期，泄漏了也没人管，和裸线程一样危险。应该用viewModelScope、lifecycleScope或自定义的CoroutineScope。

第二，异常处理容易漏。launch里未捕获的异常会传播到父协程，可能导致整个 scope 崩溃。用async时异常被包在Deferred里，不await就看不到。建议在 scope 上配置CoroutineExceptionHandler，或者用supervisorScope隔离失败。

第三，suspend函数里做阻塞操作。如果一个suspend函数内部调用了阻塞的Thread.sleep或同步 IO，它并不会自动切线程，会阻塞当前调度器的线程。suspend只是标记“可能挂起”，不保证不阻塞。这点新手特别容易误解。

7. 选型决策：什么场景用什么，一张表说清

把上面几种方式放一起对比，选型逻辑就清晰了：

我的实际选型习惯：新项目一律协程，配合viewModelScope和Dispatchers.IO，代码量少、生命周期安全。纯 Java 项目或需要精细控制线程池参数的场景用ExecutorService，显式配置有界队列和拒绝策略。需要严格串行的后台队列用HandlerThread。Thread和AsyncTask只在读老代码时出现，不主动写。

还有一个容易被忽略的点：多线程方案的选择要和架构分层配合。Repository 层负责调度（决定在哪个线程执行），ViewModel 层负责生命周期（决定何时取消），UI 层只管展示。把线程调度散落在各处，是维护噩梦的根源。我见过一个项目，网络请求在 Activity 里起线程、数据库操作在 Adapter 里起线程、图片加载在自定义 View 里起线程，最后没人说得清一个页面到底跑着多少线程。统一收口到 Repository 的suspend函数或线程池封装里，问题会少一大半。

8. 几个真实踩过的坑与排查思路

8.1 线程池打满导致的“假死”

某次线上反馈：进入某个页面后，其他页面的网络请求全部超时，但 App 没崩。排查发现所有网络请求共用一个newFixedThreadPool(4)，而那个页面有个批量任务往同一个池里塞了几百个请求，每个请求还带重试。池被占满，其他页面的请求全在队列里排队，表现就是“假死”。

根因是不同业务共用线程池且没有隔离。修复方案是网络请求独立池、批量任务独立池，并且给批量任务加并发上限。教训：线程池是稀缺资源，按业务域隔离，别图省事共用一个。

8.2 协程里调阻塞 API 导致 ANR

有段代码在viewModelScope.launch里直接调了一个同步的数据库查询（老代码没提供suspend版本），以为协程会自动切线程。结果主线程被阻塞，ANR。原因就是前面说的：launch默认跑在Dispatchers.Main，suspend不自动切线程。修复是显式withContext(Dispatchers.IO) { ... }包住阻塞调用。

这个坑的排查思路：看 ANR 堆栈，如果主线程卡在某个数据库或网络调用上，基本就是这个问题。以后遇到“协程里怎么还卡主线程”，先检查有没有漏withContext。

8.3 HandlerThread 忘记 quit 导致的内存与电量问题

一个后台同步模块用HandlerThread做串行任务，页面退出时没调quitSafely()。线程一直活着，Looper空转（虽然空转时是阻塞在MessageQueue.next()上不耗 CPU，但线程栈和对象一直占着内存），而且持有了一些回调引用，导致相关对象无法回收。后来在onDestroy里补上quitSafely()才解决。

排查这类问题的思路：用 Profiler 看线程列表，如果某个自定义名字的线程在页面退出后还长期存在，基本就是没退出。养成“谁 start 谁负责 quit”的习惯，最好封装成AutoCloseable或在生命周期回调里统一管理。

提示：判断一个后台任务该不该用多线程，先问“它会不会阻塞主线程超过 16ms”。会，就必须挪走；不会，就别为了“看起来专业”而强行开线程，线程切换本身也有成本。

最后分享一个我个人的习惯：每次引入新的多线程代码，我都会在注释里写清楚三件事——这个任务跑在哪个线程、它依赖哪个生命周期、它失败时怎么被感知。这三行注释看着简单，但能在半年后回看代码时省下大量猜测时间。多线程的复杂度不在于 API 多难，而在于“谁在什么时候、在哪个线程上、做了什么”这件事一旦说不清，bug 就会以最意想不到的方式冒出来。把线程模型当成架构的一部分来设计，而不是随手new Thread，是 Android 并发编程真正要迈过的坎。