jvm参数问题通常一启动就暴露或规律性崩溃，代码bug则在特定逻辑路径下才触发；前者表现为启动失败、oom/stackoverflowerror等，后者具条件性且堆栈顶层为业务包名。
直接看现象和发生时机——代码 bug 通常在特定逻辑路径下才触发，而 JVM 参数问题往往一启动就暴露，或在资源压力下规律性崩溃。
看启动阶段是否失败
如果程序根本跑不起来，报错带 OutOfMemoryError、StackOverflowError、Could not create Java Virtual Machine 等字样，基本是 JVM 参数配置不当：
- -Xmx 设置过大（超过物理内存或容器限制），导致 JVM 启动失败
- -Xss 过小，多线程场景下刚创建几个线程就抛 StackOverflowError
- 元空间参数缺失（如 -XX:MaxMetaspaceSize 未设），动态类加载多时触发 Metaspace OOM
这类错误与业务代码无关，换台机器、改小堆大小或调大栈空间就能恢复。
看异常是否随负载/数据变化
代码 bug 往往有“条件性”：
- 空指针（NullPointerException）只在某个字段为 null 时出现
- 数组越界（ArrayIndexOutOfBoundsException）只在特定输入下触发
- 数字格式异常（NumberFormatException）只在解析非法字符串时抛出
而 JVM 问题更“稳定”：同一份代码，在相同参数下，只要并发数上升、对象分配加快、运行时间变长，就会准时复现 GC 频繁、Full GC 暴增、响应延迟飙升，甚至卡死。
用工具交叉验证
别靠猜，用 JDK 自带工具快速划界：
- 启动后立刻执行 jps 能看到进程 → JVM 已正常启动，问题大概率在代码层
- 用 jstat -gc
查看 GC 统计：YGC 次数突增、老年代持续上涨 → 堆参数或内存泄漏嫌疑大 - 用 jmap -histo
看对象分布：某类实例数量异常高（如 String、HashMap$Node）→ 可能是代码逻辑导致对象堆积 - 加 -XX:+HeapDumpOnOutOfMemoryError 后触发 dump → 用 MAT 分析：若大量业务对象滞留无法回收 → 代码级内存泄漏；若只是缓存/静态集合撑满 → 参数+设计双问题
检查日志和堆栈源头
关键看异常堆栈最顶层的类名和方法：
- 以 java.lang. 开头（如 java.lang.OutOfMemoryError、java.lang.StackOverflowError）→ JVM 层面资源耗尽，优先查参数
- 以项目包名开头（如 com.example.service.UserService.login）→ 代码执行中抛出，比如 NullPointerException、IllegalArgumentException → 重点审逻辑和入参校验
- 堆栈里出现 sun.misc.Launcher 或 java.util.concurrent 底层类但无业务类 → 很可能是线程模型或 JVM 并发参数（如 -XX:ParallelGCThreads）不匹配
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
