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()方法不能抛受检异常也不能返回值。如果你需要任务执行完拿回结果就得用CallableFuture这是后面线程池部分要讲的。实际项目里我见过有人为了拿返回值在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。正确的回主线程方式最基础的是HandlerLooperHandler 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工厂类提供了几个预设但它们的适用场景差别很大不能混用工厂方法线程数特征队列适用场景风险newFixedThreadPool(n)固定 n 个无界队列任务量可控的并行计算队列无限增长可能 OOMnewCachedThreadPool()0 到 Integer.MAX_VALUESynchronousQueue大量短时异步任务线程数可能爆炸newSingleThreadExecutor()固定 1 个无界队列严格串行的任务同 Fixed 的队列风险newScheduledThreadPool(n)固定 n 个延时队列定时/周期任务周期任务异常会静默停止实际项目里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 AsyncTaskVoid, 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.IOIO 线程池网络、文件、数据库用。它内部是一个弹性线程池按需扩容。Dispatchers.DefaultCPU 密集型计算用线程数等于 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. 选型决策什么场景用什么一张表说清把上面几种方式放一起对比选型逻辑就清晰了方案线程模型适用场景不适用场景现状建议Thread/Runnable单次执行极简 Demo、临时验证任何生产业务仅作底层了解HandlerThread单线程串行日志、传感器、串行 DB需要并行的任务特定场景可用ExecutorService线程池通用后台任务、可控并发需要生命周期绑定主力方案之一AsyncTask线程池封装无所有场景已废弃替换IntentServiceHandlerThread 封装无所有场景已被 WorkManager 取代Kotlin 协程结构化并发现代 Android 全部异步场景纯 Java 老项目首选方案我的实际选型习惯新项目一律协程配合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.Mainsuspend不自动切线程。修复是显式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 并发编程真正要迈过的坎。
