通过这张JVM内存图:
你来看这个指标：
页面一共6块监控图表，分别是：CPU usage、System memory usage、Heap Memory、Non-Heap Memory、Thread Count、Garbage collection per minute，逐个拆解含义、数值解读、业务风险点。
1. CPU usage 容器/进程CPU使用率
指标含义
分为系统级CPU （容器整体）、JVM进程CPU两部分，百分比代表CPU占用比例。
- System max/avg：容器全部进程CPU峰值、平均值
- Process max/avg：仅Java业务进程的CPU峰值、平均值
图中数值解读
进程最大CPU 2.0%，平均仅1.2%；容器整体峰值2.1%
业务说明
当前服务CPU压力极低，无计算密集、死循环、频繁GC消耗CPU的问题。
2. System memory usage 容器整机内存使用率
指标含义
容器自身内存配额的占用百分比 ，分母为容器启动时通过docker run --memory=4g指定的最大内存限额（4GB）；统计容器内全部内存开销：JVM堆内存 + JVM非堆内存 + 容器系统依赖库 + 容器底层基础进程。
- Max/Average：容器内存占用峰值、平均值（相对4G容器配额的百分比）
图中数值解读
内存占用峰值、平均值稳定在19%，做数值换算： 容器实际占用内存 = 4G × 19% = 0.76GB ≈ 760MB 仅使用容器4G总配额的1/5左右。
结合JVM指标交叉验证
- Heap堆内存：最大限制1GB，实际仅使用0.3GB
- Non-Heap非堆内存：实际占用218.1MB
- JVM内存合计 ≈ 0.3+0.218 = 0.518GB 剩余约240MB为容器系统库、底层进程占用，和760MB总占用完全匹配。
3. Heap Memory JVM堆内存
指标含义
Java对象存放区域，由-Xms/-Xmx控制，GC回收核心区域；三条曲线：
- Avg.used：堆内实际业务对象占用内存
- Avg.committed：操作系统已经分配给JVM的堆内存
- Avg.limit：堆内存最大上限（你的服务-Xmx=1GB）
图中数值解读
实际使用0.3GB，已分配0.4GB，最大限制1GB
业务说明
堆内存仅使用30%，空闲堆内存充足；内存无持续上涨，不存在堆内存泄漏、堆OOM风险。
4. Non-Heap Memory JVM非堆内存
指标含义
不受-Xmx管控，存储类元数据、线程栈、JIT缓存、NIO堆外内存；两条曲线：
- Avg.used：非堆实际占用
- Avg.committed：系统分配给非堆的内存
图中数值解读
实际占用218.1MB，已分配228.7MB
业务说明
SpringBoot常规占用区间，内存平稳无持续爬升；无元空间溢出、堆外内存泄漏问题。
5. Thread Count JVM线程总数
指标含义
当前Java进程存活的所有线程数量，包含业务线程、Tomcat线程池、定时任务、GC后台线程等。
- Avg.count：线程平均数量
- Max.count：线程峰值数量
图中数值解读
平均89.9个线程，峰值91个
业务说明
线程数量稳定、波动极小；无无限创建线程、线程池耗尽、线程泄漏问题。
6. Garbage collection per minute 每分钟GC次数
指标含义
统计每分钟发生的两类GC频次：
- Copy：年轻代Minor GC（Eden区满触发）
- MarkSweepCompact：老年代Full GC（全局STW，严重影响接口性能）
图中数值解读
Copy、Full GC每分钟次数均接近0
业务说明
堆内存充足，对象创建速度慢，几乎不触发GC；无频繁GC、Full GC停顿导致接口超时的性能隐患。
整体服务性能总结
当前服务资源极度空闲：CPU、容器内存、JVM堆内存、线程、GC全部无压力，不存在内存泄漏、GC卡顿、资源耗尽类故障风险。