多线程与线程池:从 Thread 到高效并发

简介: 本文详解Android多线程核心原理与实践:从主线程阻塞风险引出线程池必要性,系统讲解Thread、Handler通信、ThreadPoolExecutor参数机制、拒绝策略、线程数设定及生命周期管理,并对比协程底层调度,强调复用、可控、安全的并发设计原则。

为什么需要多线程?

在 Android 开发中,主线程(UI 线程)负责界面渲染和用户交互。如果在主线程执行耗时操作——网络请求、数据库读写、文件 IO——界面就会卡顿,甚至触发 ANR(Application Not Responding)。

多线程的核心目的就一个:把耗时任务移出主线程,保持 UI 流畅

Thread 基础

最直接的方式是创建 Thread

Thread {
    // 耗时操作
    val data = fetchDataFromNetwork()
    runOnUiThread {
        textView.text = data
    }
}.start()

简单粗暴,但问题很多:

  • 每次 new Thread 都有创建和销毁的开销
  • 线程数量不可控,大量请求时会创建大量线程
  • 线程间通信靠 runOnUiThread / Handler,代码容易变乱

Handler 与线程通信

Android 提供了 Handler 机制来做线程间通信:

val handler = Handler(Looper.getMainLooper())

Thread {
    val result = doHeavyWork()
    handler.post {
        // 回到主线程更新 UI
        textView.text = result
    }
}.start()

Handler 解决了「子线程完成后怎么通知主线程」的问题,但并没有解决线程管理的问题。

线程池:统一管理线程

线程池(ExecutorService)是 Java 提供的线程管理方案,核心思想:复用线程,控制并发数量

常见线程池类型

// 固定大小线程池 —— 最常用的选择
val fixedPool = Executors.newFixedThreadPool(4)

// 缓存线程池 —— 适合大量短时任务
val cachedPool = Executors.newCachedThreadPool()

// 单线程池 —— 保证任务顺序执行
val singlePool = Executors.newSingleThreadExecutor()

// 定时线程池 —— 周期性任务
val scheduledPool = Executors.newScheduledThreadPool(2)

使用示例

val executor = Executors.newFixedThreadPool(4)

// 提交任务
executor.execute {
    val bitmap = downloadImage(url)
    handler.post { imageView.setImageBitmap(bitmap) }
}

// 提交有返回值的任务
val future: Future<String> = executor.submit(Callable {
    fetchDataFromServer()
})
// 获取结果(会阻塞当前线程)
val result = future.get()

合理设置线程数

// CPU 密集型:线程数 ≈ CPU 核心数
val cpuThreads = Runtime.getRuntime().availableProcessors()

// IO 密集型:线程数可以多一些(网络、文件操作等待时间长)
val ioThreads = cpuThreads * 2

ThreadPoolExecutor:底层原理

Executors 工厂方法底层都是创建 ThreadPoolExecutor,理解它的参数才能真正掌控线程池:

val pool = ThreadPoolExecutor(
    2,                          // corePoolSize:核心线程数(常驻)
    4,                          // maximumPoolSize:最大线程数
    60L, TimeUnit.SECONDS,      // 非核心线程空闲存活时间
    LinkedBlockingQueue(100),   // 任务队列
    Executors.defaultThreadFactory(),
    ThreadPoolExecutor.CallerRunsPolicy()  // 拒绝策略
)

任务提交流程

提交任务
  ↓
核心线程是否已满?── 否 → 创建核心线程执行
  ↓ 是
队列是否已满?── 否 → 放入队列等待
  ↓ 是
是否达到最大线程数?── 否 → 创建非核心线程执行
  ↓ 是
执行拒绝策略

四种拒绝策略

策略 行为
AbortPolicy(默认) 抛出 RejectedExecutionException
CallerRunsPolicy 由提交任务的线程自己执行
DiscardPolicy 直接丢弃,不报错
DiscardOldestPolicy 丢弃队列最旧的任务,重新提交

Android 中的实际场景

场景一:批量下载图片

val executor = Executors.newFixedThreadPool(4)

fun loadImages(urls: List<String>, callback: (String, Bitmap) -> Unit) {
    val handler = Handler(Looper.getMainLooper())
    urls.forEach { url ->
        executor.execute {
            val bitmap = downloadBitmap(url)
            handler.post { callback(url, bitmap) }
        }
    }
}

场景二:串行执行数据库写入

// 单线程池保证写入顺序
val dbExecutor = Executors.newSingleThreadExecutor()

fun saveUser(user: User) {
    dbExecutor.execute {
        database.userDao().insert(user)
    }
}

fun saveLog(log: LogEntry) {
    dbExecutor.execute {
        database.logDao().insert(log)
    }
}

场景三:定时清理缓存

val scheduler = Executors.newScheduledThreadPool(1)

// 每小时清理一次过期缓存
scheduler.scheduleAtFixedRate({
    clearExpiredCache()
}, 0, 1, TimeUnit.HOURS)

配合 Kotlin Coroutines 的现代方案

现代 Android 开发推荐用协程替代手动线程管理,但理解线程池原理依然重要:

// 协程内部依然可以使用线程池
val ioDispatcher = Executors.newFixedThreadPool(4).asCoroutineDispatcher()

viewModelScope.launch {
    val result = withContext(ioDispatcher) {
        fetchData()
    }
    updateUI(result)
}

协程的 Dispatchers.IO 底层就是一个共享线程池(默认 64 个线程上限)。理解线程池,才能更好地理解协程的调度行为。

线程安全问题

多线程带来的不只是性能问题,还有数据一致性:

var counter = 0

// 多线程同时执行 counter++,结果可能不对
fun increment() {
    counter++  // 非原子操作!
}

解决方案

