✅ 会上升的情况
-
频繁垃圾回收(GC)
- 场景:内存占用高导致堆空间不足时,JVM 频繁触发 GC(尤其是 Full GC)。GC 是 CPU 密集型操作,会显著推高 CPU 使用率。
- 数据指标:
jstat -gc
显示FGC
(Full GC 次数)和FGCT
(Full GC 耗时)激增,CPU 监控中 GC 线程占比高]。
-
内存溢出(OOM)前的挣扎
- 场景:内存泄漏导致可用内存耗尽,JVM 持续尝试 GC 但回收失败,形成“GC 风暴”,CPU 长时间接近 100%
-
系统级资源竞争
- 场景:物理内存不足时,操作系统启用 Swap 空间(磁盘交换),频繁的磁盘 I/O 和页面错误(Page Fault)间接推高 CPU 负载。
❌ 不会上升的情况
-
独立的高内存场景
- 场景:静态缓存大量数据(如全局配置加载到内存),内存占用高但无频繁对象创建/销毁,GC 不活跃,CPU 不受影响。
-
独立的高 CPU 场景
- 场景:死循环、复杂算法或线程竞争等问题直接消耗 CPU,但内存占用稳定(如
while(true)
循环无内存增长)。
- 场景:死循环、复杂算法或线程竞争等问题直接消耗 CPU,但内存占用稳定(如
⚠️ 关键判断依据
- GC 活动:通过
jstat
或 GC 日志观察是否伴随频繁 GC(特别是 Full GC)。 - 线程分析:
top -Hp
+jstack
定位高 CPU 线程:- 若为
VM Thread
(GC 线程),则内存是诱因; - 若为业务线程(如
RUNNABLE
状态循环),则 CPU 与内存无关
- 若为
结论:内存占用上升不必然导致 CPU 上升,但若伴随频繁 GC 或 Swap 抖动,则 CPU 会显著升高。排查时优先通过 GC 日志和线程分析区分根因