写点什么

【JVM 性能优化】服务发生 OOM 故障定位方案

用户头像
Java架构师
关注
发布于: 33 分钟前

前提概要

对于 JVM 服务而言出现了 OOM(Out Of Memory)问题,并且对其进行相关的解决是作为一个 Java 技术栈人员必备的实战能力。在此总结了一些相对通用的方案,希望能帮助到大家

分析原因

某 Java 服务出现了 OOM,最常见的原因为:


  1. 有可能是内存分配确实过小,而正常业务使用了大量内存(正常现象)

  2. 某一个对象被频繁申请,却没有释放,内存不断泄漏,导致内存耗尽(内存泄漏、代码问题)

  3. 某一个资源被频繁申请,系统资源耗尽,例如:不断创建线程,不断发起网络连接(线程不断创建、代码问题)

排查方案

确认是不是内存本身就分配过小

方法:jmap -heap pid



如上图,可以查看新生代,老生代堆内存的分配大小以及使用情况,看是否本身分配过小。

找到最耗内存的对象

方法:jmap -histo:live 10765 | more



如上图,输入命令后,会以表格的形式显示存活对象的信息,并按照所占内存大小排序:


  • 实例数

  • 所占内存大小

  • 类名


是不是很直观?对于实例数较多,占用内存大小较多的实例/类,相关的代码就要针对性 review 了。


上图中占内存最多的对象是 RingBufferLogEvent,共占用内存 18M,属于正常使用范围。


如果发现某类对象占用内存很大(例如几个 G),很可能是类对象创建太多,且一直未释放。例如:


  • 申请完资源后,未调用 close()或 dispose()释放资源

  • 消费者消费速度慢(或停止消费了),而生产者不断往队列中投递任务,导致队列中任务累积过多


线上执行该命令会强制执行一次 fullgc。另外还可以 dump 内存进行分析

确认是否是资源耗尽

工具:

  • pstree

  • netstat


查看进程创建的线程数,以及网络连接数,如果资源耗尽,也可能出现 OOM


这里介绍另一种方法,通过


/proc/${PID}/fd/proc/${PID}/task
复制代码


可以分别查看句柄详情和线程数。


例如,某一台线上服务器的 sshd 进程 PID 是 9339,查看


ll /proc/9339/fdll /proc/9339/task
复制代码


如上图,sshd 共占用了四个句柄


  • 0 -> 标准输入

  • 1 -> 标准输出

  • 2 -> 标准错误输出

  • 3 -> socket(容易想到是监听端口)


sshd 只有一个主线程 PID 为 9339,并没有多线程。


所以,只要


ll /proc/${PID}/fd | wc -lll /proc/${PID}/task | wc -l (效果等同pstree -p | wc -l)
复制代码


就能知道进程打开的句柄数和线程数。

Java 内存溢出 OOM

JVM 中常见的两个错误


  • StackoverFlowError :栈溢出

  • OutOfMemoryError: java heap space:堆溢出


除此之外,还有以下的错误


java.lang.StackOverflowErrorjava.lang.OutOfMemoryError:java heap spacejava.lang.OutOfMemoryError:GC overhead limit exceeededjava.lang.OutOfMemoryError:Direct buffer memoryjava.lang.OutOfMemoryError:unable to create new native threadjava.lang.OutOfMemoryError:Metaspace
复制代码


OutOfMemoryError 和 StackOverflowError 是属于 Error,不是 Exception

StackoverFlowError

堆栈溢出,我们有最简单的一个递归调用,就会造成堆栈溢出,也就是深度的方法调用栈一般是 512K,不断的深度调用,直到栈被撑破


public class StackOverflowErrorDemo {  public static void main(String[] args) {    stackOverflowError();  }  /**   * 栈一般是512K,不断的深度调用,直到栈被撑破   * Exception in thread "main" java.lang.StackOverflowError   */  private static void stackOverflowError() {    stackOverflowError();  }}
复制代码

运行结果

Exception in thread "main" java.lang.StackOverflowError  at com.moxi.interview.study.oom.StackOverflowErrorDemo.stackOverflowError(StackOverflowErrorDemo.java:17)
复制代码

OutOfMemoryError:java heap space

创建了很多对象,导致堆空间不够存储


