【问题】
MQ长期运行后,出现老代GC不掉的现象分析。
通过HA工具分析后,发现对象TransportConnection占用绝对部分heap空间。
问题分解:实际可以归结为两个方面的问题,如下:
1、VMTransport的建立是由网桥建立动作触发的;即【VMTransport】对象在内存中的增加;
2、VMTransport能否被回收和内存中该对象的引用有关;即【VMTransport】对象在内存中的减少;
【分析】
(1)VMTransport和TransportConnection数量是1:1的关系。
(2)【jms.pool.ConnectionPool】和【 jms.pool.ConnectionPool$1】同时存在,正常的情况下,仅后者出现,即内部类对象。
(3)VMTransport数量为奇数,而仅通过网桥触发的VMTransport是偶数,即成对出现的;
(4)建网桥关键字【Establishing】
(5)通过网桥触发的VMTransport是可以被GC掉的,验证时可以触发System.gc();
(6)MutexTransport如何被ResponseCorrelator所引用?==>相互引用
(7)ResponseCorrelator和MutexTransport都是继承自TransportFilter,怎么会相互引用呢?==>正常
(8)分析正常heapdump和异常的heapdump,发现【FMQConnection】的引用不同,正常时,类【FMQConnection】的owner【ResponseCorrelator】,不正常时,其owner变为【jms/pool/ConnectionPool】导致该类引用在连接池中缓存,回收不掉的问题发生。
【注意】
(1)区分:FMQConnection和broker.TransportConnection以及VMTransport的关系
(2)正常情况下:【FMQConnection】和【ResponseCorrelator】相互引用,发生问题时【FMQConnection】owner为【jms.pool.ConnectionPool】导致无法回收。
(3)VMTransport由使用vm通道时触发生成,如:uri调用vm://<brokerName>或者建立网桥时也会触发vm://<brokerName>
(4)问题发生的原因,【VMTransport】引用了【FMQConnection】,而【FMQConnection】来自【jms.pool.ConnectionPool】,在连接池中,将【FMQConnection】的超时时间设置为了0,导致其不能被回收,从而只要【VMTransport】引用到这种来自连接池的【FMQConnection】对象,
,就有可能只增长而不减少,即回收不掉。
(5)解决方法:
>>>同JVM时,客户端和broker间不使用连接池,直接使用VMTransport产生FMQConnection;
>>>同JVM时,uri采用vm通道,并且要采用连接池,建议连接池中的连接是可回收的,即设置一个超时时间,而不是永不过期;==>目前暂不起作用;
===>建议使用vm通道时,不采用连接池; ===>调整目标是【FMQConnection】不要关联到连接池对象【jms.pool.ConnectionPool】,因为使用了连接池,连接【FMQConnection】也是共享的,而不是单独由连接池提供的。
>>>考虑在MQ配置中,预先添加VM通道,以免客户端首次创建该通道;
>>>如果非要形式上用连接池,则建网桥的动作在通过vm通道创建连接池之前执行;
【问题聚焦】==>和thread context有关还是和触发VM通道的建立次序有关?
【总结】和VM通道的建立次序有关,考虑在MQ配置中,预先添加VM通道,以免客户端因首次创建该通道,并且让【FMQConnection】引用了来自连接池之类的引用不释放对象;
MQ配置通道如下:
//////////begin///////
<transportConnector name="vm" uri="vm://broker-${fmq.brokername}"/>
//////////end/////////
日志如下:
///////////begin//////
Connector openwire started and configured URI is tcp://0.0.0.0:61616
Connector vm started and configured URI is vm://broker-cnd
//////////end/////////
分享到:
相关推荐
事件驱动解析是把文件转换成xml,然后一边读取一边解析,这样就对内存的占用就会很少,可以很好的处理poi出现OOM的问题。 maven添加需要的jar包 <groupId>org.apache.poi <artifactId>poi <version>3.15 ...
针对`ViewFlipper`加载多张图片时可能出现的`OOM`问题,我们可以采取以下策略: 1. **图片压缩**:首先,确保图片资源在加载前已经进行了适当的压缩。这可以通过降低图片的分辨率、压缩图片的质量或者使用像`...
java jvm 中关于内存溢出分享,举例说明各种情况下可能会出现的oom事故
通过以上策略,我们可以有效地解决SurfaceView加载帧动画时可能出现的OOM问题,并确保动画流畅运行,即使帧数众多,也不会出现卡顿现象。在实际开发中,需要根据项目的具体需求和性能要求,灵活应用这些技巧,以提供...
2. 数据不平衡也可能导致OOM,因为某些Executor可能接收过多数据,从而耗尽内存。解决方法同样是对数据进行`repartition`,确保数据均匀分布到各个Executor上。 3. `coalesce`在某些场景下可能导致内存溢出,比如当...
综上所述,解决Android加载图片出现的OOM问题需要综合运用各种策略,包括优化图片加载、缓存管理、使用合适的图片库以及合理地管理生命周期。只有这样,才能在保证用户体验的同时,避免因图片处理引发的内存问题。
在Android开发中,图片加载是常见的任务,但同时也是导致内存溢出(Out Of Memory, OOM)问题的主要原因之一。特别是当处理大量图片,如在ListView或RecyclerView中滚动时,如果没有正确的图片管理策略,图片加载...
如果在Keras内部多次使用同一个Model,例如在不同的数据集上训练同一个模型进而得到结果,会存在内存泄露的问题。在运行几次循环之后,就会报错OOM。 解决方法是在每个代码后面接clear_session()函数,显示的关闭TF...
标题“加载本地图片,绝对不会出现OOM.zip”暗示了这个压缩包包含了关于如何在Android应用程序中正确加载本地图片,以避免内存溢出(Out Of Memory,简称OOM)问题的示例代码。在Android开发中,由于有限的内存资源...
当Java应用出现OOM时,JVM会抛出`java.lang.OutOfMemoryError`异常。这通常由以下几种情况引起: 1. **堆内存溢出**:这是最常见的OOM情况,当对象实例不断创建且无法被垃圾收集器回收时,堆空间会被耗尽。 2. **...
在Android开发中,加载本地图片是一项常见的任务,但如果不妥善处理,可能会引发内存溢出(Out Of Memory,简称OOM)问题。OOM是Android应用中一个常见的运行时异常,尤其是在处理大量图片或者大尺寸图片时,可能...
二、解决GIF OOM的策略 1. 使用GIF库:常见的Android GIF库有Glide、Picasso、Universal Image Loader等,它们都提供了处理GIF的能力。这些库会在内存中缓存图片的一小部分,并根据需要动态加载下一帧,从而减少内存...
当应用程序出现Out of Memory (OOM)错误时,通常意味着系统无法分配足够的内存来执行任务,这时就需要借助专业的分析工具来查找问题的根源。MemoryAnalyzer(MAT)是IBM开发的一款强大的JVM堆内存分析工具,它能够...
OOM全称”Out Of Memory”,即内存溢出。 内存溢出已经是软件开发历史上存在了近40年的“老大难”问题。...如果已经出现OOM,则可以通过dmesg命令查看,CentOS7版本以上支持 -T选项,能将时间戳转成时
SpringBoot 中 @Async 默认线程池导致 OOM 问题 在 SpringBoot 中使用 @Async 注解来实现异步操作是一种非常常见的做法,但是如果不小心,可能会导致 OOM(Out of Memory)问题。本文将详细介绍 SpringBoot 中 @...
应用源码之加载本地图片,绝对不会出现OOM
基本上解决了OOM问题 如果 方便可以直接引用BitmapManager类到 项目中使用 解决blog 地址http://www.cnblogs.com/liongname/articles/2345087.html
"Android高级应用源码-加载本地图片,绝对不会出现OOM.zip"是一个针对这一问题的解决方案,它包含了如何在Android应用中加载本地图片而不引发内存溢出的示例代码。 首先,我们要理解为什么加载图片会引发OOM。在...
"Android应用源码之加载本地图片,绝对不会出现OOM.zip"这个压缩包文件显然提供了关于如何在Android中安全、高效地加载本地图片,避免OOM问题的解决方案。 首先,我们来深入理解为什么Android应用在处理图片时容易...