JVM内存结构实战以可观测、可验证、可干预为核心，通过GC日志、jstat、jstack、jmap等工具验证堆分区行为、线程栈异常、元空间泄漏及不同GC算法效果，强调参数设置→操作触发→日志分析→假设调整的闭环验证。
JVM 内存结构核心实战演练不是背概念，而是通过可观测、可验证、可干预的方式，把内存区域的行为“看得到、改得了、调得稳”。
堆内存分配与对象生命周期观察
重点验证新生代三区（Eden、S0、S1）如何协作，以及对象何时晋升老年代。
- 启动参数加
-XX:+PrintGCDetails -Xloggc:gc.log，让每次GC过程输出到日志； - 编写代码连续分配多个2MB对象（避开TLAB干扰），触发Minor GC，观察日志中
Eden: 8192K->256K(8192K)这类变化，确认存活对象进入Survivor； - 再分配一个8MB大对象（大于
-XX:PretenureSizeThreshold=4M），验证它是否直接落入老年代（日志中出现allocation request: 8388608 bytes+direct to old gen）； - 用
jstat -gc实时查看S0C/S1C/EC/OC容量与使用量，对比YGC次数和YGCT耗时。
线程私有区异常复现与定位
不靠猜，靠压测和日志还原问题现场。
- 故意写深度递归（如无终止条件的斐波那契），运行时加
-Xss256k缩小栈空间，快速复现StackOverflowError； - 启动时加
-XX:+PrintConcurrentLocks -XX:+PrintGCDetails，配合jstack抓取线程快照，识别死锁或长阻塞线程栈帧位置； - 查看
jstack输出中每个线程的java.lang.Thread.State和最深几行方法调用，判断是否卡在IO、锁或无限循环。
方法区（元空间）溢出实操
JDK 8+ 元空间替代永久代，但仍有泄漏风险。
- 使用
javassist或byte-buddy在运行时反复生成新类（如动态代理类），不卸载； - 加
-XX:MaxMetaspaceSize=32m -XX:+PrintGCDetails，观察Metaspace区使用量增长及是否触发Metadata GC； - 当出现
java.lang.OutOfMemoryError: Metaspace时，用jstat -gcmetacapacity查元空间容量，再用jmap -clstats统计已加载类数量与ClassLoader分布。
GC行为对比实验
同一应用，换不同垃圾收集器看效果差异。
- 默认使用
Parallel GC：观察jstat -gc中YGCT和FGCT比例，通常 Minor GC 频繁但快，Full GC 少而重； - 切换为
G1 GC：加-XX:+UseG1GC -Xmx2g -XX:MaxGCPauseMillis=200，再压测，对比G1 Evacuation Pause日志频率与停顿时间； - 对比关键指标：吞吐量（
jstat -gc的GC时间占比）、平均停顿（jstat的GCT/GC商值）、晋升失败（jstat中OU突增且伴随Full GC）。
实战的核心是闭环：设参数 → 做动作 → 看日志/工具输出 → 分析现象 → 调整假设 → 再验证。不依赖“应该”，只信“确实发生了什么”。
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
