willbetter

@HiShan 跟你说的情况差不多，那些对象是还有很多没有用完所以没有释放。但我们服务设置了最大堆内存，按理说因为年轻代不够分配内存空间导致 GC ，那最终肯定会把符合条件的对象移动到老年代，一直这样运行最终内存会使用完发生 OOM 啊

@cheng6563 #33 不排除会存在你说的这种情况，但我们另一台服务器另一个服务也有类似的配置和负载的情况下是会产生 OOM 文件的

@fingerxie
@cheng6563
@liuhailiang
@me1onsoda
@Ashe007
感谢各位大佬的分析，其实我主要的疑问就是我在 38 楼所说的。

@jungledg #32 但它一直在 GC 超过 24 小时了就是不会抛出 OOM ，导致一直处于 STW 状态，其它服务都调不通它了。

@admol #31 创建大量对象这几个线程我们清楚是为什么，关键这几个线程要创建的对象数量其实是固定的。

奇怪的现象是它一直在不停的 GC ，这个现象超过了 24 小时，期间其它的线程几乎都没有运行了，猜测是 GC 导致经常 STW 。
主要是想知道是什么原因原因导致它一直 GC 就是不抛出 OOM 错误，抛出 OOM 错误好歹影响的范围小一些，不至于整个进程像现在“假死”了一样

@LiaoMatt OOM 不会导致整个进程都假死了，会产生 OOM 文件。但这个进程是没有产生 OOM 文件的，我是怀疑这里触发了 GC 条件后，业务线程又没来得及处理完这些对象，只处理了一点点，又进行了下一次 GC 。

@LiaoMatt #14 设置这些参数的人感觉就是乱用，这个业务把年轻代和老年代内存 55 分就是不合理的

@dlmy #13 我猜大概也是这样的情况，导致大量对象对那几个业务线程几乎没法处理或处理得很慢

题目说没有 OOM 是我不严谨表达，大家都知道只有内存不够才会 OOM 。
但是各位看日志，年轻代 GC 后并没有释放内存空间，并且内存大小也没有一直不停的增加。但是 GC 一直不断，这样的 GC 一直持续了一天，这样的 GC 开始后不久整个进程就相当于假死了。没有任何响应。

内存日志 dump 分析了引起这次不断 GC 的原因主要是有几个线程突然创建了大量的对象，我的疑问是为什么会一直在不断 GC 。