马上: Android线上OOM问题定位解决分享及总结

最新推荐文章于 2024-03-29 14:43:07 发布
置顶 最新推荐文章于 2024-03-29 14:43:07 发布
阅读量1.6w 收藏 11
点赞数
分类专栏： Android 工具 马上 文章标签： android java apache
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/csdnno/article/details/121961814
版权
Android 同时被 3 个专栏收录
71 篇文章 0 订阅
订阅专栏
马上
13 篇文章 0 订阅
订阅专栏
工具
5 篇文章 0 订阅
订阅专栏

目录

项目背景

1、由于马上智能终端App要为用户提供了24小时不间断的服务特性，App对于应用稳定性的要求非常高，体现App稳定性的一个重要数据就是Crash率，而在众多Crash中最棘手最头疼最难定位的就是OOM问题。
2、对于智能终端设备来说, 在长时间的使用过程中，App中所有的内存泄漏都会慢慢累积在内存中，最后就容易导致OOM，进而影响整个自助服务。
3、OOM是软件领域的经典问题，它藏得很深，没太多征兆，但爆发问题，问题来源的多样、不易重现、现场信息少、难以定位等困难

线上现状

腾讯Bugly，为移动开发者提供专业的异常上报和运营统计，帮助开发者快速发现并解决异常，同时掌握产品运营动态，及时跟进用户反馈。

采用 腾讯bugly 分析现状，发现OOM发生机率之高
在这里插入图片描述

OOM原因分析

要定位OOM问题，首先需要弄明白Android中有哪些原因会导致OOM，Android中导致OOM的原因主要可以划分为以下几个类型：

在这里插入图片描述
结合现状buggly堆栈报错信息

  • pthread_create (1040KB stack) failed: Try again
  • Could not allocate JNI Env
  • allocate a 7687692 byte allocation with 2774696 free bytes and 2MB until OOM
  • OutOfMemoryError thrown while trying to throw OutOfMemoryError; no
    stack available
  • Cursor window allocation of 2048 kb failed.

关键堆栈不一一贴出了.

上面几种报错信息，简单分析一下

  1. 创建线程失败，栈内存不足（进程的虚拟内存不足）或超线程数，
  2. 创建线程失败，超FD（文件描述符）或mmap创建匿名共享内存时（也是进程的虚拟内存不足）
  3. 创建资源时，堆内存分配失败
  4. 创建资源时，被try Throwable，堆内存分配失败,导致stack 溢出
  5. 游标创建失败，堆内存分配失败

再归档一下项目中OOM情况：
1、可能线程泄露，线程数超出限制
2、可能文件资源泄露，FD数超出限制
3、对象泄露，java堆内存不足

OOM问题定位

分析线上问题内存泄露,排查的一个难点：如何定位，复原案发现场

  • 分析buggly
  • 查看发生崩溃的时间，崩溃时设备的情况，一般会记录闪退日志和重要日志记录
  • 查看使用使用时长，业务场景下操作复现

1、buggly先简单定位到用户ID，用户使用时长，可用系统内存，发生时间。可以先根据堆栈信息来确定这是哪一个类型的OOM，再进行日志回捞和业务场景复现
在这里插入图片描述
2、日志回捞分析 （需要平台支持下的一套日积月累成熟方案）

项目中我加入了CPU，内存，FD，NetworkInfo，ThreadsInfo等关键模块监控，关键日志信息埋点

CpuInfo: User 6%, System 6%, IOW 0%, IRQ 1%
MemoryInfo: 1.95G,1.35G,144.00M,false; JavaHeapInfo: 38/712mb,ratio:0.05%
FdInfo: fd size: 172
StatusInfo: Threads:	120	voluntary_ctxt_switches:	1029455	nonvoluntary_ctxt_switches:	56904
NetworkInfo: type: Ethernet[9], subtype: [0], 8e:a2:0c:64:58:52, 10.0.6.144

充分了解项目基本情况，比如该项目中fd 数量200+，和线程数200+，堆内存占比30%是合理的。下面是个真实例子

回捞的日志信息，发生时间为12-18 13:38
12-18 13:38:24.747: : E/14491/MGException: Id=NHG47K&Display=v1.0.5&Product=rk3288&Device=rk3288&Board=rk30sdk&CpuAbi=armeabi-v7a&CpuAbi2=armeabi&Manufacturer=Haitianxiong&Brand=Haitianxiong&Model=VX-3288K&Hardware=rk30board&Serial=VCPIDLDV6Z&Type=userdebug&Tags=test-keys&FingerPrint=Haitianxiong/rk3288/rk3288:7.1.2/NHG47K:userdebug/test-keys&Version.Incremental=eng.root.20200713.104251&Version.Release=7.1.2&SDK=25&SDKInt=25&Version.CodeName=REL&Density=0.75;Width=800;Height=444;ScaledDensity=0.75;xdpi=213.0;ydpi=213.0;DensityDpi=120&Ver=6.9.6_211108
	at java.lang.Thread.nativeCreate(Native Method)
	at java.lang.Thread.start(Thread.java:730)
	at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:941)
	at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1009)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1151)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
	at java.lang.Thread.run(Thread.java:761)
12-18 13:38:24.749: : D/14491/DefaultUncaughtExceptionHandler: appCrashTimesStr:1639780371570,1639786813250,1639793211423,1639799591147,1639799591744
12-18 13:38:24.749: : D/14491/DefaultUncaughtExceptionHandler: crashCount:0
12-18 13:38:24.750: : D/14491/DefaultUncaughtExceptionHandler: appCrash : 借助其它app 启动

上面创建线程失败，分析Threads信息基本模块日志，13:38 期间线程数达限制导致失败，原因是不断创建线程，线程泄露

12-18 11:53:19.068: : D/14491/StatusInfo: Threads:	108	voluntary_ctxt_switches:	764	nonvoluntary_ctxt_switches:	285
12-18 12:03:19.526: : D/14491/StatusInfo: Threads:	177	voluntary_ctxt_switches:	72915	nonvoluntary_ctxt_switches:	6952
12-18 12:13:19.943: : D/14491/StatusInfo: Threads:	239	voluntary_ctxt_switches:	125722	nonvoluntary_ctxt_switches:	10480
12-18 12:23:20.337: : D/14491/StatusInfo: Threads:	296	voluntary_ctxt_switches:	201087	nonvoluntary_ctxt_switches:	16183
12-18 12:33:20.726: : D/14491/StatusInfo: Threads:	352	voluntary_ctxt_switches:	253078	nonvoluntary_ctxt_switches:	19911
12-18 12:43:21.141: : D/14491/StatusInfo: Threads:	405	voluntary_ctxt_switches:	315668	nonvoluntary_ctxt_switches:	25419
12-18 12:53:21.582: : D/14491/StatusInfo: Threads:	460	voluntary_ctxt_switches:	375660	nonvoluntary_ctxt_switches:	29996
12-18 13:03:22.056: : D/14491/StatusInfo: Threads:	517	voluntary_ctxt_switches:	428586	nonvoluntary_ctxt_switches:	34298
12-18 13:13:22.508: : D/14491/StatusInfo: Threads:	573	voluntary_ctxt_switches:	466703	nonvoluntary_ctxt_switches:	36509
12-18 13:23:22.937: : D/14491/StatusInfo: Threads:	628	voluntary_ctxt_switches:	504824	nonvoluntary_ctxt_switches:	38960
12-18 13:33:23.394: : D/14491/StatusInfo: Threads:	682	voluntary_ctxt_switches:	542957	nonvoluntary_ctxt_switches:	41872
12-18 13:38:32.157: : D/24733/StatusInfo: Threads:	105	voluntary_ctxt_switches:	705	nonvoluntary_ctxt_switches:	263
12-18 13:48:32.736: : D/24733/StatusInfo: Threads:	180	voluntary_ctxt_switches:	113782	nonvoluntary_ctxt_switches:	14680

