凌晨两点，监控告警像疯了一样刷屏。服务日志里赫然躺着一行红字：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。希望我的三天，能换你三分钟。
