一点关于内存溢出的疑问

ambe_gzy 2019-04-03 03:50:26

今天学习到了内存溢出，定义内部静态类就能一定程度的避免内存溢出，但是如果每次遇到可能内存溢出的情况都把非静态类改为静态类来避免，这岂不是会很多静态类？这样内存够用吗？

...全文

488 10 打赏收藏转发到动态举报

写回复

用AI写文章

10 条回复

切换为时间正序

请发表友善的回复…

发表回复

ambe_gzy 2019-04-09

打赏
举报

引用 8 楼追风筝的孩子的回复：

如果忘记写静态内部类了，99.9%情况下都不会内存泄漏。楼主应该是看了一个handler泄漏的例子吧，内部类创建的时候，即使构造函数是空的，但实际上字节码里面会把外部类作为内部类构造函数的参数传进来的。如果一个handler postDelay一个runnable，这个时候activity因为其他原因摧毁了，才会造成泄漏，但是这个泄漏并不会很长，只要runnable执行了就没有引用了，就不存在泄漏了，而且一般人用handler poseDelay也不会太长，太长就不适合用这个了。另外在onDestroy里面removeCallBack也可以有效避免这种情况。静态内部类只是手段。

也就是说，所谓的内存泄漏是指内部类持有外部类的引用并处于耗时的执行状态的时候外部类无法回收，当内部类执行完毕以后外部类和内部类都可以回收？这样理解对吗？

追风筝的孩子 2019-04-09

打赏
举报

引用 9 楼 ambe_gzy 的回复:

[quote=引用 8 楼追风筝的孩子的回复：]如果忘记写静态内部类了，99.9%情况下都不会内存泄漏。楼主应该是看了一个handler泄漏的例子吧，内部类创建的时候，即使构造函数是空的，但实际上字节码里面会把外部类作为内部类构造函数的参数传进来的。如果一个handler postDelay一个runnable，这个时候activity因为其他原因摧毁了，才会造成泄漏，但是这个泄漏并不会很长，只要runnable执行了就没有引用了，就不存在泄漏了，而且一般人用handler poseDelay也不会太长，太长就不适合用这个了。另外在onDestroy里面removeCallBack也可以有效避免这种情况。静态内部类只是手段。

也就是说，所谓的内存泄漏是指内部类持有外部类的引用并处于耗时的执行状态的时候外部类无法回收，当内部类执行完毕以后外部类和内部类都可以回收？这样理解对吗？[/quote]对的。

追风筝的孩子 2019-04-07

打赏
举报

如果忘记写静态内部类了，99.9%情况下都不会内存泄漏。楼主应该是看了一个handler泄漏的例子吧，内部类创建的时候，即使构造函数是空的，但实际上字节码里面会把外部类作为内部类构造函数的参数传进来的。如果一个handler postDelay一个runnable，这个时候activity因为其他原因摧毁了，才会造成泄漏，但是这个泄漏并不会很长，只要runnable执行了就没有引用了，就不存在泄漏了，而且一般人用handler poseDelay也不会太长，太长就不适合用这个了。另外在onDestroy里面removeCallBack也可以有效避免这种情况。静态内部类只是手段。

王能 2019-04-04

打赏
举报

参照这篇博客的常见问题3内存泄漏相关：https://blog.csdn.net/weimingjue/article/details/87921494 要了解原理，而不是只看表现，内存泄漏的原因是无法回收导致的，非静态内部类只要能回收想怎么用就怎么用。

王能 2019-04-04

打赏
举报

谁告诉你：非静态内部类会出现内存泄漏？

亲爱的Joe 2019-04-04

打赏
举报

你的问题更像是一个哲学问题。如果一个非静态内部类的对象被引用了,那么该类也应该被认为是正在被使用，正在被使用的类不能被回收，这是正常的合理的。所以，不能认为一个类的非静态内部类的对象被引用了而该类本身却需要被垃圾回收器回收掉

快乐的编码小猪 2019-04-04

打赏
举报

首先非静态内部类产生内存泄漏的原因在于1.非静态内部类的对象持有外部类的引用。2非静态内部类的对象被其他对象引用，其他对象有可能是生命周期比Activity或者Fragment长，特别是异步场景。要想阻止这方面的内存泄漏方法有在Activity的onDestroy方法中，断开其他对象对非静态内部类的引用即可。可以参考EventBus的unregister方法，原理类似。在设计外部类的时候，如果有引用非静态内部类对象的方法，那么同时需要提供解除引用的方法。