中秋月圆之夜，我与协程的泄漏做斗争

已于 2023-10-27 10:31:43 修改
阅读量437 收藏
点赞数 1
文章标签： android kotlin 开发语言
于 2023-09-26 22:44:49 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/wekajava/article/details/133325437
版权
本文详细介绍了如何在Kotlin中检测和避免协程内存泄漏，包括使用Profiler和dumpsysmeminfo工具，分析内存泄漏原因（持有外部类对象），提供青铜级和王者级避免策略，并讨论了协程挂起和线程挂起的区别。
摘要由CSDN通过智能技术生成

前言

人有悲欢离合，月有阴晴圆缺，此事古难全——苏东坡
人有悲欢离合，月有阴晴圆缺，你的协程是否泄漏了?——小鱼人
通过本篇文章，你将了解到：

  1. 如何检测Kotlin协程的内存泄漏？
  2. Kotlin协程为啥会内存泄漏?
  3. 如何避免Kotlin协程的内存泄漏？
  4. 协程挂起和线程挂起的终极混用
  5. 关注内存泄漏到底有没有现实意义？

1. 如何检测Kotlin协程的内存泄漏？

内存泄漏检测方式

Profiler抓取

Android官方给我们提供了profiler功能，可以实时观测线程、内存的情况：
选择内存分析，先dump文件：

image.png

dump成功后，解析文件：

image.png

如此一来就可以看到有泄漏了。

dumpsys meminfo抓取

Profiler功能很强，但步骤比较多也比较费时，如果只是想查看内存泄漏，可以使用更简单的方式。

第一步
在adb里输入如下命令查看进程的进程号：

ps -A | grep perform //perform为我自己包名的简称

image.png

24148 即为进程号。

第二步
拿到进程号后再使用如下命令：

dumpsys meminfo 24148

结果如下：

image.png

我们只需要关注Activities的值即可。
理论上打开一个Activity这个值就会加1，关闭一个Activity这个值就会减1。

如果只是打开了n个Activity，而此处的值>n，那么就可以判定发生了内存泄漏

一个会泄漏的协程

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查看是否发生内存泄漏：

image.png

很显然，此时只有MainActivity展示了，但此处却显示还有2个Activity对象，SecondActivity 发生了泄漏。

2. Kotlin协程为啥会内存泄漏?

持有外部类对象

前面有分析过内存泄漏的本质：匿名内部类/Lambda Java和Kotlin谁会导致内存泄漏?

在该例子里，因为在协程的闭包里持有了SecondActivity对象，而协程的闭包本质上是匿名内部类对象。
Dispatchers.Main表示该闭包将会在主线程执行，而在Android主线程执行势必要通过Looper，因此闭包最终被MessageQueue持有，最终它会被主线程持有，而线程属于一种GC Root，最终的持有关系：

主线程持有了SecondActivity对象，当SecondActivity退出时，由于还被主线程持有，因此无法释放，最终导致内存泄漏

不持有外部类对象

当然，如果协程的闭包里不持有外部类对象，那么无论如何都不会泄漏Activity，如下代码：

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，因此需要关注协程的泄漏问题。

从最直观的方式思考：

能否在页面退出的时候关闭协程？

override fun onDestroy() {
    super.onDestroy()
    GlobalScope.cancel("我要取消协程")
}

遗憾的是发生了crash:

image.png

意思是该协程作用域(GlobalScope)底下没有任何的Job。

仔细想想也是如此，若是GlobalScope.cancel()能够取消协程的执行，那么其它也用了GlobalScope开启的协程不就被我们cancel掉了吗？

既然如此，尝试cancel指定的Job。

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，猜猜会有内存泄漏吗？

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()
        }
    }
}

答案是：没有内存泄漏。

你可能会问了：此处咱们也没有显式地取消协程，为啥没泄漏呢？
真相只有一个：那就是从源码里寻找答案。

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()
    }
}

由上可知：

  1. lifecycleScope 监听了Activity生命周期，在Activity销毁时会取消协程，因此不会发生泄漏
  2. 同样的，在实际的应用中不推荐使用GlobalScope，而是使用与Activity/Fragment/ViewMode相关联的scope开启协程，如此一来我们只专注于协程实现业务逻辑

各个组件的协程作用域请参考：狂飙吧，Lifecycle与协程、Flow的化学反应

协程取消的原理

什么场景下能够取消协程

scope.cancel()/job.cancel()为什么就能够取消协程呢？
你可能会说：cancel本来就是设计为能够取消协程正在执行的动作，没什么那么多为什么。

阁下说的很有道理，倘若我代码写成以下这样子，阁下将如何应对呢？

lifecycleScope.launch(Dispatchers.IO) {
    while (true) {
        println("协程还在运行中...")
    }
}

