您好!
欢迎来到京东云开发者社区
登录
首页
博文
课程
大赛
工具
用户中心
开源
首页
博文
课程
大赛
工具
开源
更多
用户中心
开发者社区
>
博文
>
完蛋!我被 Out of Memory 包围了!
分享
打开微信扫码分享
点击前往QQ分享
点击前往微博分享
点击复制链接
完蛋!我被 Out of Memory 包围了!
ji****
2023-11-06
IP归属:北京
18320浏览
推荐
<p>> 先点赞再看,养成好习惯 * 是极致魅惑、洒脱自由的 `Java heap space`? * 是知性柔情、温婉大气的 `GC overhead limit exceeded`? * 是纯真无邪、活泼可爱的 `Metaspace`? * 如果以上不是你的菜,那还有…… * 刁蛮任性,无迹可寻的 `CodeCache`! * 性感火辣、心思细腻的 `Direct Memory` * 高贵冷艳,独爱你一人的 `OOM Killer`! * 总有一款,能让你钟情!BUG 选择权,现在交由你手! ![image.png](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-11-02-10-57XocqTnPFlxTzDLX.png) ## Java heap space 这是最常见的一个 OOM 问题了,谁还没经历过一个 Heap OOM呢? 当堆内存被塞满之后,一边 GC 无法及时回收,一边又在继续创建新对象,Allocator 无法分配新的内存之后,就会送一个 OOM 的错误: ```log java.lang.OutOfMemoryError: Java heap space ``` 分析解决起来无非是那几步: 1. dump 堆内存 2. 通过 MAT、YourKit、JProfiler 、IDEA Profiler 等一系列工具分析dump文件 3. 找到占用内存最多、最大的对象,看看是哪个小可爱干的 4. 分析代码,尝试优化代码、减少对象创建 5. 增加 JVM 堆内存、限制请求数、线程数、增加节点数量等 ### 常见类库使用误区 尤其是一些工具库,尽可能的避免每次新建对象,从而节省内存提升性能。 大多数主流的类库,入口类都保证了单例线程安全,全局维护一份即可 举一些常见的错误使用例子: #### Apache HttpClient CloseableHttpClient ,这玩意相当于一个“浏览器进程”了,背后有连接池连接复用,一堆机制的辅助类,如果每次都 new 一个,不仅速度慢,而且浪费了大量资源。 比较正常的做法是,全局维护一个(或者根据业务场景分组,每组一个)实例,服务启动时创建,服务关闭时销毁: ```java CloseableHttpClient httpClient = HttpClients.custom() .setMaxConnPerRoute(maxConnPerRoute) .setMaxConnTotal(maxConnTotal) /// ... .build(); ``` #### Gson 毕竟是 Google 的项目,入口类自然也是实现了线程安全,全局维护一份 Gson 实例即可 #### Jackson Jackson 作为 Spring MVC 默认的 JSON 处理库,功能强大、用户众多,xml/json/yaml/properties/csv 各种主流格式都支持,单例线程安全自然也是 ok 的,全局维护一份 ObjectMapper 即可。 ## GC overhead limit exceeded 这个错误比较有意思,上面的 Java heap space 是内存彻底满了之后,还在持续的创建新对象,此时服务会彻底假死,无法处理新的请求。 而这个错误,只是表示 GC 开销过大,Collector 花了大量的时间回收内存,但释放的堆内存却很小,并不代表服务死了 此时程序处于一种很微妙的状态:堆内存满了(或者达到回收阈值),不停的触发 GC 回收,但大多数对象都是可达的无法回收,同时 Mutator 还在低频率的创建新对象。 出现这个错误,一般都是流量较低的场景,有太多常驻的可达对象无法回收,但是吧,GC 后空闲的内存还可以满足服务的基本使用 不过此时,已经在频繁的老年代GC了,老年代又大对象又多、在现有的回收算法下,GC 效率非常低并切资源占用巨大,甚至会出现把 CPU 打满的情况。 出现这个错误的时候,从监控角度看起来可能是这个样子: 1. 请求量可能并不大 2. 不停 GC,并切暂停时间很长 3. 时不时的还有新的请求,但响应时间很高 4. CPU 利用率很高 毕竟还是堆内存的问题,排查思路和上面的 `Java heap space` 没什么区别。 ## Metaspace/PermGen Metaspace 区域里,最主要的就是 Class 的元数据了,ClassLoader 加在的数据,都会存储在这里。 MetaSpace 初始值很小,默认是没有上限的。当利用率超过40%(默认值 MinMetaspaceFreeRatio)会进行扩容,每次扩容一点点,扩容也不会直接 FullGC。 比较推荐的做法,是不给初始值,但限制最大值: ``` -XX:MaxMetaspaceSize=</p><size>``` 不过还是得小心,这玩意满了后果很严重,轻则 Full GC,重则 OOM: ``` java.lang.OutOfMemoryError: Metaspace ``` 排查 MetaSpace 的问题,主要思路还是追踪 Class Load数据,比较主流的做法是: 1. 通过 Arthas 之类的工具,查看 ClassLoader、loadClassess 的数据,分析数量较多的 ClassLoader 或者 Class 2. 打印每个 class 的加载日志:`-XX:+TraceClassLoading -XX:+TraceClassUnloading` 下面介绍几个常见的,可能导致 MetaSpace 增长的场景: ### 反射使用不当 JAVA 里的反射,性能是非常低的,以反射的对象必须得缓存起来。尤其是这个`Method`对象,如果在并发的场景下,每次都获取新的 Method,然后 invoke 的话,用不了多久 MetaSpace 就给你打爆! 简单的说,并发场景下,Method.invoke 会重复的动态创建 class,从而导致 MetaSpace 区域增长,具体分析可以参考笨神的文章《[从一起GC血案谈到反射原理](https://heapdump.cn/article/54786)》。 用反射时,尽可能的用成熟的工具类,Spring的、Apache的都可以。它们都内置了reflection相关对象的缓存,功能又全性能又好,足以解决日常的使用需求。 ### 一些 Agent 的 bug 一些 Java Agent,静态的和运行时注入的都算。基于 Instrumentation 这套 API 做了各种增强,一会 load 一会 redefine 一会remove的,如果不小心出现 BUG,也很容易生成大量动态的 class,从而导致 metaspace 打满。 ### 动态代理问题 像 Spring 的 AOP ,也是基于动态代理实现的,不管是 CgLib 还是 JDK Proxy,不管是 ASM 还是 ByteBuddy。最终的结果都逃不开动态创建、加载 Class,有这两个操作,那 Metaspace 必定受影响。 Spring 的 Bean 默认是 `singleton` 的,如果配置为 `prototype`,那么每次 getBean 就会创建新的代理对象,重新生成动态的 class、重新 define,MetaSpace 自然越来越大。 ## Code Cache Code Cache 区域,存储的是 JIT 编译后的热点代码缓存(注意,编译过程中使用的内存不属于 Code cache),也属于 non heap 。 如果 Code cache 满了,你可能会看到这么一条日志: ``` Server VM warning: CodeCache is full. Compiler has been disabled. ``` 此时 JVM 会禁用 JIT 编译,你的服务也会开始变慢。 Code Cache 的上限默认比较低,一般是240MB/128MB,不同平台可能有所区别。 可以通过参数来调整 Code Cache 的上限: ``` -XX:ReservedCodeCacheSize=<size>``` 只要尽量避免过大的Class、Method ,一般也不太会出现这个区域被打满的问题,默认的 240MB/128MB 也足够了 ## Direct Memory Direct Memory 区域,一般称之为直接内存,很多涉及到 磁盘I/O ,Socket I/O 的场景,为了“Zero Copy”提升性能都会使用 Direct Memory。 就比如 Netty ,它真的是把 Direct Memory 玩出了花(有空写一篇 Netty 内存管理分析)…… 使用 Direct Memory时,相当于直接绕过 JVM 内存管理,调用 malloc() 函数,体验手动管理内存的乐趣~ 不过吧,这玩意使用比较危险,一般都配合 Unsafe 操作,一个不小心地址读写的地址错误,就能得到一个 JVM 给你的惊喜: ``` # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffdbd5d19b4, pid=1208, tid=0x0000000000002ee0 # # JRE version: Java(TM) SE Runtime Environment (8.0_301-b09) (build 1.8.0_301-b09) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.301-b09 mixed mode windows-amd64 compressed oops) # Problematic frame: # C [msvcr100.dll+0x119b4] # # No core dump will be written. Minidumps are not enabled by default on client versions of Windows # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # ``` ![image.png](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-11-02-10-369sm6Shj7lkLZQao.png) 更多的解释,可以参考我这篇《[Java中的Heap Buffer与Direct Buffer](https://segmentfault.com/a/1190000020228048)》 这个 Direct Memory 区域,默认是无上限的,但为了防止被 OS Kill,还是会限制一下,给个256MB或者更小的值,防止内存无限增长: ``` -XX:MaxDirectMemorySize=<size>``` 如果 Direct Memory 达到 MaxDirectMemorySize 并且无法释放时,就会得到一个 OOM错误: ``` java.lang.OutOfMemoryError: Direct buffer memory ``` ## Linux OOM Killer 跳出 JVM 内存管理之后,当 OS 内存耗尽时,Linux 会选择内存占用最多,优先级最低或者最不重要的进程杀死。 一般在容器里,主要的进程就是肯定是我们的 JVM ,一旦内存满,第一个杀的就是它,而且还是 kill -TERM (-9)信号,打你一个猝不及防。 如果 JVM 内存参数配置合理,远低于容器内存限制,还是出现了 OOM Killer 的话,那么恭喜你,大概率是有什么 Native 内存泄漏。 这部分内存,JVM 它还管不了。 除了 JVM 内部的 Native 泄漏 BUG 这种小概率事件外,大概率是你引用的第三方库导致的。 这类问题排查起来非常麻烦,毕竟在 JVM 之外,只能靠一些原生的工具去分析。 而且吧,这种动不动就要 root 权限的工具,可是得领导审批申请权限的……排查成本真的很高 ![image.png](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-11-02-10-39aqlx39acVlRQ29Qrm.png) 排查 Native 内存的基本的思路是: 1. pmap 查看内存地址映射,定位可疑内存块、分析内存块数据 2. strace 手动追踪进程系统调用,分析内存分配的系统调用链路 3. 更换jemalloc/tcmalloc之类的内存分配器(或者 async-profiler有个支持native 分析的分支)追踪malloc的调用链路 目前最常见的 Native 内存泄漏场景,是 JDK 的 Inflater/Deflater 这俩卧龙凤雏,功能是提供 GZIP 的压缩、解压,在默认 glibc 的 malloc 实现下,很容易出现“内存泄漏”。如果出现 Native 内存泄漏,可以先看看应用里有没有 GZIP 相关操作,说不定有惊喜。 --- 好了,各类风格的 OOM 都感受完了,到底哪一个更能打动你呢?</size></size></size>
上一篇:从混乱到优雅:基于DDD的六边形架构的代码翻新指南
下一篇:前端性能优化实践
相关文章
京东金融APP的鸿蒙之旅:技术、挑战与实践
京东云JoyCoder荣获AI4SE“银弹”优秀案例
从原理聊JVM(四):JVM中的方法调用原理
ji****
文章数
7
阅读量
1656
作者其他文章
01
GPTs 初体验 - 1 分钟就能创建一个自己的 ChatGPT?
点赞再看,养成习惯就在 11.10 号早上,ChatGPT 已经偷摸的把 GPTs 功能,开放给所有尊贵的 Plus 用户了。随着这波的功能开放,界面也是改了不少。点击左侧的 Explore 或者左下角的用户处,就可以直接进入新的 GPTs 功能:这里可以看到我们自己创建的 GPT,下面呢还有 OpenAI 官方出品的 GPTs :不过这些官方的,目前看起来更像是一个个的提示词包,貌似没啥惊艳的,
01
完蛋!我被 Out of Memory 包围了!
先点赞再看,养成好习惯是极致魅惑、洒脱自由的 Java heap space?是知性柔情、温婉大气的 GC overhead limit exceeded?是纯真无邪、活泼可爱的 Metaspace?如果以上不是你的菜,那还有……刁蛮任性,无迹可寻的 CodeCache!性感火辣、心思细腻的 Direct Memory高贵冷艳,独爱你一人的 OOM Killer!总有一款,能让你钟情!BUG 选择
01
从头到尾说一次 Spring 事务管理(器)
先点赞再看,养成好习惯事务管理,一个被说烂的也被看烂的话题,还是八股文中的基础股之一。本文会从设计角度,一步步的剖析 Spring 事务管理的设计思路(都会设计事务管理器了,还能玩不转?)为什么需要事务管理?先看看如果没有事务管理器的话,如果想让多个操作(方法/类)处在一个事务里应该怎么做:// MethodA:public void methodA(){ Connection connecti
01
别再纠结线程池池大小、线程数量了,哪有什么固定公式
可能很多人都看到过一个线程数设置的理论:CPU 密集型的程序 - 核心数 + 1I/O 密集型的程序 - 核心数 * 2不会吧,不会吧,真的有人按照这个理论规划线程数?线程数和CPU利用率的小测试抛开一些操作系统,计算机原理不谈,说一个基本的理论(不用纠结是否严谨,只为好理解):一个CPU核心,单位时间内只能执行一个线程的指令那么理论上,我一个线程只需要不停的执行指令,就可以跑满一个核心的利用率。
ji****
文章数
7
阅读量
1656
作者其他文章
01
GPTs 初体验 - 1 分钟就能创建一个自己的 ChatGPT?
01
从头到尾说一次 Spring 事务管理(器)
01
别再纠结线程池池大小、线程数量了,哪有什么固定公式
添加企业微信
获取1V1专业服务
扫码关注
京东云开发者公众号