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

已于 2023-10-27 10:31:43 修改
阅读量293 收藏
点赞数
文章标签： android kotlin 开发语言
于 2023-09-26 22:44:49 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/wekajava/article/details/133325437
版权

前言

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

  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 协程系列全面解读

小鱼人爱编程
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
中秋月圆生活甜flash动画
07-31
中秋月圆生活甜flash动画是一款中秋节贺卡，祝你好梦圆圆生活甜甜。
go内存泄露case
热门推荐
架构师专栏
07-18 1万+
介绍一个golang内存泄露case的排查，go的gc、profile等
go老鸟也会经常出现 并发channal问题引起的协程泄漏
aaqq123456654321的博客
04-24 491
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 608
【字节跳动】内推码7ZUUEBV 长期有效：https://blog.csdn.net/u011091739/article/details/89502333 原文地址：https://www.ardanlabs.com/blog/2018/11/goroutine-leaks-the-forgotten-sender.html 起因： 新建goroutines处理事物，经过一段时间之后程...
android进程通信，腾讯、阿里Android高级面试真题汇总，先收藏了
m0_56252652的博客
03-27 125
前言 春招已经接近尾声了，不知道各位小伙伴有没有收获自己心仪的offer呢。笔者疫情被裁后在家LeetCode狂刷了800多题，加之自己以为工作总结的知识、经验，系统化的整理了一下。在五一期间已经收获了字节的offer。废话不多说，下面是我的刷题分享。 Android核心知识点文档 这份文档包含Android进阶架构师之路的核心知识，同时也是面试时面试官必问的知识点，篇章也是包括了很多知识点，其中包括了有Android部分、JAVA部分、Kotlin 部分、计算机网络部分、算法与数据结构部分、Flutter
Go协程泄漏和修复方法
奔跑的程序猿
06-24 2575
原文地址 许多Go开发人员都熟悉这个格言: 在不知道如何停止的情况下，永远不要启动goroutine。然而，泄漏goroutines仍然非常容易。让我们看一下泄漏goroutine的一种常见方法以及如何修复它。 为此，我们将构建一个具有自定义map类型的库，map的键配置配置成在持续时间后过期。我们给这个库取名为ttl，它将具有如下所示的API： // Create a map with a TT...
中秋月圆——公司中秋主题晚会ppt模板.zip
09-08
八月十五的月亮比其他几个月的满月更圆，更明亮，此夜，人们仰望天空如玉如盘的朗朗明月，自然会期盼家人团聚。远在他乡的游子，也借此寄托自己对故乡和亲人的思念之情。圆月、金鱼、祥云、牡丹、嫦娥奔月、金莲、...
PSD月圆中秋模板下载
08-28
PSD月圆中秋模板下载
金色季节月圆中秋精美动态中秋节祝福贺卡ppt模板.zip
09-09
枝头的吉祥鸟、山、金色麦浪、金色莲花、圆月等元素，金色季节月圆中秋精美动态中秋节祝福贺卡ppt模板。
月圆人圆事事圆flash动画
07-31
月圆人圆事事圆flash动画是一款中秋节快乐贺卡动画素材下载。
Golang 什么是协程泄露(Goroutine Leak)？
Mark66890620
02-09 1784
概述 在Go中，goroutine很轻量级，随便创建成千上万个goroutine不是问题，但要注意，要是这么多的goroutine一致递增，而不退出，不释放资源，就有可能耗尽系统资源。 本文介绍goroutine泄露的两种实际场景，并讨论如何解决该问题。其他场景和更加详细的介绍，可以参考我的个人博客。 产生原因分析 产生goroutine leak（协程泄露）的原因可能有以下几种： goroutine由于channel的读/写端退出而一直阻塞，导致goroutine一直占用资源，而无法退出 gorou
Kotlin实战指南十五：协程泄漏
赵彦军
05-28 3111
coroutines 引用 GlobalScope MainScope lifecycleScope lifecycleScope 是 KTX 下面的扩展包，Android 帮我们提供了一个扩展引用 使用 注意： 不需要我们手动 ， 系统已经帮我们做好了是ViewModel的KTX扩展库，可以让我们在ViewModel中方便的使用Coroutine。如果想要在 ViewModel 中使用作用域，我们需要添加依稀： 使用： lifecycleScope 原理 个人微信号：zhaoyanjun125 ,
匿名内部类持有外部类的引用会导致内存泄漏？Kotlin：没有那么简单
柚子君的博客
11-03 4355
1. 结论 做Android的，或者做Java开发的同学，通常都会听到一句话，内部类持有外部类的引用，可能会导致父类内存泄漏？ 知道大家很忙，那就先把结论抛出来 Java中内部类会持有外部类的引用，可能引发内存泄漏 Kotlin存在编译优化，会将内部类编译成普通的类，如果内部类中没有实际引用外部类，则不会造成内存泄漏；如果内部类中引用了外部类，则会将外部类的作为参数传递给“内部类”，进而可能引发内存泄漏。 Kotlin协程中，GlobalScope与上条相同，如果协程内部没有实际引用外部类，则不会造成内存
[译]Kotlin是如何帮助你避免内存泄漏的？
weixin_33755557的博客
03-09 681
首先，本文的代码位置在github.com/marcosholga…中的kotlin-mem-leak分支上。 令人困惑的现象 我是通过创建一个会导致内存泄漏的Activity，然后观察其使用Java和Kotlin编写时的表现来进行测试的。 其中Java代码如下： public class LeakActivity extends Activity { @Override protected...
Android正向开发实现客户端证书认证
dafan0的博客
05-18 347
如果第三方模块被混淆，那hook方式均不能生效。这时就需要根据系统包去定位校验的函数，因此需要对安卓开发者是如何实现客户端证书校验的有一定了解，接下来就介绍这部分内容。开发者实现客户端证书校验的本质是：证书/密钥 + 代码。在形式上有：公钥校验、证书校验和Host（主机）校验。
安卓部署ffmpeg全平台so并实现命令行调用
codeofcc的博客
05-17 1055
前面的章节实现了ffmpeg全平台so的生成，接下来的步骤就是部署以及使用了，部署so还是比较简单的，用gradle和cmake都可以部署，部署好了就可以直接使用了，如果需要c++进行封装一层，则需要链接，对cmake熟悉的话链接也是比较简单的。以上就是今天讲述的内容，ffmpeg的so部署还是比较容易的，但是命令行的调用会麻烦一些，尤其是要解决ffmpeg退出问题，在c++中比较好解决，java理论上也比较好实现，如果在dart中则会比较麻烦，因为dart的方法通常不能跨线程调用，多线程的情况会出问题。
阿里云服务器下，部署LNMP环境安装wordpress
dl_11的博客
05-14 476
在阿里云环境下部署LNMP服务时，尤其是安装MySQL了时需要注意，和centos7不完全一样。在利用LNMP环境部署wordpress时，一定要先测试LNMP环境没问题，再部署wordpress，不然找问题好麻烦。MySQL和PHP，版本不同，部署和配置的方法不同，所以如果是安装的其他版本的本文章中的方法不一定实用。
安卓手机APP开发__支持64位的架构
红孩儿编程大师
05-15 622
在谷歌的应用中发布的APP需要支持64位的架构。添加上你的APP的64位的版本， 提供了性能上的提升，并且能够运行在仅支持64位的硬件上。
Android Audio基础——AudioFlinger回放录制线程（七）
最新发布
小旭的专栏
05-20 208
PlaybackThread 和 RecordThread 的基类。录制线程类，由 ThreadBase 派生。回放线程基类，同由 ThreadBase 派生。混音回放线程类，由 PlaybackThread 派生，负责处理标识为 AUDIO_OUTPUT_FLAG_PRIMARY、AUDIO_OUTPUT_FLAG_FAST、AUDIO_OUTPUT_FLAG_DEEP_BUFFER 的音频流，MixerThread 可以把多个音轨的数据混音后再输出。
中秋节月亮python
10-01
中秋节是中国的传统节日，人们在这一天会赏月，月亮是中秋节的重要象征之一。如果你想用Python绘制中秋节的月亮，可以使用海龟库来实现。根据引用中的代码，你可以使用turtle库的函数来画一个圆形的月亮。具体的步骤...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值