再看看内存使用情况
12-18 13:03:22.048: : D/14491/MemoryInfo: 1.95G,1.33G,144.00M,false
12-18 13:13:22.505: : D/14491/MemoryInfo: 1.95G,1.33G,144.00M,false
12-18 13:23:22.933: : D/14491/MemoryInfo: 1.95G,1.33G,144.00M,false
12-18 13:33:23.391: : D/14491/MemoryInfo: 1.95G,1.32G,144.00M,false
12-18 13:38:30.627: : I/24817push/MemoryInfo: ESS=mounted;ESD=/storage/emulated/0;ESSC=mounted;EXIST=true,true,false,false,true,false,false&IMA=2.48G;IMT=3.91G;EMA=2.48G;EMT=3.91G&AM.MEM=1.52G,1.95G,144.00M,false
12-18 13:38:32.155: : D/24733/MemoryInfo: 1.95G,1.50G,144.00M,false
12-18 13:48:32.732: : D/24733/MemoryInfo: 1.95G,1.34G,144.00M,false

结论是这个OOM，是线程使用不合理，根据业务日志和结合代码分析出，是接入的sdk循环初始化导致OOM

Fd泄露，类似线程泄露，找出项目代码哪里没有释放fd

12-16 07:10:23.143: : D/1308/FdInfo: fd size: 193
12-16 07:20:23.591: : D/1308/FdInfo: fd size: 183

对象泄露导致堆内存不足, 需要根据项目分析出现的场景操作复现。

MemoryInfo:  1.95G,739.30M,144.00M,false; JavaHeapInfo: 500/512mb,ratio:97%

OOM问题分析

OOM问题定位到原因，但是要结合项目具体分析修复

前面OOM问题定位，已通过回捞日志分析并模拟发生场景，接下来通过官方分析应用性能工具之android-studio profile ，生成Java内存快照文件（即HPROF文件）。

android-studio bin目录下，可以单独允许运行

也可以打开as,profiler视图
在这里插入图片描述

查看Show activity/fragment leaks，这功能直接分析 activity/fragment 泄露地方，
在这里插入图片描述
然后结合业务，这是智慧屏的一个Metro风格展示，上面泄露的是轮播的磁贴Fragment
在这里插入图片描述

Banner业务实体类代码分析，居然引用了fragment, 万一哪里没有setFragment(null),或者持有Banner，Fragment对象就泄露了
在这里插入图片描述
可是项目复杂想·业务代码几千行，知道Fragment 被mBanners 持有着，一时间也无从下手，可以先用WeakReference 引用尝试定位，发现确实是这个Banner引起。

setFragment业务代码埋点日志, 并输出调用栈，新预览版as,能查看调用栈，方便挺多的

Log.i("aaa", "setFragment: " + fragment + " ;" + Utility.getStackTraceElement(4));

结果日志埋点后发现了：轮播主页Fragment的Banners初始化有以下问题:
1、mBanners clear时是没有把Banner里的Fragment对象清除.
2、无用的Banner的Fragment没有清除

private ArrayList<Banner> mBanners;

// 刷新ViewPager leak代码
if (mBanners != null && !mBanners.isEmpty()) {
    mBanners.clear();
}

// 刷新ViewPager 修复leak代码
if (mBanners != null && !mBanners.isEmpty()) {
    for (Banner banner : mBanners) {
        if (banner == null) {
            continue;
        }
        banner.setFragment(null);
    }
    mBanners.clear();
}

//外部磁贴最多只能轮播5帧 leak代码
ArrayList<Banner> subList = new ArrayList<>(5);
subList.addAll(tmpBanners.subList(0, 5));
pagesBanner.setPages(subList);

boolean removeAll = tmpBanners.removeAll(subList); //添加修复leak代码
if (removeAll && tmpBanners != null) {
    Iterator<Banner> it = tmpBanners.iterator();
    while (it.hasNext()) {
        Banner banner = it.next();
        if (banner.getView() != null) {
            continue;
        }
        Fragment next = banner.getFragment();
        if (next != null && !next.isAdded()) {
            Banner banner1 = banner;
            if (banner1 != null) {
                banner1.setFragment(null);
            }
        }
    }
}

一般情况下通过,profiler来分析堆内存, 能定位项目中的Activity，Fragment泄露原因.
如界面销毁时Handler 没有及时移除消息。不合理使用Fragment, replace fragment 没有用tag和remove 等。