// 方案一:synchronized
@Synchronized
fun increment() {
    counter++
}

// 方案二:原子变量
val counter = AtomicInteger(0)
fun increment() {
    counter.incrementAndGet()
}

// 方案三:volatile(保证可见性,不保证原子性)
@Volatile
var flag = false

生命周期管理

线程池不关掉,线程会一直存活,可能导致内存泄漏:

class MyActivity : AppCompatActivity() {
    private val executor = Executors.newFixedThreadPool(4)

    override fun onDestroy() {
        super.onDestroy()
        // 停止接收新任务,等待已提交任务完成
        executor.shutdown()
        // 或者立即中断所有线程
        // executor.shutdownNow()
    }
}

更好的做法是把线程池交给 ViewModel 管理:

class MyViewModel : ViewModel() {
    private val executor = Executors.newFixedThreadPool(4)

    override fun onCleared() {
        super.onCleared()
        executor.shutdown()
    }

    fun loadData() {
        executor.execute {
            val data = repository.fetch()
            _result.postValue(data)
        }
    }
}

小结

方案 适用场景 注意点
Thread 简单一次性任务 用完即毁,别滥用
Handler 线程间通信 注意内存泄漏
FixedThreadPool 并发执行、控制资源 合理设置线程数
SingleThreadExecutor 保证顺序执行 队列会堆积
ScheduledThreadPool 定时/周期任务 记得关闭
Kotlin Coroutines 现代异步方案 底层仍是线程池

多线程不是银弹,核心原则:用最少的线程完成最多的工作,同时保证数据安全。线程池就是这一原则的工程化实现——复用线程、控制并发、管理队列。理解了这些,不管是用传统 Java 线程池还是 Kotlin 协程,都能写出高效可靠的并发代码。

相关文章
|
1月前
|
人工智能 自然语言处理 API
给 Claude Code 省 97% Token 是真的吗?我把 caveman 装上跑了一周
caveman 是一款专为 Claude Code 等 AI 编码助手设计的省 token 插件,通过强制 AI 以极简“原始人式”语言输出(砍客套、留代码),平均压缩输出 token 65%。但它不省输入 token,甚至每轮多耗1–1.5k输入token,故短问答任务可能反增费用。实测显示:长文档/解释类任务真省钱,调试类任务慎用。省 token 的关键,在于上下文压缩+模型分级+输出优化三者协同,而非单靠插件。(239字)
336 1
|
1月前
|
网络协议 API 数据安全/隐私保护
阿里云百炼按量付费 API Key 获取教程:附TokenPlan和Coding Plan密钥获取方法
本文详解阿里云百炼按量付费API Key获取流程:登录控制台→开通服务→进入API Key管理页→选择地域(推荐北京)→创建并配置权限(全部或自定义IP/模型白名单)→立即复制保存sk-开头密钥(仅显示一次)。Token/Coding Plan用户需用专属sk-sp-密钥。在阿里云百炼官网:https://t.aliyun.com/U/fPVHqY 免费领取千万Tokens
|
存储
wsl的存储路径
wsl的存储路径
2810 0
|
1月前
|
人工智能 测试技术 API
AI智能体Harness四种架构横向对比——Loop / Graph / Microkernel / MultiAgent完整解析
随着LLM智能体大规模落地,Harness作为智能体执行承载框架,架构选型直接决定任务完成率、运行稳定性、资源成本。同一模型、同一业务需求,不同Harness架构下任务成功率可相差3至5倍。本文以微服务拆分改造这一典型复杂开发任务为样本,拆解循环驱动、图执行、微内核、多智能协作四类主流Harness架构的运行逻辑、核心特性、优劣边界,同时结合后端分布式系统类比,给出清晰选型标准与混合落地方案。
376 0
|
1月前
|
Java 关系型数据库 MySQL
【AgentScope Java新手村系列】(18)Skills技能系统
用 SKILL.md 文件定义可复用技能,HarnessAgent 自动扫描匹配,智能体按需调用。
304 0
|
存储 缓存 NoSQL
跟着源码学IM(十一):一套基于Netty的分布式高可用IM详细设计与实现(有源码)
本文将要分享的是如何从零实现一套基于Netty框架的分布式高可用IM系统,它将支持长连接网关管理、单聊、群聊、聊天记录查询、离线消息存储、消息推送、心跳、分布式唯一ID、红包、消息同步等功能,并且还支持集群部署。
14137 1
|
11月前
|
Web App开发 移动开发 前端开发
除了使用响应式布局,还有哪些方法可以适配H5页面在折叠屏上的显示?
除了使用响应式布局,还有哪些方法可以适配H5页面在折叠屏上的显示?
550 4
|
6月前
|
运维 安全 数据可视化
从SaaS到本地部署:阿里云建站与PageAdmin CMS的适用场景与决策边界解析
SaaS建站与独立部署CMS是企业官网的两条成熟路径。前者以阿里云建站为代表,解决快速上线的效率问题;后者以PageAdmin CMS为代表,满足数据自主与业务扩展的深层需求。路径无优劣,适配即价值。
268 1
|
人工智能 Linux API
零门槛本地部署!手把手教你用Ollama+Chatbox玩转DeepSeek大模型
本教程介绍如何在个人电脑上免费部署DeepSeek模型,无需高端显卡。通过Ollama和Chatbox两款轻量工具,用户可以在普通CPU上流畅运行大型语言模型。Ollama支持跨平台操作,提供一键式安装和模型管理;Chatbox则是多平台AI客户端,支持多种主流模型。教程涵盖Ollama和Chatbox的安装、DeepSeek模型的下载与配置,帮助你在本地轻松搭建智能助手,适用于学术研究、代码编写和日常问答等场景。
6324 32

热门文章

最新文章