java缓慢增长 瞬间增长 gc_java – GC应用程序运行缓慢之后

本文探讨了一款在JVM上运行的游戏应用遇到的GC问题,特别是在游戏更新逻辑执行过程中,GC活动导致的CPU使用率异常升高现象。作者提出了两个理论,并寻求社区的帮助以解决这一难题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

我有一个在JVM上运行的应用程序(游戏).

游戏的更新逻辑(运行60次/秒)完成,大约25%使用它的“时间片”(1/60秒),然后休眠剩下的75%.但是当GC收集器运行时,它会上升到75-200%,并在其余的执行中保持不变.

游戏使用大约70Mb的堆并且增长大约1-2mb / s.当GC运行时,它会回到70Mb,因此没有真正的内存泄漏.我将来会尝试降低这个数字,但在这个范围内它应该不是问题.

我正在使用没有运行时参数或标志的JVM 8,不确定哪个GC会给我.

我已经尝试将堆设置为不同的大小,但它不会影响这种现象.

关于为什么会这样,我有两个理论:

> GC无意中将我的堆分段,导致更新循环中的缓存废弃.我有逻辑,它可以从数据接近中获益,因为它会循环并更新它.可能是它将一些数据改组到旧区域,同时保留一些年轻人(托儿所)?

>突然的GC处理触发了我的操作系统,让它意识到我的主要更新步骤不需要像现在这样多的CPU资源,降低了它的优先级. (但是,即使我跳过thread.sleep()来休眠未使用的CPU使用情况,这种现象仍然存在.

你怎么看.我的理论是否合理,可以对它们做些什么,或者我是否需要切换到C语言?我对GC的了解有限.

附:作为附注,通常更新()在GC后75%结束.当我得到200%的数字时使用VSync.

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值