1. 什么是 OOM, 为什么会 OOM 及一些解决方法
1.1. OOM 含义:
OOM, 全称 “Out Of Memory”, 意思是 “内存用完了”。 它来源于 java.lang.OutOfMemoryError。
1.2. 为什么会出现OOM:
官方介绍为当 JVM 因为没有足够的内存来为对象分配空间并且垃圾回收器也已经没有空间可回收时, 就会抛出 java.lang.OutOfMemoryError: ··· (注意: 这是个很严重的问题, 因为这个问题已经严重到不足以被应用处理)。
具体原因大致为两方面:
- 自身原因: 比如虚拟机本身可使用的内存太少。
- 外在原因: 如应用使用的太多, 且用完没释放, 浪费了内存。此时就会造成内存泄露或者内存溢出。
内存泄露: 申请使用完的内存没有释放, 导致虚拟机不能再次使用该内存, 此时这段内存就泄露了, 因为申请者不用了, 而又不能被虚拟机分配给别人用。
内存溢出: 申请的内存超出了 JVM 能提供的内存大小, 此时称之为溢出。
1.3. OOM 的 error 类型
首先说一下 JAVA 虚拟机运行时会管理的内存区域吧:
- 程序计数器: 当前线程执行的字节码的行号指示器, 线程私有
- JAVA 虚拟机栈: Java 方法执行的内存模型, 每个 Java 方法的执行对应着一个栈帧的进栈和出栈的操作。
- 本地方法栈: 类似 “JAVA 虚拟机栈”, 但是为 native 方法的运行提供内存环境。
- JAVA 堆: 对象内存分配的地方, 内存垃圾回收的主要区域, 所有线程共享。可分为新生代, 老生代。
- 方法区: 用于存储已经被 JVM 加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。Hotspot 中的 “永久代”。
- 运行时常量池: 方法区的一部分, 存储常量信息, 如各种字面量、符号引用等。
- 直接内存: 并不是 JVM 运行时数据区的一部分, 可直接访问的内存, 比如 NIO 会用到这部分。
所以除了程序计数器不会抛出 OOM 外, 其他各个内存区域都可能会抛出 OOM。
常见 OOM 情况:
- java.lang.OutOfMemoryError: Java heap space ------>java 堆内存溢出, 此种情况最常见, 一般由于内存泄露或者堆的大小设置不当引起。对于内存泄露, 需要通过内存监控软件查找程序中的泄露代码, 而堆大小可以通过虚拟机参数 - Xms,-Xmx 等修改。
- java.lang.OutOfMemoryError: PermGen space ------>java 永久代溢出, 即方法区溢出了, 一般出现于大量 Class 或者 jsp 页面, 或者采用 cglib 等反射机制的情况, 因为上述情况会产生大量的 Class 信息存储于方法区。当出现此种情况时可以通过更改方法区的大小来解决, 使用类似 - XX:PermSize=64m -XX:MaxPermSize=256m 的形式修改。注意, 过多的常量尤其是字符串也会导致方法区溢出。
- java.lang.StackOverflowError ------> 不会抛 OOM error, 但也是比较常见的 Java 内存溢出。JAVA 虚拟机栈溢出, 一般是由于程序中存在死循环或者深度递归调用造成的, 栈大小设置太小也会出现此种溢出。可以通过虚拟机参数 - Xss 来设置栈的大小。
1.4. OOM 分析
Heap Dump(堆转储文件)它是一个 Java 进程在某个时间点上的内存快照。Heap Dump 是有着多种类型的。不过总体上 heap dump 在触发快照的时候都保存了 java 对象和类的信息。通常在写 heap dump 文件前会触发一次 FullGC, 所以 heap dump 文件中保存的是 FullGC 后留下的对象信息。
通过设置如下的 JVM 参数, 可以在发生 OutOfMemoryError 后获取到一份 HPROF 二进制 Heap Dump 文件:
-XX:+HeapDumpOnOutOfMemoryError
生成的文件会直接写入到工作目录。
注意: 该方法需要 JDK5 以上版本。
转存堆内存信息后, 需要对文件进行分析, 从而找到 OOM 的原因。可以使用以下方式:
- mat: eclipse memory analyzer, 基于 eclipse RCP 的内存分析工具。具体使用参考: http://www.eclipse.org/mat/, 推荐使用。
- jhat: JDK 自带的 java heap analyze tool, 可以将堆中的对象以 html 的形式显示出来, 包括对象的数量, 大小等等, 并支持对象查询语言 OQL, 分析相关的应用后, 可以通过 http://localhost:7000 来访问分析结果。不推荐使用。
1.5. 九种 OOM 常见原因及解决方案
1、 Java heap space
当堆内存 (Heap Space) 没有足够空间存放新创建的对象时, 就会抛出 java.lang.OutOfMemoryError:Java heap space 错误(根据实际生产经验, 可以对程序日志中的 OutOfMemoryError 配置关键字告警, 一经发现, 立即处理)。
原因分析
Javaheap space 错误产生的常见原因可以分为以下几类：
- 请求创建一个超大对象，通常是一个大数组。
- 超出预期的访问量/数据量，通常是上游系统请求流量飙升，常见于各类促销/秒杀活动，可以结合业务流量指标排查是否有尖状峰值。
- 过度使用终结器（Finalizer），该对象没有立即被 GC。
- 内存泄漏（Memory Leak），大量对象引用没有释放，JVM 无法对其自动回收，常见于使用了 File 等资源没有回收。
解决方案
针对大部分情况，通常只需要通过 -Xmx 参数调高 JVM 堆内存空间即可。如果仍然没有解决，可以参考以下情况做进一步处理：
- 如果是超大对象，可以检查其合理性，比如是否一次性查询了数据库全部结果，而没有做结果数限制。
- 如果是业务峰值压力，可以考虑添加机器资源，或者做限流降级。
- 如果是内存泄漏，需要找到持有的对象，修改代码设计，比如关闭没有释放的连接。
2、PermGen space
该错误表示永久代 (Permanent Generation) 已用满, 通常是因为加载的 class 数目太多或体积太大。
原因分析
永久代存储对象主要包括以下几类：
- 加载/缓存到内存中的 class 定义，包括类的名称，字段，方法和字节码；
- 常量池；
- 对象数组/类型数组所关联的 class；
- JIT 编译器优化后的 class 信息。
PermGen 的使用量与加载到内存的 class 的数量/大小正相关。
解决方案
根据 Permgen space 报错的时机，可以采用不同的解决方案，如下所示：
- 程序启动报错，修改 -XX:MaxPermSize 启动参数，调大永久代空间。
- 应用重新部署时报错，很可能是没有应用没有重启，导致加载了多份 class 信息，只需重启 JVM 即可解决。
- 运行时报错，应用程序可能会动态创建大量 class，而这些 class 的生命周期很短暂，但是 JVM 默认不会卸载 class，可以设置 -XX:+CMSClassUnloadingEnabled 和 -XX:+UseConcMarkSweepGC这两个参数允许 JVM 卸载 class。
- 如果上述方法无法解决，可以通过 jmap 命令 dump 内存对象 jmap-dump:format=b,file=dump.hprof ，然后利用 Eclipse MAT https://www.eclipse.org/mat 功能逐一分析开销最大的 classloader 和重复 class。
34、GC overhead limit exceeded
当 Java 进程花费 98% 以上的时间执行 GC，但只恢复了不到 2% 的内存，且该动作连续重复了 5 次，就会抛出 java.lang.OutOfMemoryError:GC overhead limit exceeded 错误。简单地说，就是应用程序已经基本耗尽了所有可用内存， GC 也无法回收。
此类问题的原因与解决方案跟 Javaheap space 非常类似，可以参考上文。
4、Metaspace
JDK 1.8 使用 Metaspace 替换了永久代（Permanent Generation），该错误表示 Metaspace 已被用满，通常是因为加载的 class 数目太多或体积太大。
此类问题的原因与解决方法跟 Permgenspace 非常类似，可以参考上文。需要特别注意的是调整 Metaspace 空间大小的启动参数为 -XX:MaxMetaspaceSize。
5、Unable to create new native thread
每个 Java 线程都需要占用一定的内存空间，当 JVM 向底层操作系统请求创建一个新的 native 线程时，如果没有足够的资源分配就会报此类错误。
原因分析
JVM 向 OS 请求创建 native 线程失败，就会抛出 Unableto createnewnativethread，常见的原因包括以下几类：
- 线程数超过操作系统最大线程数 ulimit 限制；
- 线程数超过 kernel.pid_max（只能重启）；
- native 内存不足；
该问题发生的常见过程主要包括以下几步：
- JVM 内部的应用程序请求创建一个新的 Java 线程；
- JVM native 方法代理了该次请求，并向操作系统请求创建一个 native 线程；
- 操作系统尝试创建一个新的 native 线程，并为其分配内存；
- 如果操作系统的虚拟内存已耗尽，或是受到 32 位进程的地址空间限制，操作系统就会拒绝本次 native 内存分配；
- JVM 将抛出 java.lang.OutOfMemoryError:Unableto createnewnativethread 错误。
解决方案
- 升级配置，为机器提供更多的内存；
- 降低 Java Heap Space 大小；
- 修复应用程序的线程泄漏问题；
- 限制线程池大小；
- 使用 -Xss 参数减少线程栈的大小；
- 调高 OS 层面的线程最大数：执行 ulimia-a 查看最大线程数限制，使用 ulimit-u xxx 调整最大线程数限制。
ulimit -a … 省略部分内容 … max user processes (-u) 16384
6、Out of swap space？
该错误表示所有可用的虚拟内存已被耗尽。虚拟内存（Virtual Memory）由物理内存（Physical Memory）和交换空间（Swap Space）两部分组成。当运行时程序请求的虚拟内存溢出时就会报 Outof swap space? 错误。
原因分析
该错误出现的常见原因包括以下几类：
- 地址空间不足；
- 物理内存已耗光；
- 应用程序的本地内存泄漏（native leak），例如不断申请本地内存，却不释放。
- 执行 jmap-histo:live 命令，强制执行 Full GC；如果几次执行后内存明显下降，则基本确认为 Direct ByteBuffer 问题。
解决方案
根据错误原因可以采取如下解决方案：
- 升级地址空间为 64 bit；
- 使用 Arthas 检查是否为 Inflater/Deflater 解压缩问题，如果是，则显式调用 end 方法。
- Direct ByteBuffer 问题可以通过启动参数 -XX:MaxDirectMemorySize 调低阈值。
- 升级服务器配置/隔离部署，避免争用。
7、 Kill process or sacrifice child
有一种内核作业（Kernel Job）名为 Out of Memory Killer，它会在可用内存极低的情况下“杀死”（kill）某些进程。OOM Killer 会对所有进程进行打分，然后将评分较低的进程“杀死”，具体的评分规则可以参考 Surviving the Linux OOM Killer。
不同于其他的 OOM 错误， Killprocessorsacrifice child 错误不是由 JVM 层面触发的，而是由操作系统层面触发的。
原因分析
默认情况下，Linux 内核允许进程申请的内存总量大于系统可用内存，通过这种“错峰复用”的方式可以更有效的利用系统资源。
然而，这种方式也会无可避免地带来一定的“超卖”风险。例如某些进程持续占用系统内存，然后导致其他进程没有可用内存。此时，系统将自动激活 OOM Killer，寻找评分低的进程，并将其“杀死”，释放内存资源。
解决方案
- 升级服务器配置/隔离部署，避免争用。
- OOM Killer 调优。
8、Requested array size exceeds VM limit
JVM 限制了数组的最大长度，该错误表示程序请求创建的数组超过最大长度限制。
JVM 在为数组分配内存前，会检查要分配的数据结构在系统中是否可寻址，通常为 Integer.MAX_VALUE-2。
此类问题比较罕见，通常需要检查代码，确认业务是否需要创建如此大的数组，是否可以拆分为多个块，分批执行。
9、Direct buffer memory
ava 允许应用程序通过 Direct ByteBuffer 直接访问堆外内存，许多高性能程序通过 Direct ByteBuffer 结合内存映射文件（Memory Mapped File）实现高速 IO。
原因分析
Direct ByteBuffer 的默认大小为 64 MB，一旦使用超出限制，就会抛出 Directbuffer memory 错误。
解决方案
- Java 只能通过 ByteBuffer.allocateDirect 方法使用 Direct ByteBuffer，因此，可以通过 Arthas 等在线诊断工具拦截该方法进行排查。
- 检查是否直接或间接使用了 NIO，如 netty，jetty 等。
- 通过启动参数 -XX:MaxDirectMemorySize 调整 Direct ByteBuffer 的上限值。
- 检查 JVM 参数是否有 -XX:+DisableExplicitGC 选项，如果有就去掉，因为该参数会使 System.gc() 失效。
- 检查堆外内存使用代码，确认是否存在内存泄漏；或者通过反射调用 sun.misc.Cleaner 的 clean() 方法来主动释放被 Direct ByteBuffer 持有的内存空间。
- 内存容量确实不足，升级配置。
推荐工具&产品
JVM 内存分析工具 mat
1、Eclipse Memory Analyzer
https://www.eclipse.org/mat
阿里云 APM 产品，支持 OOM 异常关键字告警
2、ARMS
https://help.aliyun.com/document_detail/42966.html?spm=a2c4g.11174283.6.685.d69b668cuztvff
阿里 Java 在线诊断工具 Arthas(阿尔萨斯)
3、alibaba Arthas
https://github.com/alibaba/arthas
2. 补充一下Java 四种引用类型：
强引用
强引用是最普遍的引用，如果一个对象具有强引用，垃圾回收器不会回收该对象，当内存空间不足时，JVM 宁愿抛出 OutOfMemoryError异常；只有当这个对象没有被引用时，才有可能会被回收。
package com.wts;
import java.util.ArrayList;
import java.util.List;
public class StrongReferenceTest {
static class BigObject {
private Byte[] bytes = new Byte[1024 * 1024];
}
public static void main(String[] args) {
List<BigObject> list = new ArrayList<>();
while (true) {
BigObject obj = new BigObject();
list.add(obj);
}
}
}
BigObject obj = new BigObject()创建的这个对象时就是强引用，上面的main方法最终将抛出OOM异常：
软引用
软引用是用来描述一些有用但并不是必需的对象，适合用来实现缓存(比如浏览器的‘后退’按钮使用的缓存)，内存空间充足的时候将数据缓存在内存中，如果空间不足了就将其回收掉。
如果一个对象只具有软引用，则当内存空间足够，垃圾回收器就不会回收它。
- 当内存空间不足了，就会回收该对象。
- JVM会优先回收长时间闲置不用的软引用的对象，对那些刚刚构建的或刚刚使用过的“新”软引用对象会尽可能保留。
- 如果回收完还没有足够的内存，才会抛出内存溢出异常。只要垃圾回收器没有回收它，该对象就可以被程序使用。
package com.wts;
import java.lang.ref.SoftReference;
public class SoftReferenceTest {
static class Person {
private String name;
private Byte[] bytes = new Byte[1024 * 1024];
public Person(String name) {
this.name = name;
}
}
public static void main(String[] args) throws InterruptedException {
Person person = new Person("张三");
SoftReference<Person> softReference = new SoftReference<>(person);
person = null; //去掉强引用，new Person("张三")的这个对象就只有软引用了
System.gc();
Thread.sleep(1000);
System.err.println("软引用的对象 ------->" + softReference.get());
}
}
弱引用
被弱引用关联的对象实例只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时， 无论当前内存是否足够，都会回收掉只被弱引用关联的对象实例。在 JDK 1.2 之 后，提供了 WeakReference 类来实现弱引用。
public static void main(String[] args) throws InterruptedException {
Person person = new Person("张三");
ReferenceQueue<Person> queue = new ReferenceQueue<>();
WeakReference<Person> weakReference = new WeakReference<Person>(person, queue);
person = null;//去掉强引用，new Person("张三")的这个对象就只有软引用了
System.gc();
Thread.sleep(1000);
System.err.println("弱引用的对象 ------->" + weakReference.get());
Reference weakPollRef = queue.poll(); //poll()方法是有延迟的
if (weakPollRef != null) {
System.err.println("WeakReference对象中保存的弱引用对象已经被GC，下一步需要清理该Reference对象");
//清理softReference
} else {
System.err.println("WeakReference对象中保存的软引用对象还没有被GC，或者被GC了但是获得对列中的引用对象出现延迟");
}
}
被弱引用关联的对象实例只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时， 无论当前内存是否足够，都会回收掉只被弱引用关联的对象实例。在 JDK 1.2 之 后，提供了 WeakReference 类来实现弱引用。
public static void main(String[] args) throws InterruptedException {
Person person = new Person("张三");
ReferenceQueue<Person> queue = new ReferenceQueue<>();
WeakReference<Person> weakReference = new WeakReference<Person>(person, queue);
person = null;//去掉强引用，new Person("张三")的这个对象就只有软引用了
System.gc();
Thread.sleep(1000);
System.err.println("弱引用的对象 ------->" + weakReference.get());
Reference weakPollRef = queue.poll(); //poll()方法是有延迟的
if (weakPollRef != null) {
System.err.println("WeakReference对象中保存的弱引用对象已经被GC，下一步需要清理该Reference对象");
//清理softReference
} else {
System.err.println("WeakReference对象中保存的软引用对象还没有被GC，或者被GC了但是获得对列中的引用对象出现延迟");
}
}
虚引用
虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么就和没有任何引用一样，在任何时候都可能被垃圾回收。
Object object = new Object();
ReferenceQueue queue = new ReferenceQueue ();
PhantomReference pr = new PhantomReference (object, queue);
ThreadLocal_OOM
测试配置堆内存大小：
代码块：
public class ThreadLocal_OOM {
private static final int A = 500;
//创建线程池，固定为5个
final static ThreadPoolExecutor tpe = new ThreadPoolExecutor(
5,5,1,TimeUnit.MINUTES,
new LinkedBlockingQueue<Runnable>());
//创建一个用来创建数组的类
static class fiveByte{
//开一个大小为5m的数组
private byte[] a = new byte[1024*1024*5];
}
//创建 ThreadLocal对象
final static ThreadLocal<fiveByte> threadLocalForFB = new ThreadLocal<>();
public static class testThread implements Runnable{
@Override
public void run(){
//创建一个数组实例，大小约为25兆
fiveByte lV1 = new fiveByte();
System.out.println("I just miss u Alizary");
}
}
public static void main(String[] args) throws InterruptedException {
Object o = new Object();
for(int i = 0; i < A; ++i){
testThread thread = new testThread();
tpe.execute(thread);
}
Thread.sleep(100);
}
}
跑起来看看内存情况
内存变化大小情况：平均稳定在800M
再看看加入ThreadLocal对象的情况：
public static class testThread implements Runnable{
@Override
public void run(){
//创建一个数组实例，大小约为25兆
fiveByte lV1 = new fiveByte();
//加入ThreadLocal
threadLocalForFB.set(lV1);
//fiveByte lV2 = new fiveByte();
System.out.println("I just miss u Alizary");
}
}
再来看内存情况：
可以看到启动 ThreadLocal 后内存占用上了200M
这时候当我们手动释放内存：
public static class testThread implements Runnable{
@Override
public void run(){
//创建一个数组实例，大小约为25兆
fiveByte lV1 = new fiveByte();
//加入ThreadLocal
threadLocalForFB.set(lV1);
//fiveByte lV2 = new fiveByte();
threadLocalForFB.remove();
System.out.println("I just miss u Alizary");
}
}
很明显内存情况回到了只开5个数组的大小，可以说明启动ThreadLocal肯定发生了OOM
回顾ThreadLocal
根据上一篇文章写的，每次声明创建 Thread 就声明一个ThreadLocalMap，而ThreadLocalMap里面的每个Enty[ ] 里的 key 是 ThreadLocal 实例本身，而 value 是真正需要存储的 Object对象，也就证明ThreadLocal 就只是一个对象实例 ，它只是作为一个 key 来让线程从 ThreadLocalMap 的 Enty[ ] 中拿到相对应的 value。仔细观察 ThreadLocalMap。
就可以根据ThreadLocal对象和对应线程对象的栈堆情况来分析，画出他们的引用情况。
从源码得知，只有 map 是使用ThreadLocal 的弱引用作为 Key的（WeakReference）：
static class ThreadLocalMap {
static class Entry extends WeakReference<ThreadLocal<?>> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal<?> k, Object v) {super(k);value = v;}
}
因此使用了 ThreadLocal 后，引用链如图所示:
虚线表示弱引用
当线程把 threadlocal 变量指向** null** 后，没有任何强引用指向** threadlocal** 实例，所以** threadlocal** 将会被 GC 回收。ThreadLocalMap 中就出现 key 为 null 的 Entry，这些 key 为 null 的 value自然也不能再访问，如果这些线程继续跑得话，这些 key 为 null 的 Entry 的 value 就会一直存在一条强引用链：
Thread对象 —> Thread —> ThreaLocalMap —> Entry —> value
而这些 value 永远不会被访问到了，这就会OOM。
只有当前** thread** 结束以后，**current thread **就不会存在栈中，强引用断开， **Current Thread、Map value **将全部被 GC 回收。最好的做法是不在需要使用ThreadLocal 变量后，都调用它的 remove() 方法，清除数据。
回到代码块中，虽然线程池里面的任务执行完毕了，但是线程池里面的 5 个线程会一直存在直到** JVM** 退出， set 了线程的localVariable 变量后没有调用 localVariable.remove() 方法，导致线程池里面的 5 个线程的 threadLocals 变量里面的** new LocalVariable()** 实例没有被释放。
而 ThreadLocal 的实现，无论是 get()、set() 在某些时候，调用了**expungeStaleEntry **方法用来清除 Entry 中 Key 为 null 的 **Value **：
get( ):
private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {
Entry[] tab = table;
int len = tab.length;
while (e != null) {
ThreadLocal<?> k = e.get();
if (k == key)
return e;
if (k == null)
------有机会被调用到用来清除 key 为 null 的 Value 值-----
expungeStaleEntry(i);
else
i = nextIndex(i, len);
e = tab[i];
}
return null;
}
set( ) :
if (k == key) {
e.value = value;
tab[i] = tab[staleSlot];
tab[staleSlot] = e;
// Start expunge at preceding stale entry if it exists
if (slotToExpunge == staleSlot)
slotToExpunge = i;
cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
return;
}
但是这是不及时的，意思就是不是每次都执行清除语句，所以一些情况下还是会发生内存泄露。只有 remove() 方法中显式调用了expungeStaleEntry 方法。
key 使用强引用：
引用 ThreadLocal 的对象被回收了，但是 ThreadLocalMap 还持有 ThreadLocal 的强引用，如果没有手动删除，ThreadLocal 的对象实例不会被回收，导致 Entry 内存泄漏。
key 使用弱引用：
引用的 ThreadLocal 的对象被回收了，由于 ThreadLocalMap 持有 ThreadLocal 的弱引用，即使没有手动删除，ThreadLocal 的对象实例也会被回收。value 在下一次ThreadLocalMap 调用** set，get，remove** 都有机会被回收。
比较两种情况，由于 ThreadLocalMap 的生命周期跟 Thread 一样长，如果都没有手动删除对应 key，都会导致内存泄漏，但是使用弱引用可以多一层保护机制。
因此，ThreadLocal 内存泄漏的原因是：由于 ThreadLocalMap 的生命周期跟Thread 一样长，如果没有手动删除对应 key 就会导致内存泄漏，而不是因为弱引用。
SoSoSoSo，ThreadLocal 变量用完了请记得 remove ，谢谢
参考文档：https://blog.csdn.net/wan212000/article/details/121659189
扫一扫
808
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
