匿名内部类/Lambda Java和Kotlin谁会导致内存泄漏?

作者:小鱼人爱编程

前言

内存泄漏是程序界永恒的话题,对于Android开发来说尤为重要,想让你的App表现得更优雅,了解并治理内存泄漏问题势在必行。

通过本篇文章,你将了解到:

  1. 何为内存泄漏?
  2. Android 常见内存泄漏场景
  3. Java匿名内部类会导致泄漏吗?
  4. Java的Lambda是否会泄漏?
  5. Kotlin匿名内部类会导致泄漏吗?
  6. Kotlin的Lambda是否会泄漏?
  7. Kotlin高阶函数的会泄漏吗?
  8. 内存泄漏总结

1. 何为内存泄漏?

简单内存分布

如上图,系统在分配内存的时候,会寻找空闲的内存块进行分配(有些需要连续的存储空间)。

分配成功,则标记该内存块被占用,当内存块不再被使用时,则置为空闲。

占用和被占用涉及到内存的分配和释放,在不同的程序语言里有不同的封装。

C 分配/释放内存函数:

分配:malloc函数

释放:free函数

C++ 分配/释放内存函数:

分配:new函数

释放:delete函数

C/C++ 需要程序员手动分配和释放内存,而我们知道手动的东西容易遗漏。

如果一块内存永远不再被使用,但是又没有被回收,那么这段内存一直无法被复用,这就是内存泄漏

Java内存泄漏

鉴于C/C++ 需要手动释放内存容易遗漏最后造成内存泄漏的问题,Java在内存回收机制上做了改进:
不需要程序员手动释放内存,JVM系统有GC机制,定期扫描不再被引用的对象,将对象所占的的内存空间释放。

你可能会有疑惑:既然都有GC机制了,为啥还会有泄漏呢?

因为GC是根据可达性来判别对象是否还在使用,当GC动作发生时,如果一个对象被gc root对象持有,那么它是无法被回收的。

如上图,obj1obj5被gc root 直接或间接持有,它们是不会被回收的,而obj6obj10 没有被gc root持有,它们是可以被回收的。

常见的作为gc root的对象

JVM在发起GC 动作的时候,需要从gc root出发判别对象的可达性,常见的gc root对象:

开发里排查内存泄漏涉及比较多的gc root是:

JNI 变量、静态引用、活动的线程

如果不涉及到JNI开发,我们更多关注的是后两者。

到此,我们知道了Java内存泄漏的缘由:

不再被使用的对象,因为一些不当的操作导致其被gc root持有无法被回收,最终内存泄漏

2. Android 常见内存泄漏场景

经典泄漏问题

Handler使用不当泄漏

先看耳熟能详的Demo:

public class ThirdActivity extends AppCompatActivity {
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_third);
    }

    private Handler handler = new Handler() {
        @Override
        public void handleMessage(@NonNull Message msg) {
            super.handleMessage(msg);
            Log.d("fish", "hello world");
        }
    };
}

上面有个匿名内部类,继承自Handler。

我们知道在Java里,匿名内部类默认持有外部类引用,并且此处编译器会有提示:

This Handler class should be static or leaks might occur (anonymous android.os.Handler)

意思是:

推荐使用静态类来继承Handler,因为使用匿名内部类可能会有内存泄漏风险

我们做个实验,操作步骤:打开Activity,关闭Activity,观察内存使用状况,是否发生内存泄漏。

问题来了:以上代码会有内存泄漏吗?

答案当然是否定的,因为我们并没有使用handler对象。

将代码改造一下,onCreate里新增如下代码:

        handler.sendEmptyMessageDelayed(2, 5000);

此时会发生内存泄漏吗?

当然肉眼是无法证明是否泄漏的,我们通过使用Android Studio自带的性能分析工具:Profiler 进行分析:

果然Activity发生泄漏了。

如何规避此种场景下的内存泄漏呢?

public class ThirdActivity extends AppCompatActivity {
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_third);

        new MyHandler().sendEmptyMessageDelayed(2, 5000);
    }

    static class MyHandler extends Handler {
        @Override
        public void handleMessage(@NonNull Message msg) {
            super.handleMessage(msg);
            Log.d("fish", "hello world");
        }
    }
}

使用静态内部类实现Handler功能,静态内部类默认没有持有外部类引用。

检测结果,没有发生内存泄漏。

无论是匿名内部类还是静态内部类,都没有显式地持有外部类引用,既然匿名内部类会发生泄漏,那为啥还需要匿名内部类呢?

匿名内部类优点:

  1. 无需重新定义新的具名类
  2. 符合条件的匿名内部类可以转为Lambda表达式,简洁
  3. 匿名内部类可以直接访问外部类引用

假若现在需要在收到message时弹出个Toast。