image.png

现实是：即使Activity退出了，协程也没法取消，打印一直持续到天荒地老。

再换个写法：

lifecycleScope.launch(Dispatchers.IO) {
    while (true) {
        delay(1000)
        println("协程还在运行中...")
    }
}

当Activity退出时，协程被取消了，打印没了。

对比前后两者差异可知：

  1. 协程的取消能够打断挂起的函数，对不是挂起的函数不生效
  2. 协程取消后，挂起函数后面的代码将无法得到执行

取消的原理

lifecycleScope.launch(Dispatchers.IO) {
    while (true) {
        println("协程还在运行中...")
    }
}

将以上代码转为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：

lifecycleScope.launch(Dispatchers.IO) {
    while (true) {
        delay(1000) 
        println ("协程还在运行中...")
    }
}

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。

lifecycleScope.launch(Dispatchers.IO) {
    try {
        delay(30000)
        println("协程还在运行中...")
    } catch (e: Exception) {
        println("发生了异常：${e.localizedMessage}")
    }
}

退出Activity时，打印如下：

image.png

确实发生了异常，由此我们得出结论：

当协程里有挂起的函数时并且当前协程被挂起，若此时调用了协程的cancel方法，那么协程会终止挂起函数的执行，并抛出异常阻断后续代码的执行

此时依旧还有两个问题没有解决：

  1. 为什么非挂起函数不能取消？
  2. 协程是如何监听到取消指令的？

用一张图解释：

image.png

对于有挂起函数的协程，将会完全执行上图流程。
而对于没有挂起函数的协程，那么第5步将不会执行，也就是协程将不会切换状态机的状态(case的值)，当然也不会触发到如下语句：

ResultKt.throwOnFailure(var1);

最终也不会抛出异常。

最后一个问题：为啥抛出了异常，协程就没泄漏了？

答案是：

协程体的本质是一个Runnable，提交给了线程执行，当Runnable里的逻辑抛出了异常，那么这个Runnable就执行结束了，也就不会被线程持有，既然没被GC Root持有，那么在GC的时候就有机会被回收

4. 协程挂起和线程挂起的终极混用

协程取消能否中断线程？

lifecycleScope.launch(Dispatchers.IO) {
    Thread.sleep(10000)
    println("协程还在运行中...")//2
}

同样的步骤，进入到Activity后就退出，此时协程将会被取消。
问：2处的语句还会执行吗？

答案是：能

image.png

可以看出，此时的协程状态机里只有一个状态，并没有挂起函数，依据前面的分析可知协程并不会被成功取消。

这里涉及到线程的挂起和协程挂起的差异：

  1. 线程的挂起表示当前线程不会占用CPU的执行时间，也就是线程休息了，暂时不干活了
  2. 协程的挂起表示当前线程执行到挂起函数后就不会往下执行了，当前线程继续去做别的事(执行其它Runnable)

因此，若是在协程里想要延迟一段时间请使用协程相关的挂起函数如Delay等。

如何编写没还有泄漏的协程代码？

建议以下几个步骤：

  1. 协程里若是没有持有外部类对象(Activity/Fragment/Dialog等)，那么此时协程并不会泄漏UI对象
  2. 若是步骤1不满足，那么需要使用生命周期关联的协程作用域（LifecycleScope/viewModelScope等），当UI组件销毁时自动取消协程
  3. 协程体里尽量不使用线程相关的API，如Thread.sleep 等

5. 关注内存泄漏到底有没有现实意义？

小明说：“现在应用的内存都比较大，最常见的是UI对象的泄漏，不过呢泄漏几个Activity最多浪费了几K的内存，无伤大雅，不需要花费太多的时间在上面”

小刚说：“事虽然小，但有可能是压死骆驼的最后一棵稻草，勿以善小而不为,勿以恶小而为之”

小明继续道：“我们更多的需要关注频繁分配对象与突然间分配大对象的场景"

小刚说：“对于程序员来说，代码洁癖是一种美德，关注内存泄漏对己对人都有裨益”

小码说：“你倆都快领毕业大礼包了，先关心自己能不能抵御这大环境的寒冰真气吧"

小刚：“…"
小码：“…”

阁下意下如何？请把你的想法写在评论上吧。

本篇基于kotlin 1.7.0

您若喜欢，请点赞、关注、收藏，您的鼓励是我前进的动力

持续更新中，和我一起步步为营系统、深入学习Android/Kotlin

