测试jvm内存结构临界点需分区域设计：堆内存用固定大小分配循环+禁用动态扩容，观察oom与gc行为；元空间通过动态生成类逼近上限；栈内存用递归或线程创建触发stackoverflowerror或native线程耗尽；直接内存通过directbytebuffer分配并限制maxdirectmemorysize，结合native_memory监控。
要测试 JVM 内存结构的临界点，核心是主动逼近各区域的容量上限，并观察其行为边界与异常触发时机，而不是等待自然溢出。不同内存区域临界点的测试逻辑、手段和风险完全不同，需分区域设计。
堆内存临界点测试
目标是验证 -Xmx 设置是否生效、GC 是否及时介入、OOM 是否在预期堆耗尽时抛出。
- 写一个可控分配循环：每轮创建固定大小对象（如
new byte[1024 * 1024]），放入ArrayList持有引用，防止被 GC；用System.gc()不起作用，靠持续分配逼迫 GC 触发或失败 - 启动参数必须固定堆大小：
-Xms2g -Xmx2g，禁用动态扩容，否则临界点不明确 - 配合
jstat -gc <pid> 500</pid>实时观察 Eden 使用率、YGC 次数、老年代占用增长；当O（老年代）持续 >95% 且 Mixed GC 频繁但回收量小，说明已逼近临界 - 真正临界点标志：抛出
java.lang.OutOfMemoryError: Java heap space，且堆 dump 可确认对象堆积（用jmap -histo对比前后实例数）
元空间（Metaspace）临界点测试
用于验证类加载器泄漏、动态生成类（如 CGLIB、反射代理）是否失控。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 用
Unsafe.defineAnonymousClass或字节码工具（如 ByteBuddy）在循环中反复定义新类，每个类名唯一（避免重名缓存） - 启动参数设限：
-XX:MaxMetaspaceSize=64m，并加-XX:+PrintGCDetails，关注日志中Metadata GC Threshold和Metaspace区使用率 - 临界表现：不再抛 OOM，而是
java.lang.OutOfMemoryError: Metaspace；可用jstat -gcmetacapacity <pid></pid>查看当前元空间容量与使用量 - 注意：JDK 8+ 永久代已移除，
-XX:MaxPermSize无效，勿混淆
虚拟机栈临界点测试
验证线程栈深度与单线程内存占用上限，常用于排查递归过深或线程数爆炸问题。
- 写无限递归方法（如
void recur() { recur(); }），不加 try-catch，直接运行 - 用
-Xss256k降低单线程栈大小，加速触发StackOverflowError - 若想测线程数量极限，改用循环创建新线程（
new Thread(...).start()），不 sleep 不 join，直到抛OutOfMemoryError: unable to create new native thread——这其实是操作系统级线程资源耗尽，非 JVM 栈本身溢出，但属于栈相关临界行为
直接内存（堆外内存）临界点测试
适用于 NIO、Netty、Elasticsearch 等大量使用 DirectByteBuffer 的场景。
- 循环调用
ByteBuffer.allocateDirect(1024 * 1024)，不调用cleaner或free，也不让对象被 GC（例如存入静态集合） - 启动加
-XX:MaxDirectMemorySize=512m（默认等于 -Xmx），观察是否在达到该值时抛OutOfMemoryError: Direct buffer memory - 用
jcmd <pid> VM.native_memory summary</pid>查看Direct分类内存增长，比堆监控更早暴露问题 - 注意：堆外内存不受 GC 管理，只依赖 Cleaner 或显式释放，测试中务必避免自动回收干扰
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