在项目解决了:

  1. Activity/Fragment 的泄露问题
  2. rxjava CompositeDisposable 泄露，clear 并不等同dispose , add(Disposable) 函数，DisposeTask执行完成，必须及时移出 remove（Disposable）
  3. 没有及时反注册引起的资源泄露，用WeakHashMap 效果很好
  4. 旧业务采用volley，NetworkDispatcher.run() ,请求队列轮询一直持有request，升级为okhttp 解决或者升级最新sdk
  5. 下载器Cancelable 对象泄露，Map<String, Cancelable> mCancelDownloading 没有及时移出导致
  6. ijk播放器在轮播页不断创建泄露，native fd 泄露
  7. Toast 泄露
  8. …不一一列举

以上上面只是通过日志分析场景，通过复现现场，抓取内存快照来分析解决。此方式耗费时间成本，为此项目中监控了堆内存、FD、Thread使用指标，达到这指标并且是关注设备通过Debug.dumpHprofData(String fileName)，获取快照文件，裁剪回捞HPROF文件等工作，虽然成功率不高，也能节约大量时间分析现场

使用MAT分析复杂的OOM情况

Android studio 分析内存堆的profiler 工具，简单便利。但是缺少比对，查对象引用等功能，而MAT提供了非常多的功能。
Memory Analyzer Tool 是一个分析 Java堆数据的专业工具，可以计算出内存中对象的实例数量、占用空间大小、引用关系等，看看是谁阻止了垃圾收集器的回收工作，从而定位内存泄漏的原因。

使用MAT之前，需要认识：

  • Java内存分配策略 ,静态存储区（方法区）+栈区+ 堆区
  • Java管理内存的机制，GC机制 （有向图）
  • Java内存泄漏，对象对象是可达的，即在有向图中，存在通路可以与其相连且以后不会再使用这些对象
  • Android sdk hprof-conv, 把安卓hprof文件转换为标准的java hprof文件

关键词概念

  • Dominator：从GC Roots到达某一个对象时，必须经过的对象，称为该对象的Dominator。
  • ShallowSize：对象自身占用的内存大小，不包括它引用的对象。
  • RetainSize：对象自身的ShallowSize和对象所支配的（可直接或间接引用到的）对象的ShallowSize总和，就是该对象GC之后能回收的内存总和。
Histogram：直方图，可以列出内存中每个对象的名字、数量以及大小。

Dominator Tree：会将所有内存中的对象按大小进行排序，并且我们可以分析对象之间的引用结构。

Group分组功能，工具栏的 Group result by...

List objects：想要看某个条目（对象/类）的引用关系图，可以使用 List objects 功能
List objects -> with outgoing references ：表示该对象的出节点（被该对象引用的对象）
List objects -> with incoming references：表示该对象的入节点（引用到该对象的对象）

分析引用链路径：
Paths to GC Roots：从当前对象到GC roots的路径，这个路径解释了为什么当前对象还能存活，对分析内存泄露很有帮助，这个查询只能针对单个对象使用
Merge Shortest Paths to GC roots：从GC roots到一个或一组对象的公共路径

排除泄露选-> exclude all phantom/weak/soft etc. references，因为GC无法回收的强引用对象


Add Compare Basket 或者Compare to another heap dump：两个文件对比

总结

  1. 解决问题，必须要有扎实学识。如OOM，需要掌握Java内存分配，回收；Linux的FD文件描述符；线程底层创建原理
  2. 工欲善其事，必先利其器。线上监控，日志回捞方案，掌握profiler,mat工具使用等必不可少。
  3. 多分析相关的代码，找出相应的问题关键，再来考虑具体的优化策略。
  4. 优化完代码，要不断自测，保持一颗敬畏的心。
ExtraLazy
关注
  • 0
    点赞
  • 踩
  • 11
    收藏
    觉得还不错? 一键收藏
  • 3
    评论