对于匿名内部类的实现很简单:

    private Handler handler = new Handler() {
        @Override
        public void handleMessage(@NonNull Message msg) {
            super.handleMessage(msg);
            Toast.makeText(ThirdActivity.this, "hello world", Toast.LENGTH_SHORT).show();
        }
    };

因为它默认持有外部类引用。

而对于静态内部类,则提示无法访问外部类对象。

需要给它单独传递外部类引用,相较于匿名内部类比较繁琐。

Handler 泄漏的本质原因

对于当前的Demo来说,匿名内部类隐式持有外部类引用,我们需要需要找到匿名内部类被哪个gc root直接/间接地持有了。

由图可知,最终Activity被Thread持有了。

简单回顾源码流程:

  1. 构造Handler对象时会绑定当前线程的Looper,Looper里持有MessageQueue引用
  2. 当前线程的Looper存储在Thread里的ThreadLocal
  3. 当Handler发送消息的时候,构造Message对象,而该Message对象持有Handler引用
  4. Message对象将会被放置在MessageQueue里
  5. 由此推断,Thread将会间接持有Handler,而Handler又持有外部类引用,最终Thread将会间接持有外部类引用,导致了泄漏

线程使用不当泄漏

先看简单Demo:

public class ThirdActivity extends AppCompatActivity {
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_third);

        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    Thread.sleep(200000);
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
            }
        });
    }
}

问:上述代码会发生内存泄漏吗?

答:当然不会,因为线程并没有开启。

public class ThirdActivity extends AppCompatActivity {
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_third);

        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    Thread.sleep(200000);
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
            }
        }).start();
    }
}

再分析分析,会有内存泄漏吗?

与之前的Handler一致,匿名内部类会持有外部类的引用,而匿名内部类本身又被线程持有,因此会发生泄漏。

如何规避此种场景下的内存泄漏呢?

有两种方式:
第一种:使用静态内部类替换匿名内部类

此种方式同Handler处理类似。

第二种:使用Lambda替换匿名内部类

public class ThirdActivity extends AppCompatActivity {
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_third);

        new Thread(() -> {
            try {
                Thread.sleep(200000);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        }).start();
    }
}

Lambda表达式没有隐式持有外部类,因此此种场景下不会有内存泄漏风险。

注册不当内存泄漏

模拟一个简单下载过程,首先定义一个下载管理类:

public class DownloadManager {
   private DownloadManager() {
   }
   static class Inner {
      private static final DownloadManager ins = new DownloadManager();
   }
   public static DownloadManager getIns() {
      return Inner.ins;
   }
   private HashMap<String, DownloadListener> map = new HashMap();
   //模拟注册
   public void download(DownloadListener listener, String path) {
      map.put(path, listener);
      new Thread(() -> {
         //模拟下载
         listener.onSuc();
      }).start();
   }
}

interface DownloadListener {
   void onSuc();
   void onFail();
}

外部传入下载路径,下载成功后通知外界调用者:

public class ThirdActivity extends AppCompatActivity {
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_third);

        DownloadManager.getIns().download(new DownloadListener() {
            @Override
            public void onSuc() {
                //更新UI
            }
            @Override
            public void onFail() {
            }
        }, "hello test");
    }
}

因为需要在下载回调时更新UI,因此选择匿名内部类接收回调,而因为该匿名内部类被静态变量: DownloadManager.ins 持有。

也就是说:

静态变量作为gc root,间接持有匿名内部类,最终持有Activity导致了泄漏

如何规避此种场景下的内存泄漏呢?

有两种方式:

  1. 静态内部类持有Activity弱引用
  2. DownloadManager提供反注册方式,当Activity销毁时反注册从Map里移除回调

3. Java匿名内部类会导致泄漏吗?

线程持有匿名内部类对象

内存泄漏的一些前置知识已经过了一遍,接下来我们从字节码的角度分别分析匿名内部类、Lambda表达式、高阶函数是否存在泄漏问题。

先看Demo:

public class ThirdActivity extends AppCompatActivity {
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_third);
        new Thread(new Runnable() {
            @Override
            public void run() {
                Log.d("fish", "hello world");
            }
        }).start();
    }
}

当我们进入Activity,而后又退出时,猜猜会发生泄漏吗?

有些小伙伴会说:当然了,线程持有匿名内部类对象,而匿名内部类对象又持有外部类(Activity)引用。

实际上是此处的线程并没有执行耗时任务,很快就结束了,系统回收Activity对象时线程已经结束了,不会再持有匿名内部类对象了。

怎么确定匿名内部类持有外部类引用呢?

一个很直观的表现:

在匿名内部类里访问外部类实例变量,若是编译器没有提示错误,则可以认为匿名内部类持有外部类引用

当然,想要看到石锤就得从字节码出发了。

Java匿名内部类Class文件

build一下并查找Javac的产物:在/build/intermediates/javac 开头的目录下

