Jstarfish资料

本文主要介绍Jstarfish资料 方法和在新技术下所面对的“挑战”,方便大家深入理解Jstarfish资料 过程。本文也将分享Jstarfish资料 所遇到的问题和应对策略,怎么解决怎么做的问题。
通过深入本文可以理解代码原理,进行代码文档的下载,也可以查看相应 Demo 部署效果。

点赞+收藏 就学会系列,文章收录在 GitHub JavaKeeper ,N线互联网开发必备技能兵器谱,笔记自取

Jstarfish

在《Java虚拟机规范》的规定里,除了程序计数器外,虚拟机内存的其他几个运行时区域都有发生 OutOfMemoryError 异常的可能。

本篇主要包括如下 OOM 的介绍和示例:

  • java.lang.StackOverflowError
  • java.lang.OutOfMemoryError: Java heap space
  • java.lang.OutOfMemoryError: GC overhead limit exceeded
  • java.lang.OutOfMemoryError–>Metaspace
  • java.lang.OutOfMemoryError: Direct buffer memory
  • java.lang.OutOfMemoryError: unable to create new native thread
  • java.lang.OutOfMemoryError:Metaspace
  • java.lang.OutOfMemoryError: Requested array size exceeds VM limit
  • java.lang.OutOfMemoryError: Out of swap space
  • java.lang.OutOfMemoryError:Kill process or sacrifice child

我们常说的 OOM 异常,其实是 Error

Jstarfish

一. StackOverflowError

1.1 写个 bug

public class StackOverflowErrorDemo {      public static void main(String[] args) {         javaKeeper();     }      private static void javaKeeper() {         javaKeeper();     } } 

上一篇详细的介绍过JVM 运行时数据区,JVM 虚拟机栈是有深度的,在执行方法的时候会伴随着入栈和出栈,上边的方法可以看到,main 方法执行后不停的递归,迟早把栈撑爆了

Exception in thread "main" java.lang.StackOverflowError 	at oom.StackOverflowErrorDemo.javaKeeper(StackOverflowErrorDemo.java:15) 

Jstarfish

1.2 原因分析

  • 无限递归循环调用(最常见原因),要时刻注意代码中是否有了循环调用方法而无法退出的情况
  • 执行了大量方法,导致线程栈空间耗尽
  • 方法内声明了海量的局部变量
  • native 代码有栈上分配的逻辑,并且要求的内存还不小,比如 java.net.SocketInputStream.read0 会在栈上要求分配一个 64KB 的缓存(64位 Linux)

1.3 解决方案

  • 修复引发无限递归调用的异常代码, 通过程序抛出的异常堆栈,找出不断重复的代码行,按图索骥,修复无限递归 Bug
  • 排查是否存在类之间的循环依赖(当两个对象相互引用,在调用toString方法时也会产生这个异常)
  • 通过 JVM 启动参数 -Xss 增加线程栈内存空间, 某些正常使用场景需要执行大量方法或包含大量局部变量,这时可以适当地提高线程栈空间限制

二. Java heap space

Java 堆用于存储对象实例,我们只要不断的创建对象,并且保证 GC Roots 到对象之间有可达路径来避免 GC 清除这些对象,那随着对象数量的增加,总容量触及堆的最大容量限制后就会产生内存溢出异常。

Java 堆内存的 OOM 异常是实际应用中最常见的内存溢出异常。

2.1 写个 bug

/**  * JVM参数:-Xmx12m  */ public class JavaHeapSpaceDemo {      static final int SIZE = 2 * 1024 * 1024;      public static void main(String[] a) {         int[] i = new int[SIZE];     } } 

代码试图分配容量为 2M 的 int 数组,如果指定启动参数 -Xmx12m,分配内存就不够用,就类似于将 XXXL 号的对象,往 S 号的 Java heap space 里面塞。

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space 	at oom.JavaHeapSpaceDemo.main(JavaHeapSpaceDemo.java:13) 

2.2 原因分析

  • 请求创建一个超大对象,通常是一个大数组
  • 超出预期的访问量/数据量,通常是上游系统请求流量飙升,常见于各类促销/秒杀活动,可以结合业务流量指标排查是否有尖状峰值
  • 过度使用终结器(Finalizer),该对象没有立即被 GC
  • 内存泄漏(Memory Leak),大量对象引用没有释放,JVM 无法对其自动回收,常见于使用了 File 等资源没有回收

2.3 解决方案

针对大部分情况,通常只需要通过 -Xmx 参数调高 JVM 堆内存空间即可。如果仍然没有解决,可以参考以下情况做进一步处理:

  • 如果是超大对象,可以检查其合理性,比如是否一次性查询了数据库全部结果,而没有做结果数限制
  • 如果是业务峰值压力,可以考虑添加机器资源,或者做限流降级。
  • 如果是内存泄漏,需要找到持有的对象,修改代码设计,比如关闭没有释放的连接

