复现java内存问题需构造可控资源增长场景并精准观测：堆溢出用大数组+小堆限制；元空间溢出用动态类加载+小metaspace限制；内存泄漏通过静态集合累积+长期运行验证；全程固定jvm参数、启用堆转储与gc日志。
要复现 Java 内存溢出（OOM）和内存泄漏，核心是**构造可重现的资源增长场景，并控制 JVM 参数与观测手段**。不是随便写段代码就能稳定触发，关键在于理解触发条件、隔离干扰、精准验证。
复现堆内存溢出（java.lang.OutOfMemoryError: Java heap space）
这是最典型的 OOM，本质是对象持续分配且无法被回收，最终耗尽堆空间。
- 用 无限创建大对象：比如不断 new byte[1024*1024]（1MB 数组），配合 -Xmx100m 限制堆大小，几秒内即可触发
- 避免 GC 干扰：关闭显式 System.gc()，不依赖弱引用/软引用释放逻辑；可用 -XX:+DisableExplicitGC 确保 GC 不被手动触发
- 验证方式：启动时加 -XX:+HeapDumpOnOutOfMemoryError，OOM 后生成 heap dump，用 VisualVM 或 Eclipse MAT 分析主导对象
复现元空间溢出（java.lang.OutOfMemoryError: Metaspace）
适用于大量动态类加载（如反射、字节码增强、OSGi、热部署框架），元空间被撑爆。
- 用 ASM 或 Javassist 动态生成并加载类：每轮循环定义一个新类名，用自定义 ClassLoader 加载，不重用 ClassLoader
- 限制元空间：启动参数加 -XX:MaxMetaspaceSize=32m，加速复现
- 注意：默认类加载器有缓存机制，必须用新 ClassLoader 实例，否则类不会重复注册到 Metaspace
复现内存泄漏（非 OOM，但 RSS 持续上涨、GC 效率下降）
泄漏 ≠ 立即 OOM，而是本该回收的对象因强引用残留，长期积累导致 GC 压力增大、响应变慢。
- 典型泄漏模式：静态集合（Map/List）不断 put 对象；未注销监听器或回调；ThreadLocal 未 remove；缓存未设上限或淘汰策略
- 测试写法：模拟业务循环（如每秒处理 100 个请求），每次向 static Map
中 put 新 key + 1MB value，运行 5–10 分钟后观察老年代使用率是否阶梯式上升 - 确认泄漏：jstat -gc
观察 CMS/Old GC 频次和回收量；jmap -histo 查看某类实例数是否异常增长；对比多次 jmap -dump:format=b,file=heap.hprof 后用 MAT 的 Leak Suspects 报告
编写可重复、易诊断的测试用例要点
不能只靠“跑一次看崩没”，要让问题可观察、可对比、可归因。
- 用 JUnit + @BeforeClass/@AfterClass 控制 JVM 生命周期，或单独写 Main 方法 + 脚本启动，避免 IDE 自带 JVM 干扰
- 固定 JVM 参数：-Xms256m -Xmx256m -XX:MaxMetaspaceSize=64m -XX:+PrintGCDetails -Xloggc:gc.log
- 加入监控钩子：Runtime.getRuntime().addShutdownHook() 输出 final 内存统计；或用 java.lang.management.MemoryUsage 获取 committed/used 值打点
- 记录关键指标：启动时内存、每轮操作后内存、GC 次数、OOM 异常栈 —— 这些才是复现报告的核心证据
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
