统信UOS中Java OOM需先据日志后缀精准判定类型：Java heap space（堆不足）、Metaspace（类元数据过多）、Direct buffer memory（直接内存超限）或unable to create new native thread（线程数超限），再分场景处置。
统信UOS系统中Java程序运行时抛出OutOfMemoryError（OOM），表明JVM内存分配失败，服务已处于不可用或即将崩溃状态，必须立即定位内存耗尽区域并调整配置或修复代码。
确认OOM类型和触发位置
查看Java进程标准错误输出或日志文件，找到完整的异常堆栈。重点识别java.lang.OutOfMemoryError:后紧跟的关键词：
若为Java heap space，说明堆内存不足；
若为Metaspace，说明类元数据占用过多；
立即学习“Java免费学习笔记（深入）”；
若为Direct buffer memory，说明NIO直接内存超限；
若为unable to create new native thread，说明系统线程数已达上限——此时需检查/proc/sys/kernel/threads-max和ulimit -u，而非调JVM参数。
注意：不要仅凭现象猜测，【必须以日志中明确出现的错误后缀为准】，否则后续所有优化都可能南辕北辙。
堆内存溢出（Java heap space）的应急与根治
第一步：立即添加JVM参数启用OOM现场保留 → 启动命令中加入：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/java-oom/
第二步：确保目标路径存在且Java进程有写权限，执行：sudo mkdir -p /var/log/java-oom && sudo chown youruser:youruser /var/log/java-oom
第三步：重启应用，等待下一次OOM自动触发堆转储（.hprof文件）。这一步不能跳过，没有堆快照就无法判断是内存泄漏还是单纯配置过小。
第四步：用MAT（Memory Analyzer Tool）打开.hprof文件，查看Dominator Tree，重点关注Retained Heap最大的前3个对象类型。如果发现大量HashMap.Entry、ArrayList或自定义DTO实例长期驻留，大概率是静态集合未清理或缓存未设上限。
第五步：若确认无泄漏，仅因业务增长导致，可安全调大堆内存：将启动脚本中的-Xmx从-Xmx1g改为-Xmx2g，但【-Xms与-Xmx必须设为相同值，例如-Xms2g -Xmx2g】，避免运行时频繁扩容引发GC风暴。
元空间溢出（Metaspace）的处理方法
方法一：临时扩大元空间上限（适用于调试阶段）
在Java启动参数中添加：-XX:MaxMetaspaceSize=512m。若仍报错，可逐步加到1g，但不建议超过2g。
方法二：定位动态类爆炸源头
执行jstat -class $(pgrep -f 'YourApp.jar') 1000持续观察Loaded列是否持续上涨。若每秒新增数个类，检查是否使用了CGLIB、Groovy、Spring Boot DevTools或热加载框架——统信UOS桌面环境默认启用Wayland，某些热重载插件在此环境下会反复加载类而不卸载。
方法三：强制类卸载（仅当确认无引用残留时）
追加参数：-XX:+UseG1GC -XX:+ClassUnloadingWithConcurrentMark，G1垃圾收集器配合此选项可在Full GC时尝试卸载无用类。
直接内存与线程资源耗尽的快速处置
若日志显示Direct buffer memory，立即检查代码中是否滥用ByteBuffer.allocateDirect()。统信UOS默认未限制cgroup内存，但JVM对直接内存有独立限额，默认等于-Xmx值。需显式设置：-XX:MaxDirectMemorySize=1024m，数值应≥最大预期直接内存用量。
若报unable to create new native thread，先运行cat /proc/$(pgrep -f 'YourApp.jar')/status | grep Threads看当前线程数。再执行ulimit -u查看用户级线程上限。若显示1024，而你的线程池corePoolSize设为200、maxPoolSize为800，再叠加定时任务、Netty EventLoop等，极易突破。此时需修改/etc/security/limits.conf，为运行用户添加：youruser soft nproc 65535和youruser hard nproc 65535，然后重新登录终端生效。