Jstarfish

面试官:说说内存泄露和内存溢出

加送个知识点,三连的终将成为大神~~

内存泄露和内存溢出

内存溢出(out of memory),是指程序在申请内存时,没有足够的内存空间供其使用,出现out of memory;比如申请了一个 Integer,但给它存了 Long 才能存下的数,那就是内存溢出。

内存泄露( memory leak),是指程序在申请内存后,无法释放已申请的内存空间,一次内存泄露危害可以忽略,但内存泄露堆积后果很严重,无论多少内存,迟早会被占光。

memory leak 最终会导致 out of memory!

三、GC overhead limit exceeded

JVM 内置了垃圾回收机制GC,所以作为 Javaer 的我们不需要手工编写代码来进行内存分配和释放,但是当 Java 进程花费 98% 以上的时间执行 GC,但只恢复了不到 2% 的内存,且该动作连续重复了 5 次,就会抛出 java.lang.OutOfMemoryError:GC overhead limit exceeded 错误(俗称:垃圾回收上头)。简单地说,就是应用程序已经基本耗尽了所有可用内存, GC 也无法回收。

假如不抛出 GC overhead limit exceeded 错误,那 GC 清理的那么一丢丢内存很快就会被再次填满,迫使 GC 再次执行,这样恶性循环,CPU 使用率 100%,而 GC 没什么效果。

3.1 写个 bug

出现这个错误的实例,其实我们写个无限循环,往 List 或 Map 加数据就会一直 Full GC,直到扛不住,这里用一个不容易发现的栗子。我们往 map 中添加 1000 个元素。

/**  * JVM 参数: -Xmx14m -XX:+PrintGCDetails  */ public class KeylessEntry {      static class Key {         Integer id;          Key(Integer id) {             this.id = id;         }          @Override         public int hashCode() {             return id.hashCode();         }     }      public static void main(String[] args) {         Map m = new HashMap();         while (true){             for (int i = 0; i < 1000; i++){                 if (!m.containsKey(new Key(i))){                     m.put(new Key(i), "Number:" + i);                 }             }             System.out.println("m.size()=" + m.size());         }     } } 
... m.size()=54000 m.size()=55000 m.size()=56000 Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded 

从输出结果可以看到,我们的限制 1000 条数据没有起作用,map 容量远超过了 1000,而且最后也出现了我们想要的错误,这是因为类 Key 只重写了 hashCode() 方法,却没有重写 equals() 方法,我们在使用 containsKey() 方法其实就出现了问题,于是就会一直往 HashMap 中添加 Key,直至 GC 都清理不掉。

🧑🏻‍💻 面试官又来了:说一下 HashMap 原理以及为什么需要同时实现 equals 和 hashcode

执行这个程序的最终错误,和 JVM 配置也会有关系,如果设置的堆内存特别小,会直接报 Java heap space。算是被这个错误截胡了,所以有时,在资源受限的情况下,无法准确预测程序会死于哪种具体的原因。

3.2 解决方案

  • 添加 JVM 参数 -XX:-UseGCOverheadLimit 不推荐这么干,没有真正解决问题,只是将异常推迟
  • 检查项目中是否有大量的死循环或有使用大内存的代码,优化代码
  • dump内存分析,检查是否存在内存泄露,如果没有,加大内存

四、Direct buffer memory

我们使用 NIO 的时候经常需要使用 ByteBuffer 来读取或写入数据,这是一种基于 Channel(通道) 和 Buffer(缓冲区)的 I/O 方式,它可以使用 Native 函数库直接分配堆外内存,然后通过一个存储在 Java 堆里面的 DirectByteBuffer 对象作为这块内存的引用进行操作。这样在一些场景就避免了 Java 堆和 Native 中来回复制数据,所以性能会有所提高。

Java 允许应用程序通过 Direct ByteBuffer 直接访问堆外内存,许多高性能程序通过 Direct ByteBuffer 结合内存映射文件(Memory Mapped File)实现高速 IO。

4.1 写个 bug

  • ByteBuffer.allocate(capability) 是分配 JVM 堆内存,属于 GC 管辖范围,需要内存拷贝所以速度相对较慢;

  • ByteBuffer.allocateDirect(capability)是分配 OS 本地内存,不属于 GC 管辖范围,由于不需要内存拷贝所以速度相对较快;

如果不断分配本地内存,堆内存很少使用,那么 JVM 就不需要执行 GC,DirectByteBuffer 对象就不会被回收,这时虽然堆内存充足,但本地内存可能已经不够用了,就会出现 OOM,本地直接内存溢出