public class JavaHeapSpaceDemo {  public static void main(String[] args) {    // 堆空间的大小 -Xms10m -Xmx10m    // 创建一个 80M的字节数组    byte [] bytes = new byte[80 * 1024 * 1024];  }}
复制代码


我们创建一个 80M 的数组,会直接出现 Java heap space


Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
复制代码

GC overhead limit exceeded

GC 回收时间过长时会抛出 OutOfMemoryError,过长的定义是,超过了 98%的时间用来做 GC,并且回收了不到 2%的堆内存



为了更快的达到效果,我们首先需要设置 JVM 启动参数


-Xms10m -Xmx10m -XX:+PrintGCDetails -XX:MaxDirectMemorySize=5m
复制代码


异常出现的步骤就是,我们不断的像 list 中插入 String 对象,直到启动 GC 回收


public class GCOverheadLimitDemo {  public static void main(String[] args) {    int i = 0;    List<String> list = new ArrayList<>();    try {      while(true) {      //1.6时intern()方法发现字符串常量池(存储永久代)没有就复制,物理拷贝      //1.7时intern()方法发现字符串常量池(存储堆)没有就在保存地址值映射实际堆内存对象        list.add(String.valueOf(++i).intern());      }    } catch (Exception e) {      System.out.println("***************i:" + i);      e.printStackTrace();      throw e;    } finally {    }  }}
复制代码

运行结果

[Full GC (Ergonomics) [PSYoungGen: 2047K->2047K(2560K)] [ParOldGen: 7106K->7106K(7168K)] 9154K->9154K(9728K), [Metaspace: 3504K->3504K(1056768K)], 0.0311093 secs] [Times: user=0.13 sys=0.00, real=0.03 secs] [Full GC (Ergonomics) [PSYoungGen: 2047K->0K(2560K)] [ParOldGen: 7136K->667K(7168K)] 9184K->667K(9728K), [Metaspace: 3540K->3540K(1056768K)], 0.0058093 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] Heap PSYoungGen   total 2560K, used 114K [0x00000000ffd00000, 0x0000000100000000, 0x0000000100000000) eden space 2048K, 5% used [0x00000000ffd00000,0x00000000ffd1c878,0x00000000fff00000) from space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000) to  space 512K, 0% used [0x00000000fff00000,0x00000000fff00000,0x00000000fff80000) ParOldGen    total 7168K, used 667K [0x00000000ff600000, 0x00000000ffd00000, 0x00000000ffd00000) object space 7168K, 9% used [0x00000000ff600000,0x00000000ff6a6ff8,0x00000000ffd00000) Metaspace    used 3605K, capacity 4540K, committed 4864K, reserved 1056768K class space  used 399K, capacity 428K, committed 512K, reserved 1048576KException in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded  at java.lang.Integer.toString(Integer.java:403)  at java.lang.String.valueOf(String.java:3099)  at com.moxi.interview.study.oom.GCOverheadLimitDemo.main(GCOverheadLimitDemo.java:18)
复制代码


我们能够看到 多次 Full GC,并没有清理出空间,在多次执行 GC 操作后,就抛出异常 GC overhead limit

Direct buffer memory

Netty + NIO:这是由于 NIO 引起的


  1. NIO 程序的时候经常会使用 ByteBuffer 来读取或写入数据,这是一种基于通道(Channel)与缓冲区(Buffer)的 I/O 方式,它可以使用 Native 函数库直接分配堆外内存

  2. 然后通过一个存储在 Java 堆里面的 DirectByteBuffer 对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能,因为避免了在 Java 堆和 Native 堆中来回复制数据。


ByteBuffer.allocate(capability):第一种方式是分配 JVM 堆内存,属于 GC 管辖范围,由于需要拷贝所以速度相对较慢


ByteBuffer.allocteDirect(capability):第二种方式是分配 OS 本地内存,不属于 GC 管辖范围,由于不需要内存的拷贝,所以速度相对较快


如果不断分配本地内存,堆内存很少使用,那么 JVM 就不需要执行 GC,DirectByteBuffer 对象就不会被回收,这时候堆内存充足,但本地内存可能已经使用光了,再次尝试分配本地内存就会出现 OutOfMemoryError,那么程序就崩溃了


一句话说:本地内存不足,但是堆内存充足的时候,就会出现这个问题


我们使用 -XX:MaxDirectMemorySize=5m 配置能使用的堆外物理内存为 5M


-Xms20m -Xmx20m -XX:+PrintGCDetails -XX:MaxDirectMemorySize=5m
复制代码


然后我们申请一个 6M 的空间


// 只设置了 5M 的物理内存使用,但是却分配 6M 的空间 ByteBuffer bb = ByteBuffer.allocateDirect(6 * 1024 * 1024); 这个时候,运行就会出现问题了


配置的 maxDirectMemory:5.0MB


[GC (System.gc()) [PSYoungGen: 2030K->488K(2560K)] 2030K->796K(9728K), 0.0008326 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [Full GC (System.gc()) [PSYoungGen: 488K->0K(2560K)] [ParOldGen: 308K->712K(7168K)] 796K->712K(9728K), [Metaspace: 3512K->3512K(1056768K)], 0.0052052 secs] [Times: user=0.09 sys=0.00, real=0.00 secs] Exception in thread "main" java.lang.OutOfMemoryError: Direct buffer memory  at java.nio.Bits.reserveMemory(Bits.java:693)  at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:123)  at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)  at com.moxi.interview.study.oom.DIrectBufferMemoryDemo.main(DIrectBufferMemoryDemo.java:19)
复制代码

unable to create new native thread

不能够创建更多的新的线程了,也就是说创建线程的上限达到了


在高并发场景的时候,会应用到


高并发请求服务器时,经常会出现如下异常 java.lang.OutOfMemoryError:unable to create new native thread,准确说该 native thread 异常与对应的平台有关

导致原因:

应用创建了太多线程,一个应用进程创建多个线程,超过系统承载极限


服务器并不允许你的应用程序创建这么多线程,Linux 系统默认运行单个进程可以创建的线程为 1024 个,如果应用创建超过这个数量,就会报 java.lang.OutOfMemoryError:unable to create new native thread

解决方法

