前言
协程系列文章：
- 一个小故事讲明白进程、线程、Kotlin 协程到底啥关系？
- 少年，你可知 Kotlin 协程最初的样子？
- 讲真，Kotlin 协程的挂起/恢复没那么神秘(故事篇)
- 讲真，Kotlin 协程的挂起/恢复没那么神秘(原理篇)
- Kotlin 协程调度切换线程是时候解开真相了
- Kotlin 协程之线程池探索之旅(与Java线程池PK)
- Kotlin 协程之取消与异常处理探索之旅(上)
- Kotlin 协程之取消与异常处理探索之旅(下)
- 来，跟我一起撸Kotlin runBlocking/launch/join/async/delay 原理&使用
- 继续来，同我一起撸Kotlin Channel 深水区
- Kotlin 协程 Select：看我如何多路复用
- Kotlin Sequence 是时候派上用场了
- Kotlin Flow啊，你将流向何方？
- Kotlin Flow 背压和线程切换竟然如此相似
- Kotlin SharedFlow&StateFlow 热流到底有多热？
- 狂飙吧，Lifecycle与协程、Flow的化学反应
- 来吧！接受Kotlin 协程--线程池的7个灵魂拷问
- 当，Kotlin Flow与Channel相逢
- 这一次，让Kotlin Flow 操作符真正好用起来
人有悲欢离合，月有阴晴圆缺，此事古难全------苏东坡
人有悲欢离合，月有阴晴圆缺，你的协程是否泄漏了?------小鱼人
通过本篇文章，你将了解到：
- 如何检测Kotlin协程的内存泄漏？
- Kotlin协程为啥会内存泄漏?
- 如何避免Kotlin协程的内存泄漏？
- 协程挂起和线程挂起的终极混用
- 关注内存泄漏到底有没有现实意义？
1. 如何检测Kotlin协程的内存泄漏？
内存泄漏检测方式
Profiler抓取
Android官方给我们提供了profiler功能，可以实时观测线程、内存的情况：
选择内存分析，先dump文件：
dump成功后，解析文件：
如此一来就可以看到有泄漏了。
dumpsys meminfo抓取
Profiler功能很强，但步骤比较多也比较费时，如果只是想查看内存泄漏，可以使用更简单的方式。
第一步
在adb里输入如下命令查看进程的进程号：
kotlin
ps -A | grep perform //perform为我自己包名的简称
24148 即为进程号。
第二步
拿到进程号后再使用如下命令：
shell
dumpsys meminfo 24148结果如下：
我们只需要关注Activities的值即可。
理论上打开一个Activity这个值就会加1，关闭一个Activity这个值就会减1。
如果只是打开了n个Activity，而此处的值>n，那么就可以判定发生了内存泄漏
一个会泄漏的协程
kotlin
class SecondActivity : AppCompatActivity() {
private lateinit var binding: ActivitySecondBinding
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
binding = ActivitySecondBinding.inflate(layoutInflater)
setContentView(binding.root)
GlobalScope.launch(Dispatchers.Main) {
delay(10000)
Toast.makeText(this@SecondActivity, "toast", Toast.LENGTH_LONG).show()
}
}
}在Activity的onCreate()里开启一个协程，并延时10s弹出toast。
当从MainActivity点击进入SecondActivity，然后快速退出 SecondActivity回到MainActivity。
此时通过adb查看是否发生内存泄漏：
很显然，此时只有MainActivity展示了，但此处却显示还有2个Activity对象，SecondActivity 发生了泄漏。
2. Kotlin协程为啥会内存泄漏?
持有外部类对象
前面有分析过内存泄漏的本质：匿名内部类/Lambda Java和Kotlin谁会导致内存泄漏?
在该例子里，因为在协程的闭包里持有了SecondActivity对象，而协程的闭包本质上是匿名内部类对象。
Dispatchers.Main表示该闭包将会在主线程执行，而在Android主线程执行势必要通过Looper，因此闭包最终被MessageQueue持有，最终它会被主线程持有，而线程属于一种GC Root，最终的持有关系：
主线程持有了SecondActivity对象，当SecondActivity退出时，由于还被主线程持有，因此无法释放，最终导致内存泄漏
不持有外部类对象
当然，如果协程的闭包里不持有外部类对象，那么无论如何都不会泄漏Activity，如下代码：
kotlin
class SecondActivity : AppCompatActivity() {
private lateinit var binding: ActivitySecondBinding
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
binding = ActivitySecondBinding.inflate(layoutInflater)
setContentView(binding.root)
GlobalScope.launch(Dispatchers.Main) {
delay(10000)
println("我会泄漏吗？不会呀")
}
}
}3. 如何避免Kotlin协程的内存泄漏？
青铜级避免
最简单的方式是协程闭包里不持有外部类的对象。
我们更多的时候需要在闭包里操作UI，因此需要关注协程的泄漏问题。
从最直观的方式思考：
能否在页面退出的时候关闭协程？
kotlin
override fun onDestroy() {
super.onDestroy()
GlobalScope.cancel("我要取消协程")
}遗憾的是发生了crash:
意思是该协程作用域(GlobalScope)底下没有任何的Job。
仔细想想也是如此，若是GlobalScope.cancel()能够取消协程的执行，那么其它也用了GlobalScope开启的协程不就被我们cancel掉了吗？
既然如此，尝试cancel指定的Job。
kotlin
job = GlobalScope.launch(Dispatchers.Main) {
delay(10000)
Toast.makeText(this@SecondActivity, "toast", Toast.LENGTH_LONG).show()
}
override fun onDestroy() {
super.onDestroy()
job.cancel("")
} 这次程序没有Crash，退出Activity后也没有弹出Toast，说明协程被cancel掉了。
王者级避免
在onDestroy()里进行资源的回收是比较古老的操作了，自从有了Lifecycle组件，生命周期的监听变得简单易上手，并且Lifecycle还扩展了协程作用域，因此我们可以只关注使用协程来实现业务逻辑，而无需关心它的生命周期。
同样的测试方式，只是使用lifecycleScope替换了GlobalScope，猜猜会有内存泄漏吗？
kotlin
class SecondActivity : AppCompatActivity() {
private lateinit var binding: ActivitySecondBinding
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
binding = ActivitySecondBinding.inflate(layoutInflater)
setContentView(binding.root)
lifecycleScope.launch {
delay(4000)
Toast.makeText(this@SecondActivity, "toast", Toast.LENGTH_LONG).show()
}
}
}答案是：没有内存泄漏。
你可能会问了：此处咱们也没有显式地取消协程，为啥没泄漏呢？
真相只有一个：那就是从源码里寻找答案。
kotlin
public val Lifecycle.coroutineScope: LifecycleCoroutineScope
get() {
while (true) {
val existing = mInternalScopeRef.get() as LifecycleCoroutineScopeImpl?
if (existing != null) {
return existing
}
//构造协程作用域
val newScope = LifecycleCoroutineScopeImpl(
this,
SupervisorJob() + Dispatchers.Main.immediate
)
if (mInternalScopeRef.compareAndSet(null, newScope)) {
//注册监听Activity生命周期
newScope.register()
return newScope
}
}
}
fun register() {
launch(Dispatchers.Main.immediate) {
if (lifecycle.currentState >= Lifecycle.State.INITIALIZED) {
//监听生命周期
lifecycle.addObserver(this@LifecycleCoroutineScopeImpl)
} else {
//如果Activity已经关闭，则取消协程
coroutineContext.cancel()
}
}
}
override fun onStateChanged(source: LifecycleOwner, event: Lifecycle.Event) {
if (lifecycle.currentState <= Lifecycle.State.DESTROYED) {
lifecycle.removeObserver(this)
//监听到Activity关闭，则取消协程
coroutineContext.cancel()
}
}由上可知：
- lifecycleScope 监听了Activity生命周期，在Activity销毁时会取消协程，因此不会发生泄漏
- 同样的，在实际的应用中不推荐使用GlobalScope，而是使用与Activity/Fragment/ViewMode相关联的scope开启协程，如此一来我们只专注于协程实现业务逻辑
各个组件的协程作用域请参考：狂飙吧，Lifecycle与协程、Flow的化学反应
协程取消的原理
什么场景下能够取消协程
scope.cancel()/job.cancel()为什么就能够取消协程呢？
你可能会说：cancel本来就是设计为能够取消协程正在执行的动作，没什么那么多为什么。
阁下说的很有道理，倘若我代码写成以下这样子，阁下将如何应对呢？
kotlin
lifecycleScope.launch(Dispatchers.IO) {
while (true) {
println("协程还在运行中...")
}
}
现实是：即使Activity退出了，协程也没法取消，打印一直持续到天荒地老。
再换个写法：
kotlin
lifecycleScope.launch(Dispatchers.IO) {
while (true) {
delay(1000)
println("协程还在运行中...")
}
}当Activity退出时，协程被取消了，打印没了。
对比前后两者差异可知：
- 协程的取消能够打断挂起的函数，对不是挂起的函数不生效
- 协程取消后，挂起函数后面的代码将无法得到执行
取消的原理
javascript
lifecycleScope.launch(Dispatchers.IO) {
while (true) {
println("协程还在运行中...")
}
}将以上代码转为Java查看：
java
public final Object invokeSuspend(@NotNull Object var1) {
Object var3 = IntrinsicsKt.getCOROUTINE_SUSPENDED();
switch (this.label) {
case 0:
//检测是否有异常
ResultKt.throwOnFailure(var1);
while(true) {
String var2 = "协程还在运行中...";
System.out.println(var2);
}
default:
throw new IllegalStateException("call to 'resume' before 'invoke' with coroutine");
}
}同样的，也将如下代码转为Java：
kotlin
lifecycleScope.launch(Dispatchers.IO) {
while (true) {
delay(1000)
println ("协程还在运行中...")
}
}
java
public final Object invokeSuspend(@NotNull Object $result) {
Object var3 = IntrinsicsKt.getCOROUTINE_SUSPENDED();
String var2;
switch (this.label) {
case 0:
//检测异常，若是则抛出
ResultKt.throwOnFailure($result);
break;
case 1:
//检测异常，若是则抛出
ResultKt.throwOnFailure($result);
var2 = "协程还在运行中...";
System.out.println(var2);
break;
default:
throw new IllegalStateException("call to 'resume' before 'invoke' with coroutine");
}
while(true) {
this.label = 1;
if (DelayKt.delay(1000L, this) == var3) {
return var3;
}
var2 = "协程还在运行中...";
System.out.println(var2);
}
}可以看出，两者的相同点是：
协程闭包执行每一个分支前都判断是否有异常，若是则抛出
异同点是：
一个有挂起函数，另一个没有
invokeSuspend()对应的就是协程的闭包逻辑。
既然可能会抛出异常，那我们尝试在协程的闭包里新增try...catch。
kotlin
lifecycleScope.launch(Dispatchers.IO) {
try {
delay(30000)
println("协程还在运行中...")
} catch (e: Exception) {
println("发生了异常：${e.localizedMessage}")
}
}退出Activity时，打印如下：
确实发生了异常，由此我们得出结论：
当协程里有挂起的函数时并且当前协程被挂起，若此时调用了协程的cancel方法，那么协程会终止挂起函数的执行，并抛出异常阻断后续代码的执行
此时依旧还有两个问题没有解决：
- 为什么非挂起函数不能取消？
- 协程是如何监听到取消指令的？
用一张图解释：
对于有挂起函数的协程，将会完全执行上图流程。
而对于没有挂起函数的协程，那么第5步将不会执行，也就是协程将不会切换状态机的状态(case的值)，当然也不会触发到如下语句：
kotlin
ResultKt.throwOnFailure(var1);最终也不会抛出异常。
最后一个问题：为啥抛出了异常，协程就没泄漏了？
答案是：
协程体的本质是一个Runnable，提交给了线程执行，当Runnable里的逻辑抛出了异常，那么这个Runnable就执行结束了，也就不会被线程持有，既然没被GC Root持有，那么在GC的时候就有机会被回收
4. 协程挂起和线程挂起的终极混用
协程取消能否中断线程？
kotlin
lifecycleScope.launch(Dispatchers.IO) {
Thread.sleep(10000)
println("协程还在运行中...")//2
}同样的步骤，进入到Activity后就退出，此时协程将会被取消。
问：2处的语句还会执行吗？
答案是：能
可以看出，此时的协程状态机里只有一个状态，并没有挂起函数，依据前面的分析可知协程并不会被成功取消。
这里涉及到线程的挂起和协程挂起的差异：
- 线程的挂起表示当前线程不会占用CPU的执行时间，也就是线程休息了，暂时不干活了
- 协程的挂起表示当前线程执行到挂起函数后就不会往下执行了，当前线程继续去做别的事(执行其它Runnable)
因此，若是在协程里想要延迟一段时间请使用协程相关的挂起函数如Delay等。
如何编写没还有泄漏的协程代码？
建议以下几个步骤：
- 协程里若是没有持有外部类对象(Activity/Fragment/Dialog等)，那么此时协程并不会泄漏UI对象
- 若是步骤1不满足，那么需要使用生命周期关联的协程作用域（LifecycleScope/viewModelScope等），当UI组件销毁时自动取消协程
- 协程体里尽量不使用线程相关的API，如Thread.sleep 等
5. 关注内存泄漏到底有没有现实意义？
小明说："现在应用的内存都比较大，最常见的是UI对象的泄漏，不过呢泄漏几个Activity最多浪费了几K的内存，无伤大雅，不需要花费太多的时间在上面"
小刚说："事虽然小，但有可能是压死骆驼的最后一棵稻草，勿以善小而不为,勿以恶小而为之"
小明继续道："我们更多的需要关注频繁分配对象与突然间分配大对象的场景"
小刚说："对于程序员来说，代码洁癖是一种美德，关注内存泄漏对己对人都有裨益"
小码说："你倆都快领毕业大礼包了，先关心自己能不能抵御这大环境的寒冰真气吧"
小刚："..."
小码："..."
阁下意下如何？请把你的想法写在评论上吧。
本篇基于kotlin 1.7.0
您若喜欢，请点赞、关注、收藏，您的鼓励是我前进的动力
持续更新中，和我一起步步为营系统、深入学习Android/Kotlin
4、View Measure/Layout/Draw 真明白了
6、Android invalidate/postInvalidate/requestLayout 彻底厘清
7、Android Window 如何确定大小/onMeasure()多次执行原因
8、Android事件驱动Handler-Message-Looper解析
11、Android Activity/Window/View 的background
12、Android Activity创建到View的显示过
14、Android 存储系列
16、Java 线程池系列