/**  *  VM Options:-Xms10m,-Xmx10m,-XX:+PrintGCDetails -XX:MaxDirectMemorySize=5m  */ public class DirectBufferMemoryDemo {      public static void main(String[] args) {         System.out.println("maxDirectMemory is:"+sun.misc.VM.maxDirectMemory() / 1024 / 1024 + "MB");          //ByteBuffer buffer = ByteBuffer.allocate(6*1024*1024);         ByteBuffer buffer = ByteBuffer.allocateDirect(6*1024*1024);      } } 

最大直接内存,默认是电脑内存的 1/4,所以我们设小点,然后使用直接内存超过这个值,就会出现 OOM。

maxDirectMemory is:5MB Exception in thread "main" java.lang.OutOfMemoryError: Direct buffer memory 

4.2 解决方案

  1. Java 只能通过 ByteBuffer.allocateDirect 方法使用 Direct ByteBuffer,因此,可以通过 Arthas 等在线诊断工具拦截该方法进行排查
  2. 检查是否直接或间接使用了 NIO,如 netty,jetty 等
  3. 通过启动参数 -XX:MaxDirectMemorySize 调整 Direct ByteBuffer 的上限值
  4. 检查 JVM 参数是否有 -XX:+DisableExplicitGC 选项,如果有就去掉,因为该参数会使 System.gc() 失效
  5. 检查堆外内存使用代码,确认是否存在内存泄漏;或者通过反射调用 sun.misc.Cleanerclean() 方法来主动释放被 Direct ByteBuffer 持有的内存空间
  6. 内存容量确实不足,升级配置

五、Unable to create new native thread

每个 Java 线程都需要占用一定的内存空间,当 JVM 向底层操作系统请求创建一个新的 native 线程时,如果没有足够的资源分配就会报此类错误。

5.1 写个 bug

public static void main(String[] args) {   while(true){     new Thread(() -> {       try {         Thread.sleep(Integer.MAX_VALUE);       } catch(InterruptedException e) { }     }).start();   } } 
Error occurred during initialization of VM java.lang.OutOfMemoryError: unable to create new native thread 

5.2 原因分析

Jstarfish

JVM 向 OS 请求创建 native 线程失败,就会抛出 Unableto createnewnativethread,常见的原因包括以下几类:

  • 线程数超过操作系统最大线程数限制(和平台有关)
  • 线程数超过 kernel.pid_max(只能重启)
  • native 内存不足;该问题发生的常见过程主要包括以下几步:
    1. JVM 内部的应用程序请求创建一个新的 Java 线程;
    2. JVM native 方法代理了该次请求,并向操作系统请求创建一个 native 线程;
    3. 操作系统尝试创建一个新的 native 线程,并为其分配内存;
    4. 如果操作系统的虚拟内存已耗尽,或是受到 32 位进程的地址空间限制,操作系统就会拒绝本次 native 内存分配;
    5. JVM 将抛出 java.lang.OutOfMemoryError:Unableto createnewnativethread 错误。

5.3 解决方案

  1. 想办法降低程序中创建线程的数量,分析应用是否真的需要创建这么多线程
  2. 如果确实需要创建很多线程,调高 OS 层面的线程最大数:执行 ulimia-a 查看最大线程数限制,使用 ulimit-u xxx 调整最大线程数限制

六、Metaspace

JDK 1.8 之前会出现 Permgen space,该错误表示永久代(Permanent Generation)已用满,通常是因为加载的 class 数目太多或体积太大。随着 1.8 中永久代的取消,就不会出现这种异常了。

Metaspace 是方法区在 HotSpot 中的实现,它与永久代最大的区别在于,元空间并不在虚拟机内存中而是使用本地内存,但是本地内存也有打满的时候,所以也会有异常。

6.1 写个 bug

/**  * JVM Options: -XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m  */ public class MetaspaceOOMDemo {      public static void main(String[] args) {          while (true) {             Enhancer enhancer = new Enhancer();             enhancer.setSuperclass(MetaspaceOOMDemo.class);             enhancer.setUseCache(false);             enhancer.setCallback((MethodInterceptor) (o, method, objects, methodProxy) -> {                 //动态代理创建对象                 return methodProxy.invokeSuper(o, objects);             });             enhancer.create();         }     } } 

借助 Spring 的 GCLib 实现动态创建对象

Exception in thread "main" org.springframework.cglib.core.CodeGenerationException: java.lang.OutOfMemoryError-->Metaspace 

6.2 解决方案

方法区溢出也是一种常见的内存溢出异常,在经常运行时生成大量动态类的应用场景中,就应该特别
Jstarfish资料部分资料来自网络,侵权毕设源码联系删除

区块链毕设网(www.qklbishe.com)全网最靠谱的原创区块链毕设代做网站
部分资料来自网络,侵权联系删除!
资源收费仅为搬运整理打赏费用,用户自愿支付 !
qklbishe.com区块链毕设代做网专注|以太坊fabric-计算机|java|毕业设计|代做平台 » Jstarfish资料

提供最优质的资源集合

立即查看 了解详情