@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 。

@liprais 把整个 GC 日志都给它分析过，没有得到非常有用的信息

@c3de3f21 参数可能有不合理的，引起这次一直不断 GC 都原因是一下子创建了很多对象。关键是一直在 GC 没有 OOM 就很奇怪

不说都不在意，一直开着小火箭，一看耗电量居然排第一占比 30%

之前在中厂带了几个外包，也就那么回事没啥用

用户增长是算法那块吗，还是啥业务。想了解一下，我现在也在做用户增长的业务但几乎都是 sdk 工程师和 sql boy

@foolishcrab 也不是偷懒，如果好的指引还是可以达到事半功倍的效果

这么便宜？同是广州我办的移动 300M 好像是 79 一个月

文章是文本数据可以考虑使用 ES 来存储，入库的时候进行打标分类就行，也可以提取内容的关键词等特征向量，搜索的时候利用相似度进行匹配

这是爬脉脉的数据吗