java游戏服务端, 内存泄露怎么查看, 如果是线上的话怎么处理, 线上cpu 100%处理.

使用 jmap 手动 dump（最常用）
jmap -dump:live,format=b,file=heap.bin <pid>

live：只导出存活对象（强烈建议）
dump 文件一般很大（几个 G）

分析工具（重点）
MAT（Memory Analyzer Tool，首选）

jstat（看趋势）
jstat -gcutil <pid> 1000

1. 内存区域（单位：KB）

• S0：Survivor 0 区使用率 年轻代的两个幸存者区之一，存放存活的小对象
• S1：Survivor 1 区使用率 和 S0 交替使用，同一时间只有一个区有数据
• E：Eden 区使用率 新对象创建的地方，满了就触发年轻代 GC（YGC）
• O：Old 老年代使用率 存活时间长的对象、大对象存放区，满了触发FullGC（FGC）
• M：Metaspace 元空间使用率 存放类信息、方法、常量，JDK8 替代永久代
• CCS：Compressed Class Space 压缩类空间使用率 元空间的一部分，专门存放压缩后的类元数据

2. GC 次数 & 耗时（核心性能指标）

• YGC：Young GC 次数 年轻代垃圾回收的总次数
• YGCT：Young GC 总耗时（单位：秒） 所有年轻代 GC 加起来的总时间
• FGC：Full GC 次数 全堆垃圾回收（非常昂贵，越少越好）
• FGCT：Full GC 总耗时（秒） 所有 FullGC 的总时间
• GCT：GC 总耗时（秒） YGCT + FGCT，所有 GC 的总耗时

快速判断 JVM 健康状态（实用口诀）

1. FGC 多、FGCT 大 → 严重问题（内存泄漏、堆太小、大对象过多）
2. O 区持续上涨不下降 → 大概率内存泄漏
3. M 区满 → 类加载太多，需要调大元空间

关注：
O（Old 区）是否接近 100%
FGC 次数是否持续增长

jstack（看线程）
jstack <pid> > stack.txt
用于排查：
死循环
线程阻塞导致对象无法释放

jprofiler

线上可以使用
kill -15 来重启, 不是-9, -9为强杀, -15为优雅退出
保留日志
保留 gc.log

会触发 Full GC
大堆可能停顿数秒 ~ 数十秒
👉 非核心服 / 低峰期才做

开启 OOM 自动 dump
-XX:+HeapDumpOnOutOfMemoryError

jmap -histo（只统计数量，不 dump）
jmap -histo:live <pid>

cpu 100%
抓线程栈
jstack <pid> > jstack.txt
抓 3~5 次，间隔 5~10 秒

top -H -p <pid>
抓 CPU 占用最高的线程
top -H -p <pid>
你会看到类似：
tid 14023 99.9%
把 tid 转成 16 进制：
printf "%x\n" 14023
然后在 jstack.txt里搜：
nid=0x36f7
👉 直接定位到“罪魁祸首代码行”

1. top 确认 Java 进程
2. top -H -p <pid> 找最忙线程
3. jstack 抓栈（多次）
4. 转 tid 为 nid
5. 定位 RUNNABLE 代码
6. 看是否是循环 / 高频逻辑
7. 本地复现
8. 修复 + 压测
9. 灰度上线

top
top -H -p <pid>
jstack <pid> > jstack.txt 打印某个线程的堆
printf "%x\n" <tid>
grep -R "nid=0x<hex>" jstack.txt
jstat JVM Statistics Monitoring Tool,  JDK 自带的、用来实时监控 Java 程序运行状态的命令行工具, 内存使用、垃圾回收（GC）、类加载, 用来查内存溢出.

jmap JVM Memory Map 查  JDK 自带的堆内存分析工具，专门用来导出内存快照、查看堆里有什么对象、排查内存泄漏. 看每种类型对象占用空间

jstack = JVM Stack Trace, 打印所有线程的调用栈, 定位死锁

• jstat：看内存、GC实时数据（动态监控）
• jmap：抓堆内存快照，查对象、OOM（内存问题）
• jstack：抓线程快照，查死锁、CPU 高、卡住（线程问题）