【OutOfMemoryError】项目过程中碰到的各种OOM总结

最新推荐文章于 2025-03-18 08:45:06 发布
转载 最新推荐文章于 2025-03-18 08:45:06 发布 · 533 阅读 · 5 ·
CC 4.0 BY-SA版权
原文链接：http://blog.51cto.com/4789781/2167315
文章标签：

#java #移动开发 #数据库

OOM产生原因

常见原因有以下几种：
1.内存中加载的数据量过于庞大，如一次从数据库取出过多数据；
2.集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；
3.代码中存在死循环或循环产生过多重复的对象实体；
4.使用的第三方软件中的BUG；
5.启动参数内存值设定的过小；

对应的Log显示的错误提示如下：
1.tomcat:java.lang.OutOfMemoryError: PermGen space
2.tomcat:java.lang.OutOfMemoryError: Java heap space
3.weblogic:Root cause of ServletException java.lang.OutOfMemoryError
4.resin:java.lang.OutOfMemoryError
5.java:java.lang.OutOfMemoryError

项目一

内存溢出日志（1）

Crash日志：

Info: java.lang.Object.internalClone(Native Method)
java.lang.Object.clone(Object.java:241)
XXXXXXXXX.ARScanFragment.onNewFrame(ARScanFragment.java:259)
。。。
。。。
。。。
name: 
java.lang.OutOfMemoryError: Failed to allocate a 460812 byte allocation with 239440 free bytes and 233KB until OOM, max allowed footprint 268435456, growth limit 268435456

现象描述：
8分钟左右内存>500M导致内存溢出

图像数据byte[] data在处理过程中进行了clone（）处理。结果发现内存会不断增加直到Crash。
在分析这个日志的时候发现这个图像数据是给so层处理类似图像识别的过程的。
结合so部门同事分析发现他们并没有对内存进行过回收和释放。也就是说图像数据byte[] data一直在java层系统进行自动回收的。那么问题就很明显了，java层并没有必要clone数据给so层。
业务中并没有改变图像数据byte数组的值，因此业务也不要求clone数据
于是去掉clone（）后的现象是：
20分钟左右达到344M然后系统回收内存在260M左右。
于是预估内存波动范围260～350M
解决了当前图像数据内存使用

内存溢出日志（2）

参考博客

java.lang.OutOfMemoryError异常解决方法

转载于:https://blog.51cto.com/4789781/2167315