这里是看不到匿名内部类的,需要到文件浏览器里查找。

可以看出,我们只是声明了一个ThirdActivity类,但是生成了两个Class文件,其中一个是匿名内部类生成的,通常命名方式为:外部类名+"$"+"第几个内部类"+".class"。

拖到Studio里查看内容:

显然匿名内部类构造函数形参里有外部类的类型,当构造匿名内部类时会传递进去并赋值给匿名内部类的成员变量。

Java匿名内部类字节码

查看字节码方式有多种,可以用javap命令:

javap -c ThirdActivity$1.class

也可以在Android Studio里下载字节码插件:

在源文件上右键选择查看字节码:

可以看出:

  1. New 指令创建匿名内部类对象并复制到操作数栈顶
  2. 加载外部类对象到操作数栈顶
  3. 调用匿名内部类构造函数,并将第2步的栈顶对象传入

如此一来,匿名内部类创建了,并且持有了外部类引用。

回到最初问题,Java匿名内部类是否会泄漏呢?

当外部类销毁的时候,如果匿名内部类被gc root 持有(间接/直接),那么将会发生内存泄漏

4. Java的Lambda是否会泄漏?

线程持有Lambda对象

将上小结的匿名内部类改造为Lambda(注:不是所有的匿名内部类都可以转为Lambda表达式)

public class ThirdActivity extends AppCompatActivity {
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_third);
        new Thread(() -> {
            Log.d("fish", "hello world");
            Log.d("fish", "hello world2");
        }).start();
    }
}

Java Lambda生成的Class文件

Java Lambda并没有生成Class文件。

Java Lambda字节码

Java Lambda并没有生成Class文件,而是通过INVOKEDYNAMIC 指令动态生成Runnable对象,最后传入Thread里。

可以看出,此时生成的Lambda并没有持有外部类引用。

Java Lambda显式持有外部类引用

public class ThirdActivity extends AppCompatActivity {
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_third);
        new Thread(() -> {
            //显式持有外部类引用
            Log.d("fish", ThirdActivity.class.getName());
        }).start();
    }
}

再查看字节码:

可以看出,传入了外部类引用。

回到最初问题,Java Lambda是否会泄漏呢?

  1. Lambda没有隐式持有外部类引用,
  2. 若在Lambda内显式持有外部类引用,那么此时和Java 匿名内部类类似的,当外部类销毁的时候,如果Lambda被gc root 持有(间接/直接),那么将会发生内存泄漏

5. Kotlin匿名内部类会导致泄漏吗?

线程持有匿名内部类对象

class FourActivity : AppCompatActivity() {
    private lateinit var binding: ActivityFourBinding
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityFourBinding.inflate(layoutInflater)
        setContentView(binding.root)
        Thread(object : Runnable {
            override fun run() {
                println("hello world")
            }
        }).start()
    }
}

此时匿名内部类会持有外部类引用吗?

先从生成的Class文件入手。

Kotlin 匿名内部类生成的Class文件

Kotlin编译生成的Class目录:build/tmp/kotlin-classes/ 查找生成的Class文件:

我们发现生成了Class文件,命名规则:外部类名+方法名+第几个匿名内部类+".class"

Kotlin 匿名内部类字节码

可以看出,并没有持有外部类引用。

Kotlin 匿名内部类显式持有外部类引用

class FourActivity : AppCompatActivity() {
    val name = "fish"
    private lateinit var binding: ActivityFourBinding
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityFourBinding.inflate(layoutInflater)
        setContentView(binding.root)
        Thread(object : Runnable {
            override fun run() {
                println("hello world $name")
            }
        }).start()
    }
}

查看字节码:

由此可见,构造函数携带了外部类引用。

回到最初问题,Kotlin 匿名内部类是否会泄漏呢?

  1. Kotlin 匿名内部类没有隐式持有外部类引用,
  2. 若在Kotlin 匿名内部类内显式持有外部类引用,那么此时和Java 匿名内部类类似的,当外部类销毁的时候,如果Lambda被gc root 持有(间接/直接),那么将会发生内存泄漏

6. Kotlin的Lambda是否会泄漏?

线程持有Lambda对象

class FourActivity : AppCompatActivity() {
    private lateinit var binding: ActivityFourBinding
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityFourBinding.inflate(layoutInflater)
        setContentView(binding.root)
        Thread { println("hello world ") }
    }
}

此时Lambda会持有外部类引用吗?

先从生成的Class文件入手。

Kotlin Lambda生成的Class文件

Kotlin Lambda 并没有生成Class文件。

Kotlin Lambda字节码

可以看出,并没有隐式持有外部类引用。

Kotlin Lambda显式持有外部类引用

class FourActivity : AppCompatActivity() {
    val name = "fish"
    private lateinit var binding: ActivityFourBinding
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityFourBinding.inflate(layoutInflater)
        setContentView(binding.root)
        Thread { println("hello world $name") }
    }
}

