Android-Daily-Interview
Android-Daily-Interview copied to clipboard
Moosphan
2019-03-14：哪些情况下会导致oom问题？
举个栗子 1.例如handler 在界面销毁的时候消息还未发送 2.file没有关流 3.查询到结果还没有停止 4.内部类持有外部类引用得不到释放 5.不用的对象最好null 让GC回收一下 6.图片资源什么的最好加一个软引用
StringBuilder ?? 能详解下不？ 因为当我们创建一个String的变量后，当我们需要修改这个变量的值时，因为String是不可变对象，所以会新创建一个同名的变量String对象，并将以前的变量回收，而StringBuilder，在我们修改其值时，实际是对其对象本身操作，不涉及对象的新建和引用指向问题。如果我们不涉及到线程安全问题，我们可以使用StringBuilder(线程不安全的)，相反可以使用StringBuffer。详情可以参考这个:https://www.cnblogs.com/goody9807/p/6516374.html
该释放回收的资源没有释放掉，字节流没有关掉，activity被持有得不到释放，大图加载，等等等等
@ADrunkenLiBai 你这是内存泄漏， 并不是OOM；大图加载，算是OOM；
楼上好多在混淆 内存泄漏和内存溢出啊；
OOM常见就是，申请内存资源，语义上是正确的，但是JVM无法承载，出现不可原谅的错误, api叫Error；
大家顺便看另一个面试题 Error 和 Exception 的区别;
例如 for 100K 个 string， 或者 thread 或者其他对象， 或者加载100MB的png等等；
或者栈内存溢出，死循环调用方法等，但是方法栈溢出，也不能叫做OOM，可以算作内存溢出；
楼上好多在混淆 内存泄漏和内存溢出啊； OOM常见就是，申请内存资源，语义上是正确的，但是JVM无法承载，出现不可原谅的错误, api叫Error； 大家顺便看另一个面试题 Error 和 Exception 的区别; 例如 for 100K 个 string， 或者 thread 或者其他对象， 或者加载100MB的png等等； 或者栈内存溢出，死循环调用方法等，但是方法栈溢出，也不能叫做OOM，可以算作内存溢出；
但是过多的内存泄漏容易导致内存溢出出现的频率。
那就回答, 过多的泄漏也会导致溢出, 而不是回答什么情况会导致泄漏, 然后围绕着泄漏回答好多;
如果面试官让你解释内存泄漏, 再继续回答;
我的建议, 是这样的, 面试时间本就有限;
@jamsgithub
第6点，StringBuilder是什么意思？难道我用多了StringBuffer会造成内存溢出吗?
直接使用String会创建销毁多个实例，对性能有影响，StringBuffer只会一直操作同一个StringBuffer对象，就优化了内存使用。另外new的对象的内存超过了虚拟机的最大内存并且GC不掉就会内存溢出吧
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进程还不如浪费一些用户体验，自己主动回收内存
OOM 即 out of memory 内存溢出 。 每个进程能够支配的内存是有限的，所以资源要记得使用完及时释放，如果未释放，就有可能造成内存泄漏，内存泄漏达到一定程度 手机就会造成内存溢出。 业务场景上面的话多为加载过大的图片，或者代码问题造成的各种内存泄漏累积出现的内存溢出 。
线程开多了 java.lang.OutOfMemoryError: pthread_create (stack size 16384 bytes) failed: Try again
线程开多了 java.lang.OutOfMemoryError: pthread_create (stack size 16384 bytes) failed: Try again
我记得一个线程要占大约2M的内存大小。所以开多了肯定会有内存问题。
首先明确一点，内存泄漏和内存溢出是不同的，但是过多的内存泄漏会导致内存溢出。 内存溢出的根本原因： 1.应用申请内存的速度超过了gc内存回收的速度。 2.应用申请的内存大小超过了手机的可用内存。
常见的内存溢出的原因： 1.加载超大的图片、文件 2.创建大量的对象
内存优化的方法： 1.申请更大的内存，比如多进程、设置manifest中的largeHeap=true等。 2.减少内存使用 ①使用优化后的集合对象，分场景使用SpaseArray和HashMap； ②使用微信的mmkv替代sharedpreference； ③使用StringBuilder替代String拼接 ④统一带有缓存的基础库，特别是图片库，如果用了两套不一样的图片加载库就会出现2个图片各自维护一套图片缓存 ⑤给ImageView设置合适尺寸的图片，列表页显示缩略图，查看大图显示原图 ⑥优化业务架构设计，比如省市区数据分批加载，需要加载省就加载省，需要加载市就加载失去，避免一下子加载所有数据 3.避免内存泄漏
1.内存泄露 2.写代码在异常中再次重启，陷入无限循环会出现oom 3.资源文件没关闭，例如contentresolver 4.bitmap 没有及时回收。可以减少argb色彩模式占用的大小，尽可能减少bitmap消耗的内存 5android tv 本身内存较少，加载过多的摄像头视频，也会oom
线程池使用不合理，例如使用FixedThreadPool和SingleThreadPool时，由于这两个线程池的任务队列是无界的LinkedBlockingQueue，所以无限制的添加新任务，当任务过多时会导致OOM发生，或者使用CachedThreadPool时，最大线程数没有限制，创建过多线程，导致OOM
内存溢出(oom)说白了就是应用要申请的内存大于手机对该应用的限制。因此所有导致内存增长的操作都是有可能导致内存溢出的。之所以没有看到内存只增不减，是因为JVM的自动垃圾回收机制。所以上面说的导致oom的情况，只是某些特定场景。并不是说加载小图就不会oom，也不是说创建一个线程就不会oom,也不是说内存泄漏就一定会oom...举个例子：
比如：假如你有一个10立方米的水桶，你一次倒入1立方米的水，前10次都不会溢出，但是第11次就要开始往外取1立方水（相当于内存回收）才能继续倒水，不然就会溢出水（oom）。
OOM，内存溢出。
从应用的角度来看，当内存超过系统给当前进程允许的最大内存，或者，系统的内存不足，无法分配新的内存时；就会触发OOM。 从编码的场景来看，就是内存不够了，因此，只要申请了内存的操作，都有可能会触发OOM。
这也是为啥，OOM上报的堆栈，往往都是无用的，大概率并不能直接用于解决OOM的Crash。