浅谈虚拟内存与项目开发中的OOM问题
Jerish的博客
06-13 1603
这是【游戏开发那些事】第55篇原创文章中关于Windows平台虚拟内存的部分内容转自知乎用户 “南京周润发”内存管理是操作系统中极为核心且重要的内容，也是游戏开发者极为头痛的问题之一。由于游戏在研发中需要加载大量的美术资源，频繁的创建与销毁各种对象，就很容易遇到各种内存问题，比如最常见的OOM，"Out of Memory"(OOM)。>>UE4触发OOM逻辑...
JVM（二）哪些区域可能发生OOM（OutOfMemoryError）
m0_58466443的博客
08-05 1077
同理，在一个时间点，对应的只会有一个活动的栈帧，通常叫作当前帧，方法所在的类叫作当前类。毕竟理论上的视角和现实中的视角是有区别的，规范侧重的是通用的、无差别的部分，而对于应用开发者来说，只要是 Java 进程在运行时会占用，都会影响到我们的工程实践。今天是 JVM 内存部分的第一讲，算是我们先进行了热身准备，我介绍了主要的内存区域，以及在不同版本 Hotspot JVM 内部的变化，并且分析了各区域是否可能产生 OutOfMemoryError，以及 OOME 发生的典型情况。
项目中如何防止oom
tudusi
08-15 205
项目中如何防止oom 一个简单的要求：“程序不能crash” 难，难，难，尤其是对那些设计不合理的需求，更是难上加难 待续。。。。
Java中常见OOM的场景及解决方法
iteye_9584的博客
06-20 839
OOM for Heap (java.lang.OutOfMemoryError: Java heap space) 分析 此OOM是由于JVM中heap的最大值不满足需要，将设置heap的最大值调高即可，参数样例为：-Xmx2G JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.JVM在启动的时候会自动设置Heap size的值，其初始空间(即-Xms)是...
oom技术分享，各种情况下可能会出现的oom事故
12-27
java jvm 中关于内存溢出分享，举例说明各种情况下可能会出现的oom事故
OOM问题解决实践
Aprange的博客
10-26 1万+
一、项目背景 我们的项目是一款致力于解决大学课堂教学效率低下、教师学生课堂教学互动性不强这一现实问题而设计的独立的课堂教学辅助系统。系统主体分为两个相互关联的软件。E课的pc端的用户是大学授课教师，E课APP是服务学生的Android端软件。“E课”软件PC端的用户是大学授课教师，基于授课需要，教师需要考察学生出勤情况，了解学生课堂实时学习情况，展示相关教学资料。“E课”APP的用户是学生，学生在合适的时间使用手机软件与教师进行交互，提高课堂效率与课堂互动性。 “E课”是一项独立的软件，而且全部内容自含
Java中内存异常StackOverflowError与OutOfMemoryError详解
08-31
Java中内存异常StackOverflowError与OutOfMemoryError是两种常见的错误类型，它们都是 Java 虚拟机（JVM）在运行时可能遇到的问题。本文将详细介绍这两种错误的定义、产生原因以及解决方法。 StackOverflowError ...
深入剖析 MetaSpace OOM 问题：根因分析与高效解决策略
热门推荐
张彦峰的博客
03-18 4万+
MetaSpace区是JVM内存管理中的关键部分，负责存储类元数据。随着Java 8的推出，MetaSpace取代了PermGen区，但其灵活性也带来了新的挑战，尤其是在动态类加载和频繁类更新的场景下，容易导致MetaSpace内存溢出（OOM）问题。本文探讨了MetaSpace OOM的根本原因，包括类加载器泄漏、内存管理不当和GC效率低下等，并提供了一系列调优策略和解决方案，帮助开发者有效排查和防止此类问题的发生，确保应用程序的稳定性和高可用性。
手写jvm中的各种OOM
温安适的专栏
06-28 550
撸了今年阿里、头条和美团的面试，我有一个重要发现.......>>> ...
OOM系列之一：java.lang.OutOfMemoryError: Java堆空间问题详解
slw213106的博客
12-22 4027
第一篇：java.lang.OutOfMemoryError:Java heap space Java 应用程序只允许使用有限的内存量。此限制是在应用程序启动期间指定的。为了让事情变得更复杂，Java 内存被分成两个不同的区域。这些区域称为堆空间和 Permgen（用于永久代）： 这些区域的大小是在 Java 虚拟机 (JVM) 启动期间设置的，可以通过指定 JVM 参数-Xmx和-XX:MaxPermSize进行自定义。如果您没有明确设置大小，将使用特定于平台的默认值。 该java....
项目经验分享-----有效避免OOM(Out of Memory)问题的解决方案
军军同学的专栏
08-26 1842
根据我之前项目的经验，可以考虑以下几种方法： 1. 将viewgroup中的child view 移除。  viewgroup.remove(...);  2. 每个应用的内存空间都是由android分配固定大小的内存，可以考虑将应用内存的1/4赋予LRUCache(android中的API)。 softreference 不建议使用。  当内存达到指定上限时，LRUCache有
论Java多线程如何引发OOM—多线程开发知识点
何义竏
07-08 2479
Java —ThreadLocal 如何引发 OOMJava 内存泄漏ThreadLocal_OOM回顾ThreadLocal强引用软引用弱引用虚引用 Java 内存泄漏 内存溢出(Out Of Memory）：是指应用系统中存在无法回收的内存或使用的内存过多，最终使得程序运行要用到的内存大于能提供的最大内存。此时程序就运行不了，系统会提示内存溢出，有时候会自动关闭软件，重启电脑或者软件后释放掉一部分内存又可以正常运行该软件，而由系统配置、数据流、用户代码等原因而导致的内存溢出错误，即使用户重新执行任务依然
Android 性能优化之内存泄漏检测以及内存优化（上）
Shawn_Dut的专栏
04-10 1万+
在Java中，内存的分配是由程序完成的，而内存的释放是由垃圾收集器(Garbage Collection，GC)完成的，程序员不需要通过调用函数来释放内存，但也随之带来了内存泄漏的可能
ART运行时为新创建对象分配内存的过程分析
老罗的Android之旅
01-22 1万+
ART运行时和Dalvik虚拟机一样，在堆上为对象分配内存时都要解决内存碎片和内存不足问题。内存碎片问题可以使用dlmalloc技术解决。内存不足问题则通过垃圾回收和在允许范围内增长堆大小解决。由于垃圾回收会影响程序，因此ART运行时采用力度从小到大的进垃圾回收策略。一旦力度小的垃圾回收执行过后能满足分配要求，那就不需要进行力度大的垃圾回收了。本文就详细分析ART运行时在堆上为对象分配内存的过程。
浅谈Java OOM问题的几种解决办法
zybb166的博客
12-24 2941
总篇121篇 2021年第14篇 前言 本文主要讲述了在使用MapReduce计算框架时发生Java.lang.OutOfMemory（OOM)的故障及其处理方式。通过本文可以了解到OOM问题在MapReduce框架发生的四个具体位置，以及不同位置的解决方案，给予广大读友们类似问题的解决思路。 01 介绍 正如大家所知的，Hadoop早已成为了大数据行业的事实标准。作为一个可靠，可扩展的分布式项目Hadoop的核心组成模块有YARN，HDFS和MapReduce，其中YARN是用于作业调度和集群资
项目开发中遇到OOM怎么解决
weixin_46229190的博客
10-25 625
在项目开发中遇到OOM（Out Of Memory，内存溢出）问题，通常是由于应用程序在运行时尝试使用的内存超过了可用的内存限制。
内存溢出和内存泄漏的区别、产生原因以及解决方案
weixin_34270606的博客
03-16 303
内存溢出 out of memory，是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；比如申请了一个integer,但给它存了long才能存下的数，那就是内存溢出。 内存泄露 memory leak，是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。 memory leak会最终...
模拟实战排查堆内存溢出问题 OOM Error : Java heap space
木子雷的博客
05-15 1173
前言： 模拟实战中排查堆内存溢出（java.lang.OutOfMemoryError: Java heap space）的问题。 堆内存溢出的原因：一般都是创建了大量的对象，这些对象一直被引用着，无法被GC垃圾回收掉，最终导致堆内存被占满，没有足够的空间存放新创建的对象时，就会出现堆内存溢出问题。 在实际的业务场景中出现内存溢出的问题，排查起来一般是十分困难繁琐的，本文将通过结合一个简单的实例来阐述排查的具体思路和步骤。 准备： 注意：在实际场景中，一般都是部署在Linux服务器中的项目报出内存溢出
内存溢出的解决思路
aodaidi6752的博客
09-10 2715
内存溢出是指应用系统中存在无法回收的内存或使用的内存过多，最终使得程序运行要用到的内存大于虚拟机能提供的最大内存。 引起内存溢出的原因有很多种，常见的有以下几种：　　1.内存中加载的数据量过于庞大，如一次从数据库取出过多数据；　　2.集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；　　3.代码中存在死循环或循环产生过多重复的对象实体；　　4.使用的第三方软件中的BUG...
java项目里的OOM怎么解决
最新发布
06-04
<think>嗯，用户现在遇到了Java项目中的OutOfMemoryError问题，需要解决方案。之前用户提供了FutureExample的代码示例，但那个是关于多线程和Future的，与内存溢出关系不大，可能是用户复制错了参考内容。用户的核心诉求很明确：解决生产环境中的OOM问题。用户可能正在面临线上服务崩溃的紧急情况，情绪比较焦虑。虽然ta只简单描述了问题，但这类问题通常需要系统性排查。考虑到OOM的复杂性，我决定从六个维度展开：现象确认、原因分析、诊断工具、解决方案、预防措施和实例演示。注意到用户提到的是"Javaproject"，猜测可能是Web应用或后端服务。内存问题最棘手的是定位根源，所以重点要教用户如何获取诊断证据（特别是堆转储分析）。用户能提供FutureExample代码，说明有一定技术基础，可以接受专业工具的使用指导。在方案设计上，需要覆盖最常见的原因：内存泄漏（如未释放集合引用）、资源未关闭（如数据库连接池）、数据量激增（如大文件加载）。对于每种情况都要给出可操作的检查清单，比如用jstat看GC状态，用MAT分析dominant_tree。特意加入"伪OOM"的说明很重要——很多用户会把NativeMemory耗尽误认为HeapOOM。准备用visualvm的截图示例让诊断更直观，最后用线程栈泄漏的案例演示完整分析流程，这样用户能按模板操作。需要提醒用户注意工具使用的安全细节：比如在生产环境获取堆转储会造成服务暂停，必须评估影响。故障复现部分建议用户优先在预发环境测试dump操作，避免线上风险。</think> 针对Java项目的`OutOfMemoryError`问题，以下是系统级的解决方案和分析步骤： --- ### 一、问题本质分析 `OutOfMemoryError`表示**JVM堆内存耗尽**（多数情况）或**非堆内存不足**（如元空间）。根本原因为： - 内存泄漏（对象无法被GC回收） - 内存配置不足（如-Xmx设置过小） - 大对象/大文件处理不当 - 并发请求量突增 --- ### 二、诊断工具与步骤 #### 1. 确认错误类型 - **Heap OOM**：`java.lang.OutOfMemoryError: Java heap space` - **非堆OOM**：`java.lang.OutOfMemoryError: Metaspace` 或 `Direct buffer memory` #### 2. 实时监控工具 ```bash # 监控堆内存与GC jstat -gc <pid> 1000 # 每秒输出GC状态 # 查看堆中对象分布 jmap -histo <pid> | head -20 # 统计对象数量前20 ``` #### 3. 获取堆转储（关键步骤） ```bash jmap -dump:format=b,file=heapdump.hprof <pid> ``` 用 **Eclipse Memory Analyzer (MAT)** 分析 `heapdump.hprof`，定位内存占用最高的对象（Dominator Tree）。 --- ### 三、通用解决方案 #### ✅ 内存泄漏修复 | 常见泄漏场景 | 修复方案 | |--------------|----------| | **静态集合** | 用`WeakHashMap`代替`HashMap`，定期清理无用数据 | | **未关闭资源** | 在`finally`中关闭`InputStream`、数据库连接等 | | **线程局部变量** | 及时调用`ThreadLocal.remove()` | | **监听器未注销** | 在对象销毁时反注册事件监听 | #### ✅ 内存配置优化 ```bash # 调整堆大小（示例） java -Xms512m -Xmx2048m -XX:MaxMetaspaceSize=256m -jar app.jar # 针对G1垃圾回收器优化 -XX:+UseG1GC -XX:MaxGCPauseMillis=200 ``` #### ✅ 代码优化 - 避免在循环内创建大对象（如 `new byte[1024*1024]`) - 用`try-with-resources`自动管理资源 - 分页处理大文件/大数据集 - 缓存使用`SoftReference`或`WeakReference` --- ### 四、特殊场景处理 #### 1. **Metaspace OOM** ```bash # 增大元空间 -XX:MaxMetaspaceSize=512m # 记录类加载信息 -XX:+TraceClassLoading -XX:+TraceClassUnloading ``` 检查是否有重复加载类（如OSGi/热部署问题） #### 2. **堆外内存溢出** ```bash # 调整直接内存 -XX:MaxDirectMemorySize=256m ``` 排查：Netty、NIO等框架中未释放的`ByteBuffer` --- ### 五、预防措施 1. **压力测试**：用JMeter模拟高并发，观察内存变化 2. **监控告警**：集成Prometheus + Grafana监控： - JVM堆使用率 - GC频率与耗时 - 线程数峰值 3. **代码规范**：使用`@Slf4j`记录大对象创建日志 --- ### 六、故障复现示例 ```java // 模拟内存泄漏（静态Map持续增长） public class MemoryLeak { static Map<Object, Object> staticMap = new HashMap<>(); public static void main(String[] args) { while (true) { staticMap.put(new Object(), new byte[1024 * 1024]); // 每秒泄漏1MB Thread.sleep(1000); } } } ``` 运行参数：`java -Xms10m -Xmx20m MemoryLeak` 👉 分析堆转储可清晰定位`staticMap`的引用链。 --- > **关键提示**：80%的OOM可通过**堆转储分析**准确定位，避免盲目调大内存掩盖问题本质 [^1]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值