1、Android各种Context的前世今生
2、Android DecorView 必知必会
3、Window/WindowManager 不可不知之事
4、View Measure/Layout/Draw 真明白了
5、Android事件分发全套服务
6、Android invalidate/postInvalidate/requestLayout 彻底厘清
7、Android Window 如何确定大小/onMeasure()多次执行原因
8、Android事件驱动Handler-Message-Looper解析
9、Android 键盘一招搞定
10、Android 各种坐标彻底明了
11、Android Activity/Window/View 的background
12、Android Activity创建到View的显示过
13、Android IPC 系列
14、Android 存储系列
15、Java 并发系列不再疑惑
16、Java 线程池系列
17、Android Jetpack 前置基础系列
18、Android Jetpack 易学易懂系列
19、Kotlin 轻松入门系列
20、Kotlin 协程系列全面解读

go内存泄露case
架构师专栏
07-18 1万+
介绍一个golang内存泄露case的排查，go的gc、profile等
Kotlin实战指南十五：协程泄漏
赵彦军
05-28 3247
coroutines 引用 GlobalScope MainScope lifecycleScope lifecycleScope 是 KTX 下面的扩展包，Android 帮我们提供了一个扩展引用 使用 注意： 不需要我们手动 ， 系统已经帮我们做好了是ViewModel的KTX扩展库，可以让我们在ViewModel中方便的使用Coroutine。如果想要在 ViewModel 中使用作用域，我们需要添加依稀： 使用： lifecycleScope 原理 个人微信号：zhaoyanjun125 ,
go老鸟也会经常出现 并发channal问题引起的协程泄漏
aaqq123456654321的博客
04-24 550
go中经常用于并发channal问题引起的协程泄漏 例子: package main import ( "log" "runtime" "time" ) func main() { log.SetFlags(log.LstdFlags | log.Lshortfile) go func() { for { log.Printf("当前 goroutine 数量为：%d\n", runtime.NumGoroutine()) time.Sleep(1 * time.Second)
翻译：go协程泄漏：Goroutine Leaks - The Forgotten Sender
dhj555的博客
04-25 632
【字节跳动】内推码7ZUUEBV 长期有效：https://blog.csdn.net/u011091739/article/details/89502333 原文地址：https://www.ardanlabs.com/blog/2018/11/goroutine-leaks-the-forgotten-sender.html 起因： 新建goroutines处理事物，经过一段时间之后程...
面试题：Go协程泄漏原因及解决方法
最新发布
Faya__的博客
05-07 1070
协程泄漏(Goroutine Leakage)是指那些已经没有任何用处（不再被使用或者无法到到达其执行路径），但由于某些原因未被收回的goroutine。这些泄漏的goroutine占用内存资源，可能会随着程序运行时间的增长而累积，最终导致内存耗尽或者程序性能下降。
中秋月圆生活甜flash动画
07-31
这个名为"中秋月圆生活甜flash动画"的项目，显然是一份专为庆祝中国传统节日中秋节而设计的互动贺卡。下面将详细介绍这个项目中的相关知识点。 1. **Flash动画原理**：Flash基于帧的概念，通过在时间轴上安排不同的...
中秋月圆——公司中秋主题晚会ppt模板.zip
09-08
八月十五的月亮比其他几个月的满月更圆，更明亮，此夜，人们仰望天空如玉如盘的朗朗明月，自然会期盼家人团聚。远在他乡的游子，也借此寄托自己对故乡和亲人的思念之情。圆月、金鱼、祥云、牡丹、嫦娥奔月、金莲、...
金色季节月圆中秋精美动态中秋节祝福贺卡ppt模板.zip
09-09
标题中的“金色季节月圆中秋精美动态中秋节祝福贺卡ppt模板.zip”暗示了这是一个用于制作中秋节祝福贺卡的PowerPoint（PPT）模板，其中包含了动态元素和精美的设计。这个模板以“金色季节”为主题，利用了月圆中秋的...
华远君城中秋月圆夜方案活动策划方案-33P_市场运营_企划活动营销策划方案.pdf
08-09
华远君城中秋月圆夜方案活动策划方案-33P_市场运营_企划活动营销策划方案.pdf
PSD月圆中秋模板下载
08-28
PSD月圆中秋模板下载
android进程通信，腾讯、阿里Android高级面试真题汇总，先收藏了
m0_56252652的博客
03-27 150
前言 春招已经接近尾声了，不知道各位小伙伴有没有收获自己心仪的offer呢。笔者疫情被裁后在家LeetCode狂刷了800多题，加之自己以为工作总结的知识、经验，系统化的整理了一下。在五一期间已经收获了字节的offer。废话不多说，下面是我的刷题分享。 Android核心知识点文档 这份文档包含Android进阶架构师之路的核心知识，同时也是面试时面试官必问的知识点，篇章也是包括了很多知识点，其中包括了有Android部分、JAVA部分、Kotlin 部分、计算机网络部分、算法与数据结构部分、Flutter
Go协程泄漏和修复方法
奔跑的程序猿
06-24 2618
原文地址 许多Go开发人员都熟悉这个格言: 在不知道如何停止的情况下，永远不要启动goroutine。然而，泄漏goroutines仍然非常容易。让我们看一下泄漏goroutine的一种常见方法以及如何修复它。 为此，我们将构建一个具有自定义map类型的库，map的键配置配置成在持续时间后过期。我们给这个库取名为ttl，它将具有如下所示的API： // Create a map with a TT...
kotlin协程高级玩法之弱引用、解决协程导致的内存泄露
m0_46622598的博客
08-26 1115
前言 协程如线程一样，使用不当就会导致Activity内存泄漏，在解决内存泄漏的方法中，弱引用是最常用的封装，大家都知道WeakHandler就是例子。 项目地址 封装第一步封装弱引用类WeakRef，声明WeakReference类常量，将弱引用的对象any传入该常量构造函数。提供invoke方法返回弱引用的实例。 WeakRef 第二步为了方便调用，给任何类型的对象扩展函数weakRe...
Golang 什么是协程泄露(Goroutine Leak)？
Mark66890620
02-09 1874
概述 在Go中，goroutine很轻量级，随便创建成千上万个goroutine不是问题，但要注意，要是这么多的goroutine一致递增，而不退出，不释放资源，就有可能耗尽系统资源。 本文介绍goroutine泄露的两种实际场景，并讨论如何解决该问题。其他场景和更加详细的介绍，可以参考我的个人博客。 产生原因分析 产生goroutine leak（协程泄露）的原因可能有以下几种： goroutine由于channel的读/写端退出而一直阻塞，导致goroutine一直占用资源，而无法退出 gorou
[译]Kotlin是如何帮助你避免内存泄漏的？
weixin_33755557的博客
03-09 701
首先，本文的代码位置在github.com/marcosholga…中的kotlin-mem-leak分支上。 令人困惑的现象 我是通过创建一个会导致内存泄漏的Activity，然后观察其使用Java和Kotlin编写时的表现来进行测试的。 其中Java代码如下： public class LeakActivity extends Activity { @Override protected...
匿名内部类持有外部类的引用会导致内存泄漏？Kotlin：没有那么简单
柚子君的博客
11-03 4627
1. 结论 做Android的，或者做Java开发的同学，通常都会听到一句话，内部类持有外部类的引用，可能会导致父类内存泄漏？ 知道大家很忙，那就先把结论抛出来 Java中内部类会持有外部类的引用，可能引发内存泄漏 Kotlin存在编译优化，会将内部类编译成普通的类，如果内部类中没有实际引用外部类，则不会造成内存泄漏；如果内部类中引用了外部类，则会将外部类的作为参数传递给“内部类”，进而可能引发内存泄漏。 Kotlin协程中，GlobalScope与上条相同，如果协程内部没有实际引用外部类，则不会造成内存
如何安全地使用Kotlin协程
MengLee
10-26 696
在《五分钟说清楚Kotlin协程和Android的那点事》一文中，我们对Kotlin协程可以解决什么问题进行了深入的分析。在本文中，我们将探讨如何如何安全地使用Kotlin协程。 跟踪协程 协程可以很好地解决两个常见的编程问题： 处理长时间运行的任务； 确保主线程不被阻塞。 协程通过添加suspend和resume操作来实现上述功能。当特定线程上的所有协程都挂起时，该线程就可以执行其他的任务。 但是，协程本身并不能跟踪正在的工作。拥有大量的协同程序（数百甚至数千个）并同时将其全部暂停是非常好的。而且，尽
细说协程零六、协程泄露及async异常的处理
haoyuegongzi的博客
09-27 1845
前言一、有效避免协程泄露的方式1、通过Job来处理2、通过MainScope()来处理3、viewModelScope对象4、lifecycleScope对象二、异常Exception以及async并发下的异常处理三、几个题外话：1、RxJava与kotlin协程比较2、AsyncTask内存泄露3、协程的delay()和Thread.sleep()谁的性能更好？4、什么时候需要切线程？ Android项目开发中对协程的应用是比较灵活的，虽然依然是用****.luanch()来开启一段协程，通常指定Disp
面试官：谈谈 Go goroutine 泄露的场景
木川的技术之路
09-23 626
大家好，我是木川一、什么是 goroutine 泄露在 Go 中，goroutine 泄露是指创建的 goroutine 没有被正确地关闭或管理，导致它们在程序运行过程中无法被回收，最终导致资源浪费和潜在的性能问题。以下是一些常见的导致 goroutine 泄露的场景常见泄露原因如下：goroutine 内进行channel/mutex 等读写操作被一直阻塞。goroutine 内的业务逻辑进入死...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值