专栏目录
Android编程之内存溢出解决方案（OOM）实例总结
09-03
主要介绍了Android编程之内存溢出解决方案（OOM）,结合实例实例总结分析了Android编程过程中常见的内存溢出情况与对应的解决方法,具有一定参考借鉴价值,需要的朋友可以参考下
解决Android解析图片的OOM问题的方法!!!
09-01
我们在编写Android程序的时候经常要用到许多图片，不同图片总是会有不同的形状、不同的大小，程序占用了过高的内存就容易出现OOM(OutOfMemory)异常。本篇文章主要讲诉了解决Android解析图片的OOM问题，有兴趣的可以了解一下。
Probe：Android线上OOM问题定位组件，阿里三面
最新发布
2401_83946509的博客
03-29 972
首先是感觉自己的基础还是不够吧，大厂好像都喜欢问这些底层原理。之前的准备只涉及了Java、Android、计网、数据结构与算法这些方面，面对面试官对其他基础课程的考察显得捉襟见肘。下一步还是要查漏补缺，进行针对性复习。最后的最后，那套资料这次一定要全部看完，是真的太全面了，各个知识点都涵盖了，几乎我面试遇到的所有问题的知识点这里面都有！希望大家不要犯和我一样的错误呀！！！一定要看完！后的最后，那套资料这次一定要全部看完，是真的太全面了，各个知识点都涵盖了，几乎我面试遇到的所有问题的知识点这里面都有！
浅谈Android OOM及定位分析
苦逼的程序猿☺
09-22 2085
要定位OOM问题，首先需要弄明白Android中有哪些原因会导致OOM，Android中导致OOM的原因主要可以划分为以下几个类型：Android 虚拟机最终抛出OutOfMemoryError的代码位于/art/runtime/thread.cc。下面两个地方都会调用上面方法抛出OutOfMemoryError错误，这也是Android中发生OOM的主要原因。
Android内存溢出分析
幸福过饱和的专栏
11-29 193
内存溢出，是Android开发中常遇到的问题，解决起来总是摸不着头脑。今天爬爬就来讲讲如何定位内存溢出。   OOM（内存溢出）和Memory Leak（内存泄露）有什么关系？ OOM可能是因为Memory Leak，也可能是你的应用本身就比较耗内存（比如图片浏览型的，或者应用本身的设计有问题）。所以，出现OOM不一定是Memory Leak。 同样，Memory Le...
Android 内存溢出（OOM）问题分析方法
a854702872的博客
08-10 796
oom的原因？ 1）对象设计不合理（单个对象的内存占用过大、同类对象未重复利用）； 2）一次性申请很大内存导致超出了系统对单个应用设定的内存上限（Dalvik Heap Size）； 3）内存泄漏 如何利用工具定位oom? 1) 先查找发生oom的是哪个activity？ 可采取的查找方式有：对每个activity使用adb shell dumpsys meminfo "process
解决Android平台中应用程序OOM异常的方法
01-04
在Android平台上面，应用程序OOM异常永远都是值得关注的问题。通常这一块也是程序这中的重点之一。这下我就如何解决OOM作一点简单的介绍。 首先，OOM就是内存溢出，即Out Of Memory。也就是说内存占有量超过了VM所分配的最大。 怎么解决OOM，通常OOM都发生在需要用到大量内存的情况下（创建或解析Bitmap，分配特大的数组等），在这样的一种情况下，就可能出现OOM，据我现在了解到，多数OOM都是因为Bitmap太大。所以，这里我就专门针对如何解决Bitmap的OOM。其实最核发的就是只加载可见范围内的Bitmap，试想这样一种情况，在GridView或ListView中，数据
如何定位OOM
weixin_42774617的博客
05-22 645
可以将进程的内存heap输出出来到outfile文件里，再配合MAT（内存分析工具(Memory Analysis Tool）或与jhat (Java Heap Analysis Tool)一起使用，能够以图像的形式直观的展示当前内存是否有问题。对生产的dump文件，用JVisualVm分析，查看类的实例数，占内存的大小，找到gcroot，查看线程，定位到具体的代码。打印jvm heap的直方图，但是只答应存活对象的情况，对象的数量、内存大小。生成dump文件：（注意会造成full gc，导致STW）
OOM别慌，手把手教你定位
weixin_41010294的博客
01-17 8394
本渣渣今早正在写BUG呢，TL丢过来一个问题，说是平台有异常让我康康。一顿操作找到错误日志后，傻眼了OutOfMemoryError，这玩意我也就会写写，也没定位过啊。 org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transactio...
OOM问题快速线上定位原因和排查
豪代码的博客
03-22 2170
OOM快速线上定位欢迎使用Markdown编辑器新的改变功能快捷键合理的创建标题，有助于目录的生成如何改变文本的样式插入链接与图片如何插入一段漂亮的代码片生成一个适合你的列表创建一个表格设定内容居中、居左、居右SmartyPants创建一个自定义列表如何创建一个注脚注释也是必不可少的KaTeX数学公式新的甘特图功能，丰富你的文章UML 图表FLowchart流程图导出与导入导出导入 欢迎使用Markdown编辑器 你好！ 这是你第一次使用 Markdown编辑器 所展示的欢迎页。如果你想学习如何使用Mark
Spark面对OOM问题的解决方法及优化总结1
08-08
2.数据不平衡导致内存溢出： 数据不平衡除了有可能导致内存溢出外，也有可能导致性能的问题，解决方法和上面说的类似，就是调用repartition重新分区
Android 的一些基本概念和OOM异常的处理方法
u010257931的博客
07-06 2034
一些基本的概念 ActivityManagerServices，简称AMS，服务端对象，负责系统中所有的Activity的生命周期 ActivityThread，App的真正入口。当开启App之后，会调用main（）开始运行，开启消息循环队列，这就是传说中的UI线程或者叫主线程。与ActivityManagerServices配合，一起完成Activity的管理工作。 ApplicationThre
listView优化以及内存泄露问题
ITtraveler的专栏
04-16 7106
最经开发app使出现了由于ListView产生的内存泄露问题。我们知道内存泄露时很不好的。意味着，代码写的有点失败，需要做些优化改动。 经过这次的教训，以及在网上找了些资料，总结了一下，关于ListView的优化： listview优化问题： 首先，listview必须严格按照convertView及viewHolder格式书写，这样可以基本保证数据最优。 其次，如果自定义Item中有涉及
Android studio定位oom,android 使用okhttp可能引发OOM的一个点
weixin_39706127的博客
05-26 317
遇到一个问题: 需要给所有的请求加签名校验以防刷接口;传入请求url及body生成一个文本串作为一个header传给服务端;已经有现成的签名检验方法String doSignature(String url, byte[] body);当前网络库基于com.squareup.okhttp3:okhttp:3.14.2.这很简单了,当然是写一个interceptor然后将request对象的url及...
[Android]解决HttpURLConnection上传大文件时出现OOM问题
dodod2012的专栏
10-25 771
HttpClient
android图片加载导致的OOM分析及有效解决办法（BitmapUtils）
wlong610的专栏
04-25 4285
android应用尤其是涉及到很多图片处理的经常会遇到OOM（Out Of Memory），为什么会导致OOM，又该如何解决呢？OOM原因分析：android每一个应用都有一个独立的进程，每个进程都是实例化了dalvik虚拟机实例的linux进程。Dalvik 主要管理的内存有 Java heap 和 native heap 两大块。Android系统对dalvik的vm heapsize作了硬性限
Android的 OOM 异常
QYgujingjing的专栏
07-11 635
Android的 OOM 异常
JVM实战-2023线上项目突发OOM以及快速定位解决全过程
qq_34020761的博客
07-01 1128
线上项目突发oom，该文章将展示排查以及最终解决的全过程。
kafka OOM问题定位
09-26
Kafka OOM问题的定位可以通过以下步骤进行： 1. 首先，检查Kafka的内存使用情况。可以通过监控工具（如JMX）或命令行工具（如jstat）来查看Kafka进程的内存使用情况。如果内存使用量接近或超过了可用内存，则可能发生了OOM问题。 2. 接下来，查看Kafka的日志文件，特别是GC日志。GC日志中会显示垃圾收集的情况，以及内存使用的情况。如果GC频率较高或GC时间过长，可能是OOM问题的原因之一。 3. 进一步分析Kafka的堆转储文件（heap dump）。堆转储文件可以通过JVM参数或命令行工具（如jmap）生成。通过分析堆转储文件，可以获得Kafka进程的内存快照，从而确定导致OOM的具体原因，如内存泄漏或内存占用过高的对象。 4. 可以考虑调整Kafka的相关配置参数，如堆大小（heap size）、GC算法等。增加堆大小可提供更多的内存供Kafka使用，但也可能导致GC时间增加。选择合适的GC算法（如CMS或G1）也可以改善内存管理的效果。 5. 如果以上方法均无法解决OOM问题，可能需要检查Kafka的业务逻辑，是否存在内存占用过高或内存泄漏的情况。可以通过代码审查或性能分析工具（如VisualVM）来定位问题。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 3
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值