返回信息流最近在给一个web项目做性能测试，发现一个挺奇怪的问题：
项目使用weblogic12作为容器，使用了spring，mybatis，ehcache等构件，压测结束后服务器闲置了3天左右，发现在闲置阶段虽然也在正常做gc，但总的内存使用量在缓慢上涨，但也没有出现outofmemory的情况，尝试做了下fullgc，内存使用就掉下来了。在fullgc前后出了两个dump对比了一下，没看出什么问题，gc后相对gc前，有一个treeMap的大小变化挺大的，不过看内容像是weblogic的线程管理对象。目前有疑问的是为啥在idle期间使用的内存会缓慢上涨？而且普通的gc无法回收这部分的内存？目前猜测是有东西在持续进入老生代区，导致普通的gc无法回收，但又无法验证。所以想请教各位大神，是否有思路找到这问题的原因？
附一个内存使用情况图：1月20日之前在做压测，之后就一直闲置了，可以很明显看到内存使用量在上涨，23号手动做了个fullgc
这是一条镜像帖。来源：北邮人论坛 / java / #55071同步于 2017/1/24
该镜像源已超过 30 天没有更新，可能在源站已被删除。
Java机器人发帖
【问题】jvm内存回收问题
uriel
2017/1/24镜像同步13 回复
订阅后，新回复会通过你的通知中心匿名送达。
9 条回复
这个曲线可能是survivor年龄到了，进入了老生代，导致minor gc回收不到吧。
也有可能是有大对象直接进去了老生代
还有可能是Minor GC时survivor放不下了，就直接放进老生代了
没有outofmem，如果full gc次数跟停机时间都可以接受的话就没啥毛病
heap的大小直接定在Max吧，感觉也没啥弹性
框架在“空闲期”做了什么只能自己去分析堆跟代码了
菜鸡只能看到这个程度...楼下继续~
多谢你的建议
目前大概10天的运行，fullgc在49次，主要集中在压测期间，运行状态还是满足要求的，就是对这个现象比较好奇，担心会不会有隐患，因为是一个要求7x24小时，服务时间99.9%的金融系统
【 在 ml3615556 的大作中提到: 】
: 这个曲线可能是survivor年龄到了，进入了老生代，导致minor gc回收不到吧。
: 也有可能是有大对象直接进去了老生代
: 还有可能是Minor GC时survivor放不下了，就直接放进老生代了
: ...................
-Xms512m -Xmx2048m -Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl -Djava.awt.headless=true -Dfile.encoding=utf-8 -Dspring.profiles.active=production
是台suse服务器
【 在 earthshaker 的大作中提到: 】
: 把jvm的参数贴出来看看
那还要考虑延迟会不会影响服务质量。
如果会的话……你需要一个实现了concurrent gc的JVM。比如Azul的Zing JVM。如果是这种级别的金融应用，应该不会吝啬在JVM上投资一下吧。
【 在 uriel 的大作中提到: 】
: 多谢你的建议
: 目前大概10天的运行，fullgc在49次，主要集中在压测期间，运行状态还是满足要求的，就是对这个现象比较好奇，担心会不会有隐患，因为是一个要求7x24小时，服务时间99.9%的金融系统
支持并发gc的jvm没有免费的吗？
【 在 nuanyangyang 的大作中提到: 】
: 那还要考虑延迟会不会影响服务质量。
: 如果会的话……你需要一个实现了concurrent gc的JVM。比如Azul的Zing JVM。如果是这种级别的金融应用，应该不会吝啬在JVM上投资一下吧。
:
hotspot有个并发mark sweep回收器，但非copying的gc不适合7x24小时的服务器应用。内存碎片是个问题哦。
【 在 poiuasd 的大作中提到: 】
: 支持并发gc的jvm没有免费的吗？
: :
暖神女神出现啦~~~
tps倒是满足需求，无论是闲置前还是闲置后
买的是weblogic的容器，看说明应该支持concurrent gc吧，不过好像没有特别配置，年后再仔细查一下
【 在 nuanyangyang 的大作中提到: 】
: 那还要考虑延迟会不会影响服务质量。
: 如果会的话……你需要一个实现了concurrent gc的JVM。比如Azul的Zing JVM。如果是这种级别的金融应用，应该不会吝啬在JVM上投资一下吧。
: