2019-03-14：哪些情况下会导致oom问题？

[Moosphan]

No description provided.

[ADrunkenLiBai]

该释放回收的资源没有释放掉，字节流没有关掉，activity被持有得不到释放，大图加载，等等等等

[Ssuiyingsen]

举个栗子
1.例如handler 在界面销毁的时候消息还未发送
2.file没有关流
3.查询到结果还没有停止
4.内部类持有外部类引用得不到释放
5.不用的对象最好null 让GC回收一下
6.图片资源什么的最好加一个软引用

[Moosphan]

@wardenlzr 使用 StringBuilder 代替 String 来实现大量字符串的拼接，之前回答的角度有问题

[jamsgithub]

StringBuilder ?? 能详解下不？
因为当我们创建一个String的变量后，当我们需要修改这个变量的值时，因为String是不可变对象，所以会新创建一个同名的变量String对象，并将以前的变量回收，而StringBuilder，在我们修改其值时，实际是对其对象本身操作，不涉及对象的新建和引用指向问题。如果我们不涉及到线程安全问题，我们可以使用StringBuilder(线程不安全的)，相反可以使用StringBuffer。详情可以参考这个:https://www.cnblogs.com/goody9807/p/6516374.html

[Alex-Cin]

该释放回收的资源没有释放掉，字节流没有关掉，activity被持有得不到释放，大图加载，等等等等

@ADrunkenLiBai
你这是内存泄漏， 并不是OOM；大图加载，算是OOM；

[Alex-Cin]

楼上好多在混淆 内存泄漏和内存溢出啊；
OOM常见就是，申请内存资源，语义上是正确的，但是JVM无法承载，出现不可原谅的错误, api叫Error；
大家顺便看另一个面试题 Error 和 Exception 的区别;
例如 for 100K 个 string， 或者 thread 或者其他对象， 或者加载100MB的png等等；
或者栈内存溢出，死循环调用方法等，但是方法栈溢出，也不能叫做OOM，可以算作内存溢出；

[jamsgithub]

楼上好多在混淆 内存泄漏和内存溢出啊；
OOM常见就是，申请内存资源，语义上是正确的，但是JVM无法承载，出现不可原谅的错误, api叫Error；
大家顺便看另一个面试题 Error 和 Exception 的区别;
例如 for 100K 个 string， 或者 thread 或者其他对象， 或者加载100MB的png等等；
或者栈内存溢出，死循环调用方法等，但是方法栈溢出，也不能叫做OOM，可以算作内存溢出；

但是过多的内存泄漏容易导致内存溢出出现的频率。

[Alex-Cin]

那就回答, 过多的泄漏也会导致溢出, 而不是回答什么情况会导致泄漏, 然后围绕着泄漏回答好多;
如果面试官让你解释内存泄漏, 再继续回答;
我的建议, 是这样的, 面试时间本就有限;
@jamsgithub

[darrenjh]

第6点，StringBuilder是什么意思？难道我用多了StringBuffer会造成内存溢出吗?

[MrSimpleX]

第6点，StringBuilder是什么意思？难道我用多了StringBuffer会造成内存溢出吗?

直接使用String会创建销毁多个实例，对性能有影响，StringBuffer只会一直操作同一个StringBuffer对象，就优化了内存使用。另外new的对象的内存超过了虚拟机的最大内存并且GC不掉就会内存溢出吧

[liupengfei666]

个人觉得没毛病，内存溢出跟内存泄漏还是有区别的。过多的内存泄漏会导致内存溢出，但是内存泄漏不一定会导致内存溢出，还是要严谨一点。

[risechen]

1、根据java的内存模型会出现内存溢出的内存有堆内存、方法区内存、虚拟机栈内存、native方法区内存；
2、一般说的OOM基本都是针对堆内存；
3、对于堆内存溢出主的根本原因有两种
（1）app进程内存达到上限
（2）手机可用内存不足，这种情况并不是我们app消耗了很多内存，而是整个手机内存不足
4、而我们需要解决的主要是app的内存达到上限
5、对于app内存达到上限只有两种情况
（1）申请内存的速度超出gc释放内存的速度
（2）内存出现泄漏，gc无法回收泄漏的内存，导致可用内存越来越少
6、对于申请内存速度超出gc释放内存的速度主要有2种情况
（1）往内存中加载超大文件
（2）循环创建大量对象
7、一般申请内存的速度超出gc释放内存基本不会出现，内存泄漏才是出现问题的关键所在
8、内存泄漏常见场景
（1）资源对象没关闭造成的内存泄漏（如： Cursor、File等）
（2）全局集合类强引用没清理造成的内存泄漏（特别是 static 修饰的集合）
（3）接收器、监听器注册没取消造成的内存泄漏，如广播，eventsbus
（4）Activity 的 Context 造成的泄漏，可以使用 ApplicationContext
（5）单例中的static成员间接或直接持有了activity的引用
（6）非静态内部类持有父类的引用，如非静态handler持有activity的引用
9、怎么对内存进行优化呢
三个方向
（1）为应用申请更大内存，把manifest上的largdgeheap设置为true
（2）减少内存的使用
①使用优化后的集合对象，比如SpaseArray；
②使用微信的mmkv替代sharedpreference；
③对于经常打log的地方使用StringBuilder来组拼，替代String拼接
④统一带有缓存的基础库，特别是图片库，如果用了两套不一样的图片加载库就会出现2个图片各自维护一套图片缓存
⑤给ImageView设置合适尺寸的图片，列表页显示缩略图，查看大图显示原图
⑥优化业务架构设计，比如省市区数据分批加载，需要加载省就加载省，需要加载市就加载失去，避免一下子加载所有数据
（3）避免内存泄漏
编码规范上：
①资源对象用完一定要关闭，最好加finally
②静态集合对象用完要清理
③接收器、监听器使用时候注册和取消成对出现
④context使用注意生命周期，如果是静态类引用直接用ApplicationContext
⑤使用静态内部类
⑥结合业务场景，设置软引用，弱引用，确保对象可以在合适的时机回收
建设内存监控体系：
线下监控：
①使用ArtHook检测图片尺寸是否超出imageview自身宽高的2倍
②编码阶段Memery Profile看app的内存使用情况，是否存在内存抖动，内存泄漏，结合Mat分析内存泄漏
线上监控：
①上报app使用期间待机内存、重点模块内存、OOM率
②上报整体及重点模块的GC次数，GC时间
③使用LeakCannery自动化内存泄漏分析
10、真的出现低内存，设置一个兜底策略
低内存状态回调，根据不同的内存等级做一些事情，比如在最严重的等级清空所有的bitmap，关掉所有界面，直接强制把app跳转到主界面，相当于app重新启动了一次一样，这样就避免了系统Kill应用进程，与其让系统kill进程还不如浪费一些用户体验，自己主动回收内存