查看字节码:

由此可见,构造函数携带了外部类引用。

回到最初问题,Kotlin Lambda是否会泄漏呢?

和Java Lambda表述一致

7. Kotlin高阶函数的会泄漏吗?

什么是高阶函数?

将函数类型当做形参或返回值的函数称为高阶函数。

高阶函数在Kotlin里无处不在,是Kotlin简洁写法的一大利器。

高阶函数生成的Class文件

class FourActivity : AppCompatActivity() {
    private lateinit var binding: ActivityFourBinding
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityFourBinding.inflate(layoutInflater)
        setContentView(binding.root)
        test {
            println("$it")
        }
    }
    //高阶函数作为形参
    private fun test(block:(String) -> Unit) {
        block.invoke("fish")
    }
}

很简单的一个高阶函数,查看生成的Class文件:

查看Kotlin Bytecode内容:

final class com/fish/perform/FourActivity$onCreate$1 extends kotlin/jvm/internal/Lambda implements kotlin/jvm/functions/Function1 {

继承自Lambda,并实现了Function1接口。

它的构造函数并没有形参,说明不会传入外部类引用。

高阶函数的字节码

和之前分析的匿名内部类和Lambda不同的是(虽然高阶函数也可以用Lambda简化表达):涉及到了GETSTATIC指令。

该指令意思是从静态变量里获取高阶函数的引用,在高阶函数的字节码加载的时候就已经将静态变量初始化:

可以这么理解:

  1. 高阶函数的Class加载的时候会初始化实例,并将该实例存储在静态变量里
  2. 当外部调用高阶函数时,从静态变量里获取高阶函数实例

高阶函数显式持有外部类引用

class FourActivity : AppCompatActivity() {
    val name="fish"
    private lateinit var binding: ActivityFourBinding
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityFourBinding.inflate(layoutInflater)
        setContentView(binding.root)
        test {
            println("$it:$name")
        }
    }
    //高阶函数作为形参
    private fun test(block:(String) -> Unit) {
        block.invoke("fish")
    }
}

查看字节码:

构造函数持有了外部类引用,此时并没有生成静态变量(没必要生成,若生成了就是妥妥的内存泄漏了)

回到最初问题,高阶函数是否会泄漏呢?

  1. 高阶函数没有隐式持有外部类引用
  2. 若在高阶函数内显式持有外部类引用,那么此时和Java 匿名内部类类似的,当外部类销毁的时候,如果高阶函数被gc root 持有(间接/直接),那么将会发生内存泄漏

8. 内存泄漏总结

简单理解内存泄漏:

  1. 长生命周期的对象持有短生命周期的对象,导致短生命周期的对象在生命周期结束后没有被及时回收,导致内存无法复用,最终泄漏
  2. 合理地释放对短生命周期对象的引用

为了帮助到大家更好的全面清晰的掌握好性能优化,准备了相关的核心笔记(还该底层逻辑):https://qr18.cn/FVlo89

性能优化核心笔记:https://qr18.cn/FVlo89

启动优化

内存优化

UI优化

网络优化

Bitmap优化与图片压缩优化https://qr18.cn/FVlo89

多线程并发优化与数据传输效率优化

体积包优化

《Android 性能监控框架》:https://qr18.cn/FVlo89

《Android Framework学习手册》:https://qr18.cn/AQpN4J

  1. 开机Init 进程
  2. 开机启动 Zygote 进程
  3. 开机启动 SystemServer 进程
  4. Binder 驱动
  5. AMS 的启动过程
  6. PMS 的启动过程
  7. Launcher 的启动过程
  8. Android 四大组件
  9. Android 系统服务 - Input 事件的分发过程
  10. Android 底层渲染 - 屏幕刷新机制源码分析
  11. Android 源码分析实战
相关推荐
吾日三省吾码10 分钟前
JVM 性能调优
java
stm 学习ing15 分钟前
FPGA 第十讲 避免latch的产生
c语言·开发语言·单片机·嵌入式硬件·fpga开发·fpga
Estar.Lee16 分钟前
查手机号归属地免费API接口教程
android·网络·后端·网络协议·tcp/ip·oneapi
温辉_xh38 分钟前
uiautomator案例
android
湫ccc1 小时前
《Python基础》之字符串格式化输出
开发语言·python
弗拉唐1 小时前
springBoot,mp,ssm整合案例
java·spring boot·mybatis
oi772 小时前
使用itextpdf进行pdf模版填充中文文本时部分字不显示问题
java·服务器
mqiqe2 小时前
Python MySQL通过Binlog 获取变更记录 恢复数据
开发语言·python·mysql
工业甲酰苯胺2 小时前
MySQL 主从复制之多线程复制
android·mysql·adb