Java内存溢出（OutOfMemoryError）本质是JVM申请内存时触达系统资源上限，既受JVM参数（如-Xmx、-XX:MaxMetaspaceSize、-Xss、-XX:MaxDirectMemorySize）约束，也直接受限于物理内存、OS架构（32位进程地址空间≤3.5GB）、swap、内核预留及cgroup限额；非堆内存（元空间、线程栈、直接内存等）同样消耗真实物理内存，需结合free、ps、pmap和GC日志从系统与JVM双视角协同诊断。
Java内存溢出（OutOfMemoryError）不是单纯由Java代码写错导致的，而是JVM申请内存时触达了系统层面的资源上限——这个上限既受JVM参数约束，也直接受限于操作系统可用的物理内存及架构限制。
堆内存上限不能超过物理内存的合理比例
JVM堆空间（-Xms / -Xmx）默认按物理内存动态计算：初始堆（-Xms）约为物理内存的1/64，最大堆（-Xmx）约为1/4。例如一台16GB物理内存的服务器，JVM默认最大堆约4GB。若强行设置 -Xmx12g，而系统剩余内存不足或被其他进程占用，JVM启动可能失败；即使启动成功，运行中也可能因系统无法分配连续物理页，触发OOM（如 java.lang.OutOfMemoryError: Java heap space）。
- 32位操作系统下，单个进程用户态地址空间通常不超过3GB～3.5GB，因此无论物理内存多大，JVM堆很难突破此边界
- 64位系统无此硬性限制，但实际可用仍取决于：空闲物理内存 + swap空间 + 内核内存预留 + 其他进程占用
- Linux中可通过
ulimit -v（虚拟内存上限）和ulimit -m（物理内存上限）进一步限制JVM进程，超限会直接被OS kill
非堆内存也消耗物理资源
除了堆，JVM还需为以下区域分配真实物理内存：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
元空间（Metaspace）：替代了旧版的永久代（PermGen），存放类元数据；其大小受限于
-XX:MaxMetaspaceSize，但底层使用的是本地内存（native memory），同样计入进程RSS（Resident Set Size） -
线程栈：每个线程默认分配1MB栈空间（-Xss），1000个线程就占用约1GB物理内存；过多线程易触发
OutOfMemoryError: unable to create new native thread -
直接内存（Direct Buffer）：通过
ByteBuffer.allocateDirect()分配，绕过堆、不受-Xmx控制，但受-XX:MaxDirectMemorySize约束，超限抛出OutOfMemoryError: Direct buffer memory - JIT编译代码、GC内部结构、NIO通道等也持续占用本地内存
操作系统内存压力会间接引发Java OOM
即使JVM参数总和未超物理内存，以下情况仍会导致OOM：
立即学习“Java免费学习笔记（深入）”；
- 系统整体内存紧张时，Linux内核可能触发OOM Killer，优先杀死RSS最高的进程——JVM常首当其冲
- 频繁GC导致CPU与内存带宽争抢，加剧延迟，使应用响应变慢甚至假死，表现为“看似有内存却报OOM”
- 容器环境（如Docker）中，若未配置
--memory限制，JVM可能误读宿主机内存，按1/4策略申请过大堆，实际在容器内超出cgroup限额而被OOMKilled
诊断与调优的关键落点
排查时不能只看JVM参数，必须结合系统视角：
- 用
free -h、cat /proc/meminfo查看真实可用内存 - 用
ps -o pid,rss,vsz,comm -C java或pmap -x <pid>观察Java进程实际内存占用（RSS） - 启用
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps分析GC是否频繁、老年代是否持续增长 - 生产环境建议固定堆大小：
-Xms=Xmx，避免动态伸缩带来的系统抖动 - 容器部署务必显式设置
-Xmx和-XX:MaxMetaspaceSize，并匹配容器内存limit