[RedDargon]

OOM 即 out of memory 内存溢出 。
每个进程能够支配的内存是有限的，所以资源要记得使用完及时释放，如果未释放，就有可能造成内存泄漏，内存泄漏达到一定程度 手机就会造成内存溢出。
业务场景上面的话多为加载过大的图片，或者代码问题造成的各种内存泄漏累积出现的内存溢出 。

[ChenLeizheng]

线程开多了
java.lang.OutOfMemoryError: pthread_create (stack size 16384 bytes) failed: Try again

[KollerWithDoris]

线程开多了
java.lang.OutOfMemoryError: pthread_create (stack size 16384 bytes) failed: Try again

我记得一个线程要占大约2M的内存大小。所以开多了肯定会有内存问题。

[ZHANGfeng-james]

我遇到的一般是：线程创建过多和加载较大的资源文件。

确实应该区分：内存溢出和内存泄漏。

[siren4]

首先明确一点，内存泄漏和内存溢出是不同的，但是过多的内存泄漏会导致内存溢出。
内存溢出的根本原因：
1.应用申请内存的速度超过了gc内存回收的速度。
2.应用申请的内存大小超过了手机的可用内存。

常见的内存溢出的原因：
1.加载超大的图片、文件
2.创建大量的对象

内存优化的方法：
1.申请更大的内存，比如多进程、设置manifest中的largeHeap=true等。
2.减少内存使用
①使用优化后的集合对象，分场景使用SpaseArray和HashMap；
②使用微信的mmkv替代sharedpreference；
③使用StringBuilder替代String拼接
④统一带有缓存的基础库，特别是图片库，如果用了两套不一样的图片加载库就会出现2个图片各自维护一套图片缓存
⑤给ImageView设置合适尺寸的图片，列表页显示缩略图，查看大图显示原图
⑥优化业务架构设计，比如省市区数据分批加载，需要加载省就加载省，需要加载市就加载失去，避免一下子加载所有数据
3.避免内存泄漏

[wangxuyang518]

1.内存泄露
2.写代码在异常中再次重启，陷入无限循环会出现oom
3.资源文件没关闭，例如contentresolver
4.bitmap 没有及时回收。可以减少argb色彩模式占用的大小，尽可能减少bitmap消耗的内存
5android tv 本身内存较少，加载过多的摄像头视频，也会oom

[nealkafuly]

这位同学，单例模式不会照成内存泄漏，Context引用没有及时释放而已，根本原因不是单例模式。
解决方案：Util.release()即可

[nealkafuly]

[Mrsunbw]

1、过多的内存泄漏
2、加载大图
3、创建大量线程

[JesusYoung]

线程池使用不合理，例如使用FixedThreadPool和SingleThreadPool时，由于这两个线程池的任务队列是无界的LinkedBlockingQueue，所以无限制的添加新任务，当任务过多时会导致OOM发生，或者使用CachedThreadPool时，最大线程数没有限制，创建过多线程，导致OOM

[MoJieBlog]

内存溢出(oom)说白了就是应用要申请的内存大于手机对该应用的限制。因此所有导致内存增长的操作都是有可能导致内存溢出的。之所以没有看到内存只增不减，是因为JVM的自动垃圾回收机制。所以上面说的导致oom的情况，只是某些特定场景。并不是说加载小图就不会oom，也不是说创建一个线程就不会oom,也不是说内存泄漏就一定会oom...举个例子：

比如：假如你有一个10立方米的水桶，你一次倒入1立方米的水，前10次都不会溢出，但是第11次就要开始往外取1立方水（相当于内存回收）才能继续倒水，不然就会溢出水（oom）。

[mlinqirong]

1过多的内存泄漏会导致内存溢出
2,加载大的图片
3,创建过多的线程

[yline]

OOM，内存溢出。

从应用的角度来看，当内存超过系统给当前进程允许的最大内存，或者，系统的内存不足，无法分配新的内存时；就会触发OOM。
从编码的场景来看，就是内存不够了，因此，只要申请了内存的操作，都有可能会触发OOM。

这也是为啥，OOM上报的堆栈，往往都是无用的，大概率并不能直接用于解决OOM的Crash。