有关activemq内存溢出的问题 -Java- TryCatch
>> Content
有关activemq内存溢出的问题
本人刚开始接触activemq，使用的是activemq&5.6版本。现在出现了这样的问题，我通过线程不停的发送topic消息到服务器，会发现服务器上，我发的那个topic的消息队列越来越大持久化或非持久化消息都试了，都是这样的情况，然后内存就开始吃紧，直至内存不足，服务器崩溃。请问有什么办法可以解决？我想到的几个思路：1.设置队列总数的上限，比如1000，当到达上限后，消息通过先进先出的方法使队列总数不再增加。2.对消息本身设置有效时长，时间到了自动删除。但是我都不知道应该怎么设置，或者，还有别的办法可以解决这个问题吗？官方网站上关于内存的文档我也看了，不是很明白该怎么做注：消息发送端为java实现，目前还没有与spring整合
------Solutions------
MessageProducer&有个&setTimeToLive&方法activemq.xml&中配置systemUsage节的内容，不过貌似是没有队列大小设置的。只是整个队列所耗空间大小的设置，超出就不能再发送消息了。参考/blog/1072177http://activemq.apache.org/producer-flow-control.html
------Solutions------
引用&1&楼&&的回复:MessageProducer&有个&setTimeToLive&方法activemq.xml&中配置systemUsage节的内容，不过貌似是没有队列大小设置的。只是整个队列所耗空间大小的设置，超出就不能再发送消息了。参考/blog/1072177http://activemq.apache.or……我还想问下，现在在一个工程里，会有多个地方，多个线程都会需要发送消息。那么，哪些是可以让整个工程公用的？比如Connection是否整个工程只要创建一个就够了？同理Session呢？MessageProducer呢？
------Solutions------
conection一个程序只要一个足够。线程安全session不是线程安全的，并且创建的代价比较高，建议用对象池。MessageProducer当然是每次使用都要新建。建议用spring来简化jms的调用。网上文章一大把，搜一下。
------Solutions------
&beans&xmlns="http://www.springframework.org/schema/beans"&&&xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"&&&xmlns:p="http://www.springframework.org/schema/p"&&&xmlns:tx="http://www.springframework.org/schema/tx"&&&xmlns:aop="http://www.springframework.org/schema/aop"&&&xmlns:context="http://www.springframework.org/schema/context"&&&xmlns:util="http://www.springframework.org/schema/util"&&&xmlns:jee="http://www.springframework.org/schema/jee"&&&xmlns:amq="http://activemq.apache.org/schema/core"&&&xsi:schemaLocation="http://www.springframework.org/schema/beans&&&http://www.springframework.org/schema/beans/spring-beans-2.5.xsd&&&http://www.springframework.org/schema/tx&&&http://www.springframework.org/schema/tx/spring-tx-2.5.xsd&&&http://www.springframework.org/schema/aop&&&http://www.springframework.org/schema/aop/spring-aop-2.5.xsd&&&http://www.springframework.org/schema/context&&&http://www.springframework.org/schema/context/spring-context-2.5.xsd&&&http://www.springframework.org/schema/util&&&http://www.springframework.org/schema/util/spring-util-2.5.xsd&&&http://www.springframework.org/schema/jee&&&http://www.springframework.org/schema/jee/spring-jee-2.5.xsd&&&http://activemq.apache.org/schema/core&&&http://activemq.apache.org/schema/core/activemq-core-5.6.0.xsd"&在和spring整合时，这个资源一直会报找不到，但是用浏览器是可以看到这个资源的，这是为什么？
------Solutions------
------Solutions------
没碰到过这种问题。检查下你的工程引用里有没有&activemq-all-xxx.jar&和&activemq-spring-xxx.jar打开activemq-all-xxx.jar&检查META-INF/spring.schemas&文件的内容里有没有你写的那行的&*.xsd
------Solutions------
也遇到和楼主类似的问题，想监控activemq的动态内存，目前只能取到入列和出列消息数，也可取到activemq的内存限制大小，但动态内存还无法获取。【转载】java项目中经常碰到的内存溢出问题: java.lang.OutOfMemoryError: PermGen space,
堆内存和非堆内存，写的很好，理解很方便 - tomcat and jerry - 博客园
解决方案 在&catalina.bat 里的&蓝色代码前加入:&红色代码&
rem ----- Execute The Requested Command ---------------------------------------
set JAVA_OPTS=%JAVA_OPTS%-server -Xms800m -Xmx1024m &-XX:PermSize=128m -XX:MaxPermSize=256m
echo Using CATALINA_BASE:
"%CATALINA_BASE%"
以下为 区别说明 : 摘 自:&/mingforyou/archive//2378143.html
Eclipse崩溃，错误提示：MyEclipse has detected that less than 5% of the 64MB of Perm&Gen (Non-heap memory) space remains. It is strongly recommendedthat you exit and restart MyEclipse with new virtual machine memoryparamters to increase this memory.&& Failure to do so can result indata loss. The recommended Eclipse memory parameters are:&eclipse.exe -vmargs -Xms128M -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128M&1.参数的含义-vmargs -Xms128M -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128M-vmargs 说明后面是VM的参数，所以后面的其实都是JVM的参数了-Xms128m JVM初始分配的堆内存-Xmx512m JVM最大允许分配的堆内存，按需分配-XX:PermSize=64M JVM初始分配的非堆内存-XX:MaxPermSize=128M JVM最大允许分配的非堆内存，按需分配
我们首先了解一下JVM内存管理的机制，然后再解释每个参数代表的含义。
1)堆(Heap)和非堆(Non-heap)内存
&按照官方的说法：&Java 虚拟机具有一个堆，堆是运行时数据区域，所有类实例和数组的内存均从此处分配。堆是在 Java 虚拟机启动时创建的。&&在JVM中堆之外的内存称为非堆内存(Non-heap memory)&。&可以看出JVM主要管理两种类型的内存：堆和非堆。简单来说堆就是Java代码可及的内存，是留给开发人员使用的；非堆就是JVM留给自己用的，&所以方法区、JVM内部处理或优化所需的内存(如JIT编译后的代码缓存)、每个类结构(如运行时常数池、字段和方法数据)以及方法和构造方法的代码都在非堆内存中。&
堆内存分配
&JVM初始分配的堆内存由-Xms指定，默认是物理内存的1/64；JVM最大分配的堆内存由-Xmx指定，默认是物理内存的1/4。默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制；&空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制。因此服务器一般设置-Xms、-Xmx 相等以避免在每次GC 后调整堆的大小。&说明：如果-Xmx 不指定或者指定偏小，应用可能会导致java.lang.OutOfMemory错误，此错误来自JVM，不是Throwable的，无法用try...catch捕捉。&
非堆内存分配
&JVM使用-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64；由XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4。（还有一说：MaxPermSize缺省值和-server -client选项相关，&-server选项下默认MaxPermSize为64m，-client选项下默认MaxPermSize为32m。这个我没有实验。）&上面错误信息中的PermGen space的全称是Permanent Generation space，是指内存的永久保存区域。还没有弄明白PermGen space是属于非堆内存，还是就是非堆内存，但至少是属于了。XX:MaxPermSize设置过小会导致java.lang.OutOfMemoryError: PermGen space 就是内存益出。&说说为什么会内存益出：&（1）这一部分内存用于存放Class和Meta的信息，Class在被 Load的时候被放入PermGen space区域，它和存放Instance的Heap区域不同。&（2）GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS 的话,就很可能出现PermGen space错误。& 这种错误常见在web服务器对JSP进行pre compile的时候。 &
2)JVM内存限制(最大值)
&首先JVM内存限制于实际的最大物理内存，假设物理内存无限大的话，JVM内存的最大值跟操作系统有很大的关系。简单的说就32位处理器虽然可控内存空间有4GB,但是具体的操作系统会给一个限制，&这个限制一般是2GB-3GB（一般来说Windows系统下为1.5G-2G，Linux系统下为2G-3G），而64bit以上的处理器就不会有限制了。
2. 为什么有的机器我将-Xmx和-XX:MaxPermSize都设置为512M之后Eclipse可以启动，而有些机器无法启动？&通过上面对JVM内存管理的介绍我们已经了解到JVM内存包含两种：堆内存和非堆内存，另外JVM最大内存首先取决于实际的物理内存和操作系统。所以说设置VM参数导致程序无法启动主要有以下几种原因：1) 参数中-Xms的值大于-Xmx，或者-XX:PermSize的值大于-XX:MaxPermSize；2) -Xmx的值和-XX:MaxPermSize的总和超过了JVM内存的最大限制，比如当前操作系统最大内存限制，或者实际的物理内存等等。说到实际物理内存这里需要说明一点的是，&如果你的内存是1024MB，但实际系统中用到的并不可能是1024MB，因为有一部分被硬件占用了。
3. 为何将上面的参数写入到eclipse.ini文件Eclipse没有执行对应的设置？&那为什么同样的参数在快捷方式或者命令行中有效而在eclipse.ini文件中是无效的呢？这是因为我们没有遵守eclipse.ini文件的设置规则：参数形如&项 值&这种形式，中间有空格的需要换行书写，如果值中有空格的需要用双引号包括起来。比如我们使用-vm C:/Java/jre1.6.0/bin/javaw.exe参数设置虚拟机，在eclipse.ini文件中要写成这样：-vm&C:/Java/jre1.6.0/bin/javaw.exe&-vmargs&-Xms128M&-Xmx512M&-XX:PermSize=64M&-XX:MaxPermSize=128M&实际运行的结果可以通过Eclipse中&Help&-&About Eclipse SDK&窗口里面的&Configuration Details&按钮进行查看。另外需要说明的是，Eclipse压缩包中自带的eclipse.ini文件内容是这样的：-showsplash&org.eclipse.platform&--launcher.XXMaxPermSize&256m&-vmargs&-Xms40m&-Xmx256m&其中&launcher.XXMaxPermSize（注意最前面是两个连接线）跟-XX:MaxPermSize参数的含义基本是一样的，我觉得唯一的区别就是前者是eclipse.exe启动的时候设置的参数，而后者是eclipse所使用的JVM中的参数。其实二者设置一个就可以了，所以这里可以把&launcher.XXMaxPermSize和下一行使用#注释掉。
4. 其他的启动参数。 如果你有一个双核的CPU，也许可以尝试这个参数:-XX:+UseParallelGC让GC可以更快的执行。（只是JDK 5里对GC新增加的参数）
补充：　　如果你的WEB APP下都用了大量的第三方jar，其大小超过了服务器jvm默认的大小，那么就会产生内存益出问题了。解决方法： 设置MaxPermSize大小&可以在myelipse里选中相应的服务器比如tomcat5，展开里面的JDK子项页面，来增加服务器启动的JVM参数设置：-Xms128m&-Xmx256m&-XX:PermSize=128M&-XX:MaxNewSize=256m&-XX:MaxPermSize=256m或者手动设置MaxPermSize大小,比如tomcat，修改TOMCAT_HOME/bin/catalina.bat，在echo "Using CATALINA_BASE: $CATALINA_BASE"上面加入以下行：&JAVA_OPTS="-server -XX:PermSize=64M -XX:MaxPermSize=128m
建议：将相同的第三方jar文件移置到tomcat/shared/lib目录下，这样可以减少jar 文档重复占用内存<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
您的访问请求被拒绝 403 Forbidden - ITeye技术社区
您的访问请求被拒绝
亲爱的会员，您的IP地址所在网段被ITeye拒绝服务，这可能是以下两种情况导致：
一、您所在的网段内有网络爬虫大量抓取ITeye网页，为保证其他人流畅的访问ITeye，该网段被ITeye拒绝
二、您通过某个代理服务器访问ITeye网站，该代理服务器被网络爬虫利用，大量抓取ITeye网页
请您点击按钮解除封锁&二次元同好交流新大陆
扫码下载App
汇聚2000万达人的兴趣社区下载即送20张免费照片冲印
扫码下载App
温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
关注海量数据存储、处理和检索，MySQL，系统运维，图像处理等技术
LOFTER精选
网易考拉推荐
Memcached-Java-Clinet 一个bug引起的java direct-memeory内存溢出&&
13:59:06|&&分类：
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
1. 问题场景在运维timeline系统的过程中，发现Java主进程占用7.9G内存（宿主机totalMem为8G），从而导致了OutOfMemeory异常。追踪发现程序中用3.0.1版本的Memcached-Java-Clinet程序出现内存泄露导致OOM问题。泄露内存是Memcached分配的navicate内存（也就是Direct Buffer）。2. 排查问题的方法首先 jmap -histo pid （找到这个进程占用最多的对象）&num & & #instances & & & & #bytes &class name----------------------------------------------& &1: & & & &390214 & & & &[C& &2: & & & & 67767 & & &
&[I& &3: & & & 1601037 & & &
&java.util.AbstractList$ListItr& &4: & & & & 85367 & & &
&[B& &5: & & & &302804 & & &
&[Ljava.lang.O& &6: & & & &255924 & & &
&java.nio.DirectByteBuffer& &7: & & & &256046 & & &
&sun.misc.Cleaner& &8: & & & & 62060 & & & &9343048 && &9: & & & &277220 & & & &8871040 &java.lang.String& 10: & & & & 62060 & & & &8452560 && 11: & & & & &5530 & & & &6320272 && 12: & & & &255924 & & & &6142176 &java.nio.DirectByteBuffer$Deallocator& 13: & & & & 97432 & & & &5552104 && 14: & & & & 54061 & & & &5094352 &[Ljava.util.HashMap$E。。。。。。。。。（下面省略很多）Total & & & 5580112 & & & &3. 问题分析这里我们要追问三个问题：（a）多余的内存分配到哪里去了？（b）内存到底泄露了没有？（c）如果没有泄露，jvm为什么不垃圾回收呢；如果泄露，那么原因是什么？3.1 多余的内存分配到哪里去了？分析可知javaheap上共用内存为644M左右，远远小于pid进程所用的内存（7.9G）。也就是说有很多内存并没有分配到javaheap上。仔细分析发现占用内存较多的对象里有DirectByteBuffer和java.nio.DirectByteBuffer$Deallocator，这说明有很多内存是DirectBuffer占用，而这些内存是调用native方法生成的，并不是在堆上分配的，这样就解释了javaheap内存远小于进程占用的内存。（注意：java中直接内存并不算在javaheap中，这也解释了为何javaheap内存很小，但整个进程占用的内存却很大）3.2 内存到底泄露了没有？内存泄露的两种情况：(a)&内存分配出去，程序中依然引用这块内存，但逻辑上不在使用这块内存。(b)&内存中分配出去，程序中不在引用这块内存，理论上这部分内存是可以被垃圾回收掉的。但是如果这部分内存增长很快，以至于在垃圾回收之前就导致OOM异常，那么我们也应该认为这是一种内存泄露。其实java中自带有垃圾回收器，可以定期的回收我们程序中不在引用的内存。但是垃圾收集器并不保证可以及时的释放垃圾内存。比如我们遇到的问题，由于javaheap占用内存很少，即使进程把机器内存吃完了却依然没有触发垃圾收集器回收垃圾内存。对于这种内存泄露问题java程序员就要特别小心了。3.3&如果没有泄露，jvm为什么不垃圾回收呢；如果泄露，那么原因是什么？从3.2分析可知我们的程序确实存在内存泄露问题。根据3.1的分析我们可以知道大部分内存是DirectByteBuffer和java.nio.DirectByteBuffer$Deallocator对象所引用的本地内存。这部分内存用了足足有7G之多。那么这些对象又是谁生成的呢？为什么会产生如此之多的类似对象呢？首先使用jstack pid 获取线程堆栈（用来追踪这些对象的生成者）："http-8181-24" daemon prio=10 tid=0x8800 nid=0x4f98 runnable [0x0c000]& &java.lang.Thread.State: RUNNABLE& & & & at sun.nio.ch.FileDispatcher.read0(Native Method)& & & & at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21)& & & & at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:202)& & & & at sun.nio.ch.IOUtil.read(IOUtil.java:169)& & & & at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:243)& & & & - locked &0x88c8& (a java.lang.Object)& & & & at com.schooner.MemCached.SockInputStream.(SockInputStream.java:84)& & & & at com.schooner.MemCached.AscIIClient.get(AscIIClient.java:691)& & & & at com.schooner.MemCached.AscIIClient.get(AscIIClient.java:609)& & & & at com.schooner.MemCached.AscIIClient.get(AscIIClient.java:605)& & & & at com.danga.MemCached.MemCachedClient.get(MemCachedClient.java:911)& & & & at com.mon.util.MemcachedUtilSchoonerImpl.get(MemcachedUtilSchoonerImpl.java:35)& & & & at com.netease.timeline.api.cache.EventCacheManager.getEvent(EventCacheManager.java:57)通过分析发现堆栈中出现大量类似的信息。我们队这里的readIntoNativeBuffer单词比较敏感，因为这个buffer和我们分析的DirectBuffer有关。顺着这条线外加Mamached-Java-Client源码梳理下去，很快找到了问题的最终原因。根据堆栈中的get方法梳理下去&MemCachedClient -& get -& AscIIClinet.get -& SchoonerSockIOPool.getSock -& SchoonerSockIOPool.getConnection -& (SchoonerSockIO)sockets.borrowObject() -&&SchoonerSockIO extends SockIOPool.SockIO -& SockIO构造函数 -& SockIO.getSocket此函数源码如下：protected static Socket getSocket(String host, int port, int timeout) throws IOException{& & SocketChannel sock = SocketChannel.open();& & sock.socket().connect(new InetSocketAddress(host, port), timeout);& & return sock.socket();}这个函数第一步open()函数就已经分配了内存（而且是directbuffer），如果第二部connect出现异常，程序并没有主动调用close函数关闭sock句柄，这样第一步open函数中分配的内存没有被释放。由于服务器连接不上，会多次调用这个函数，这样就会分配大量的directbuffer，最终在垃圾会收前导致内存溢出。4. 总结a. 这个版本Memcached-Java-Clinet在新的版本中已经得到修复，请大家及时更新使用版本，避免带来类似的麻烦。b. 在排查java系统内存溢出问题时，如果发现javaheap中内存使用很少但进程所占用内存非常多，此时应该判断是否有direct内存的使用。c. 直接内存分配的空间不是在javaheap上，由于直接内存不在jvm内存监控范围之内，所以垃圾收集器并没有感受到内存已经很紧张的情况。如果heap上使用空间很少而直接内存分配很多，可能会导致垃圾回收前内存溢出问题。因为heap上剩余空间很多的话不会触发垃圾回收，及时此时整个进程已经内存溢出。
阅读(1756)|
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
历史上的今天
loftPermalink:'',
id:'fks_',
blogTitle:'Memcached-Java-Clinet 一个bug引起的java direct-memeory内存溢出',
blogAbstract:'这篇文章主要介绍DirectMemory溢出的系统表现和排查方法，另外提醒读者Memcached java客户端3.0.1版本存在一个bug，如果大家使用了这个版本请及时升级，免得带来类似问题。1. 问题场景在运维timeline系统的过程中，发现Java主进程占用7.9G内存（宿主机totalMem为8G），从而导致了OutOfMemeory异常。追踪发现程序中用3.0.1版本的Memcached-Java-Clinet程序出现内存泄露导致OOM问题。泄露内存是Memcached分配的navicate内存（也就是Direct Buffer）。',
blogTag:'',
blogUrl:'blog/static/0',
isPublished:1,
istop:false,
modifyTime:5,
publishTime:4,
permalink:'blog/static/0',
commentCount:0,
mainCommentCount:0,
recommendCount:0,
bsrk:-100,
publisherId:,
recomBlogHome:false,
currentRecomBlog:false,
attachmentsFileIds:[],
groupInfo:{},
friendstatus:'none',
followstatus:'unFollow',
pubSucc:'',
visitorProvince:'',
visitorCity:'',
visitorNewUser:false,
postAddInfo:{},
mset:'000',
remindgoodnightblog:false,
isBlackVisitor:false,
isShowYodaoAd:false,
hostIntro:'关注海量数据存储、处理和检索，MySQL，系统运维，图像处理等技术',
selfRecomBlogCount:'0',
lofter_single:''
{list a as x}
{if x.moveFrom=='wap'}
{elseif x.moveFrom=='iphone'}
{elseif x.moveFrom=='android'}
{elseif x.moveFrom=='mobile'}
${a.selfIntro|escape}{if great260}${suplement}{/if}
{list a as x}
推荐过这篇日志的人：
{list a as x}
{if !!b&&b.length>0}
他们还推荐了：
{list b as y}
转载记录：
{list d as x}
{list a as x}
{list a as x}
{list a as x}
{list a as x}
{if x_index>4}{break}{/if}
${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')}
{list a as x}
{if !!(blogDetail.preBlogPermalink)}
{if !!(blogDetail.nextBlogPermalink)}
{list a as x}
{if defined('newslist')&&newslist.length>0}
{list newslist as x}
{if x_index>7}{break}{/if}
{list a as x}
{var first_option =}
{list x.voteDetailList as voteToOption}
{if voteToOption==1}
{if first_option==false},{/if}&&“${b[voteToOption_index]}”&&
{if (x.role!="-1") },“我是${c[x.role]}”&&{/if}
&&&&&&&&${fn1(x.voteTime)}
{if x.userName==''}{/if}
网易公司版权所有&&
{list x.l as y}
{if defined('wl')}
{list wl as x}{/list}}