java OOM

在 Linux 环境下，Java 应用程序遇到 Out Of Memory（OOM）错误是比较常见的情况。以下是一些用于排查 Java OOM 错误的常见技巧：

使用 top、htop 或 ps 等命令查看 Java 进程的内存使用情况。关注 RES（Resident Set Size）和 VIRT（Virtual Memory Size）等字段，以了解进程实际使用的物理内存和虚拟内存。

如果应用程序启用了垃圾回收（GC）日志，可以查看 GC 日志以了解 GC 情况，特别是在发生 OOM 之前是否有异常的 GC 情况。

jvm heap

当发生 OOM 错误时，生成一个 Heap Dump 文件，并使用工具如 Eclipse Memory Analyzer（MAT）或 VisualVM 进行分析。Heap Dump 包含了 Java 堆的详细信息，帮助定位内存泄漏或大对象。

dump文件详情

使用 jstack 命令生成线程 Dump，以了解 Java 进程中的线程情况。有时 OOM 错误可能与线程死锁有关。

使用 Java Profiler 工具（如 YourKit, VisualVM, JProfiler）对 Java 进程进行性能分析，以查看内存使用模式、对象分配情况等。

如果应用程序的内存需求超过当前堆大小，考虑调整 Java 堆大小。通过修改 Java 启动参数中的 -Xms 和 -Xmx 来设置初始堆大小和最大堆大小。

审查应用程序的代码，查找潜在的资源泄漏，确保及时释放资源。特别关注数据库连接、文件流、线程等资源的关闭。

在一些情况下，升级 Java 版本可能会解决一些内存管理问题，因为新版本通常会修复一些已知的问题。

使用内存分析工具（如 Eclipse MAT、VisualVM、YourKit）进行实时分析，以查找内存泄漏和大对象。

如果应用程序使用的是 CMS（Concurrent Mark-Sweep）垃圾回收器，考虑切换到 G1（Garbage-First）垃圾回收器，因为 G1 在处理大堆和避免 Full GC 方面表现更好。

Linux 的 Out Of Memory（OOM）机制是用来处理系统内存耗尽的情况的。当系统内存不足以满足所有运行中进程的需求时，Linux 内核会触发 OOM 来尝试解决这个问题。在 OOM 发生时，系统会选择一个进程并终止它，释放其占用的内存，以便为其他进程提供足够的内存空间。

选择要终止的进程的具体策略是由 OOM Killer 来执行的。以下是影响 OOM Killer 选择进程的一些关键因素：

OOM Score： 每个进程都有一个称为 OOM Score 的值，它表示进程被终止的优先级。OOM Score 越高的进程越容易被选择。OOM Killer 主要会选择 OOM Score 最高的进程。

oom_adj/oom_score_adj： 进程可以通过设置 oom_adj 或 oom_score_adj 来影响其 OOM Score。负的值表示增加 OOM Score，正的值表示降低 OOM Score。这可以让进程在 OOM 发生时更有或更少可能被选择。

进程重要性： 有些进程被认为是系统的关键组成部分，它们的 OOM Score 可能会受到保护，不容易被终止。这些进程通常与系统的基本功能或稳定性相关。

内存使用情况： OOM Killer 还会考虑每个进程当前的内存使用情况。如果一个进程占用了大量内存，有可能成为 OOM Killer 的目标。

总的来说，OOM Killer 的设计目标是尽量保护系统的稳定性，同时释放足够的内存以防止系统崩溃。选择要终止的进程是一个复杂的决策过程，涉及到多个因素。