Java JVM高频痛点需靠“看”定位：一查堆内存溢出是否因泄漏或配置不当；二查GC频繁是否因年轻代过小或大对象直入老年代；三查线程异常是否因系统资源耗尽；四查元空间溢出是否因类加载未卸载。
一、堆内存溢出（OutOfMemoryError: Java heap space）
这是最常见也最容易误判的问题。表面是“内存不够”，但根源可能是泄漏、大对象、或配置过小。
-
先确认是不是真缺内存：用
jstat -gcutil <pid> 1000观察老年代使用率是否持续 >80%，且 Full GC 后无法回落； - 区分泄漏还是峰值：如果每次请求后老年代缓慢上涨，重启后归零 → 很可能是内存泄漏；若只在大促时突增 → 更可能是流量激增+堆配置不足；
- 别急着加 -Xmx：盲目调大堆内存可能让 GC 延迟更久、卡顿更明显；优先检查是否有静态集合未清理、缓存无淘汰策略、流/连接未关闭等代码问题。
二、频繁 GC 或 GC overhead limit exceeded
系统变慢、CPU 升高、响应延迟，日志里反复出现 GC 记录，甚至报 “GC overhead limit exceeded” —— 这说明 JVM 已经在“拼命打扫却收效甚微”。
-
查 GC 日志是第一动作：启动时加
-Xloggc:gc.log -XX:+PrintGCDetails，用工具（如 GCViewer 或 GCEasy）分析频率、耗时、回收量； -
年轻代太小会加剧晋升：Eden 区过小导致对象频繁 Minor GC，又因 Survivor 空间不足或对象年龄达标，大量进入老年代 → 加重 Full GC；建议按生产标准设
-Xmn为堆的 1/3，-XX:SurvivorRatio=8； -
注意对象分配模式：避免单次创建超大数组（如
new byte[50MB]），这类对象直接进老年代，极易触发 Full GC。
三、线程相关异常（unable to create new native thread）
不是堆内存爆了，而是操作系统级资源耗尽：线程数超限、栈内存总和超标、或 ulimit 设置过严。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
查真实线程数：用
ps -T -p <pid> | wc -l或jstack <pid> | grep 'java.lang.Thread' | wc -l； -
看是不是线程池滥用：比如每个请求都
new Thread()、或线程池 corePoolSize 设得过大且未设置拒绝策略； -
调小单线程栈空间：默认
-Xss1m在高并发场景下太奢侈，可降至-Xss256k（注意递归深度不能因此出错）； -
同步查系统限制：运行
ulimit -u看用户最大进程数，必要时调整/etc/security/limits.conf。
四、元空间溢出（OutOfMemoryError: Metaspace）
尤其多见于热部署、动态代理（如 Spring AOP）、或大量使用反射/字节码生成（如 MyBatis、Lombok）的项目。
立即学习“Java免费学习笔记（深入）”；
- 不是类太多就是卸不掉：JVM 默认不卸载类，每次重新加载（如 Tomcat reload）都会新增元空间占用；
-
加两个关键参数保底：
-XX:MetaspaceSize=256m（初始大小，防频繁扩容） +-XX:MaxMetaspaceSize=512m（上限，防无限增长）； -
配合 GC 策略启用类卸载：若用 CMS，加
-XX:+CMSClassUnloadingEnabled；若用 G1，G1 自带类卸载能力，但需确保没有强引用阻止卸载。