  • 想办法降低你应用程序创建线程的数量,分析应用是否真的需要创建这么多线程,如果不是,改代码将线程数降到最低

  • 对于有的应用,确实需要创建很多线程,远超过 linux 系统默认 1024 个线程限制,可以通过修改 linux 服务器配置,扩大 linux 默认限制


public class UnableCreateNewThreadDemo {  public static void main(String[] args) {    for (int i = 0; ; i++) {      System.out.println("************** i = " + i);      new Thread(() -> {        try {          TimeUnit.SECONDS.sleep(Integer.MAX_VALUE);        } catch (InterruptedException e) {          e.printStackTrace();        }      }, String.valueOf(i)).start();    }  }}
复制代码


这个时候,就会出现下列的错误,线程数大概在 900 多个


Exception in thread "main" java.lang.OutOfMemoryError: unable to cerate new native thread
复制代码
如何查看线程数
ulimit -u
复制代码

Metaspace

元空间内存不足,Matespace 元空间应用的是本地内存


-XX:MetaspaceSize 的初始化大小为 20M

元空间是什么

元空间就是我们的方法区,存放的是类模板,类信息,常量池等


Metaspace 是方法区 HotSpot 中的实现,它与持久代最大的区别在于:Metaspace 并不在虚拟内存中,而是使用本地内存,也即在 java8 中,class metadata(the virtual machines internal presentation of Java class),被存储在叫做 Metaspace 的 native memory


永久代(java8 后背元空间 Metaspace 取代了)存放了以下信息:


  • 虚拟机加载的类信息

  • 常量池

  • 静态变量

  • 即时编译后的代码


模拟 Metaspace 空间溢出,我们不断生成类 往元空间里灌输,类占据的空间总会超过 Metaspace 指定的空间大小


代码 在模拟异常生成时候,因为初始化的元空间为 20M,因此我们使用 JVM 参数调整元空间的大小,为了更好的效果


-XX:MetaspaceSize=8m -XX:MaxMetaspaceSize=8m
复制代码

代码如下:

public class MetaspaceOutOfMemoryDemo {  // 静态类  static class OOMTest {  }  public static void main(final String[] args) {    // 模拟计数多少次以后发生异常    int i =0;    try {      while (true) {        i++;        // 使用Spring的动态字节码技术        Enhancer enhancer = new Enhancer();        enhancer.setSuperclass(OOMTest.class);        enhancer.setUseCache(false);        enhancer.setCallback(new MethodInterceptor() {          @Override          public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {            return methodProxy.invokeSuper(o, args);          }        });      }    } catch (Exception e) {      System.out.println("发生异常的次数:" + i);      e.printStackTrace();    } finally {    }  }
复制代码


会出现以下错误:


发生异常的次数: 201


java.lang.OutOfMemoryError:Metaspace
复制代码

注意

  • 在 JDK1.7 之前:永久代是方法区的实现,存放了运行时常量池、字符串常量池和静态变量等。

  • 在 JDK1.7:永久代是方法区的实现,将字符串常量池和静态变量等移出至堆内存。运行时常量池等剩下的还再永久代(方法区)


在 JDK1.8 及以后:永久代被元空间替代,相当于元空间实现方法区,此时字符串常量池和静态变量还在堆,运行时常量池还在方法区(元空间),元空间使用的是直接内存。


  • -XX:MetaspaceSize=N//设置 Metaspace 的初始(和最小大小)

  • -XX:MaxMetaspaceSize=N//设置 Metaspace 的最大大小 与永久代很大的不同就是,如果不指定大小的话,随着更多类的创建,虚拟机会耗尽所有可用的系统内存


用户头像

Java架构师

关注

还未添加个人签名 2021.05.28 加入

还未添加个人简介

评论

发布
暂无评论
【JVM性能优化】服务发生OOM故障定位方案