凌晨两点监控告警像疯了一样刷屏。服务日志里赫然躺着一行红字java.lang.OutOfMemoryError。我原以为是个简单的堆溢出重启一下就能撑到天亮没想到这一查就是三天。今天我把这次踩坑经历整理成三种最常见的Java内存溢出姿势。希望你遇到时能少走点弯路。第一种堆内存溢出——最熟悉的陌生人报错信息java.lang.OutOfMemoryError: Java heap space这是最常见的一种。现象是Full GC频繁触发但老年代始终回收不掉最终堆被撑爆。我遇到的场景很典型一个本地缓存用的ConcurrentHashMap每秒写入几千条数据却从来没有清理逻辑。系统跑上两天堆就满了。排查方式也直接——jmap -dump导出堆快照用MAT打开一眼就能看到那个Map占了80%的内存。解决起来不难换成Guava Cache或Caffeine设置最大容量和过期时间或者干脆上Redis。但关键是你得意识到“本地缓存”这四个字背后藏着一个定时炸弹。第二种元空间溢出——我查了三天的元凶报错信息java.lang.OutOfMemoryError: Metaspace堆内存正常GC日志却显示Metaspace从200M一路涨到1G最终OOM。这就是让我熬了三天的第二种姿势。第一天我以为是堆泄漏反复dump、MAT分析一无所获——因为类元数据根本不在堆里。第二天我翻遍JVM参数调整-XX:MaxMetaspaceSize只是把爆炸时间往后推了推。第三天我打开GC日志用jcmd GC.class_stats和jmap -clstats查看类加载器才发现一个自定义ClassLoader加载了上万个类。真相是系统里有个脚本引擎每次执行都new一个ClassLoader去加载Groovy脚本执行完却没有释放。类加载器活着它加载的所有类元数据就活着Metaspace只增不减。最后用Arthas的classloader命令才彻底定位。解决方式缓存ClassLoader复用或者手动清理。但排查过程教会我一件事——堆溢出看得见元空间溢出看不见而看不见的往往更致命。第三种GC overhead limit exceeded——JVM的“最后通牒”报错信息java.lang.OutOfMemoryError: GC overhead limit exceeded这是JVM的一种保护机制当GC花费超过98%的时间却回收不到2%的堆空间时它干脆直接抛出错误告诉你“别挣扎了”。本质还是内存泄漏或堆太小但表现更隐蔽——CPU飙升GC线程疯狂跑应用却几乎停滞。排查思路和堆溢出类似dump堆、找泄漏点。预防手段是监控GC频率和回收效率别等到JVM自己放弃。写在最后三种姿势本质都是对象生命周期管理失控。堆溢出是对象太多元空间溢出是类太多GC overhead是回收效率太低。写单元测试能帮你发现逻辑漏洞但内存问题往往要靠监控、dump和日志。那三天里我翻遍了GC日志、类加载器、动态代理最后发现凶手只是一个没被释放的ClassLoader。希望我的三天能换你三分钟。