场景题：怎么分析 JVM 当前的内存占用情况？OOM 后怎么分析？

在 Java 应用中，分析 JVM 内存占用情况和排查 OOM（Out Of Memory）问题是常见的任务。以下是详细的排查思路和解决方案：

---

1. 分析 JVM 当前的内存占用情况

1.1 使用 JVM 内置工具

• jstat：
  • 使用 jstat -gc <pid> 查看堆内存的各个区域（Eden、Survivor、Old Gen）的使用情况。
  • 示例：jstat -gc 12345
    输出结果包括各个区域的内存使用量、GC 次数、GC 时间等。
• jmap：
  • 使用 jmap -heap <pid> 查看堆内存的详细分配情况。
  • 使用 jmap -histo <pid> 查看堆内存中对象的分布情况，按对象类型统计实例数量和占用内存大小。
• jcmd：
  • 使用 jcmd <pid> GC.heap_info 查看堆内存的详细信息。
  • 使用 jcmd <pid> VM.native_memory 查看 JVM 的本地内存使用情况。

1.2 使用可视化工具

• JConsole：
  • JConsole 是 JDK 自带的图形化工具，可以实时监控 JVM 的内存、线程、类加载等情况。
  • 启动命令：jconsole
• VisualVM：
  • VisualVM 是更强大的工具，支持插件扩展，可以分析堆内存、线程、CPU 使用情况等。
  • 启动命令：jvisualvm
• Java Mission Control (JMC)：
  • JMC 是 JDK 自带的性能分析工具，支持实时监控和历史数据分析。

1.3 使用命令行参数

• 启用 GC 日志：
  • 在 JVM 启动参数中添加 GC 日志记录，便于分析内存使用和 GC 行为。

    -Xloggc:/path/to/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps

• 启用堆内存溢出时生成 Dump 文件：
  • 在 JVM 启动参数中添加以下配置，当发生 OOM 时自动生成堆内存快照（Heap Dump）。

    -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump

---

2. OOM 后的分析方法

2.1 获取堆内存快照（Heap Dump）

• 自动生成：
  • 如果已经配置了 -XX:+HeapDumpOnOutOfMemoryError，OOM 时会自动生成 Heap Dump 文件。
• 手动生成：
  • 使用 jmap 命令手动生成 Heap Dump：

    jmap -dump:format=b,file=/path/to/heapdump.hprof <pid>

2.2 分析 Heap Dump

• 使用工具分析：
  • Eclipse MAT (Memory Analyzer Tool)：
    • MAT 是一款强大的堆内存分析工具，可以快速定位内存泄漏和大对象。
    • 打开 Heap Dump 文件后，MAT 会生成内存泄漏报告，并展示占用内存最多的对象。
  • VisualVM：
    • VisualVM 也可以加载 Heap Dump 文件进行分析。
  • JProfiler：
    • JProfiler 是一款商业工具，支持更深入的内存和性能分析。
• 分析步骤：
  1. 打开 Heap Dump 文件。
  2. 查看内存占用最大的对象。
  3. 检查对象的引用链，找到导致内存泄漏的根源。
  4. 结合业务代码，分析是否有未释放的资源或缓存。

2.3 分析 GC 日志

• 如果启用了 GC 日志，可以通过分析 GC 日志来了解内存使用和 GC 行为。
• 关注点：
  • Full GC 的频率和耗时。
  • 老年代（Old Gen）的使用情况。
  • 是否有内存碎片化问题。

2.4 检查代码

• 内存泄漏：
  • 检查是否有未关闭的资源（如数据库连接、文件流等）。
  • 检查是否有静态集合类（如 HashMap、List）持续增长未清理。
• 大对象分配：
  • 检查是否有大对象频繁创建（如大数组、大字符串）。
• 缓存问题：
  • 检查缓存是否设置了合理的过期时间或大小限制。

---

3. 常见 OOM 场景及解决方案

3.1 Java Heap Space OOM

• 原因：
  • 堆内存不足，对象无法分配。
• 解决方案：
  • 增加堆内存大小（-Xmx 参数）。
  • 优化代码，减少对象创建。
  • 检查是否有内存泄漏。

3.2 Metaspace OOM

• 原因：
  • 元空间（Metaspace）不足，类加载器加载的类过多。
• 解决方案：
  • 增加 Metaspace 大小（-XX:MaxMetaspaceSize 参数）。
  • 检查是否有动态生成类（如反射、动态代理）导致类加载过多。

3.3 Direct Buffer Memory OOM

• 原因：
  • 直接内存（Direct Buffer）不足。
• 解决方案：
  • 增加直接内存大小（-XX:MaxDirectMemorySize 参数）。
  • 检查是否有未释放的 Direct Buffer。

3.4 Unable to Create New Native Thread OOM

• 原因：
  • 线程数超过系统限制。
• 解决方案：
  • 减少线程数，使用线程池。
  • 调整系统限制（如 ulimit -u）。

3.5 GC Overhead Limit Exceeded OOM

• 原因：
  • GC 耗时过长，无法有效回收内存。
• 解决方案：
  • 优化代码，减少对象创建。
  • 调整 GC 参数（如使用 G1 GC）。

---

4. 总结

• 分析 JVM 内存占用：
  • 使用 jstat、jmap、jcmd 等工具实时监控内存使用情况。
  • 使用 JConsole、VisualVM 等可视化工具进行深入分析。
• OOM 后的分析：
  • 获取 Heap Dump 文件，使用 MAT 或 VisualVM 分析内存泄漏。
  • 检查 GC 日志，分析内存使用和 GC 行为。
  • 结合代码，定位问题根源并优化。

通过以上方法，可以有效分析和解决 JVM 内存占用过高或 OOM 的问题。