Ubuntu下WebLogic内存溢出的定位与解决
一、快速定位与取证
- 确认溢出类型：查看 AdminServer.log 与 server.log，定位是 Java heap space、Metaspace、还是 perm gen（旧版本）等，并留意是否伴随 Full GC 频繁。日志路径通常为：…/user_projects/domains/<你的域>/servers/AdminServer/logs。
- 抓取堆转储：在 WebLogic 管理控制台将“Heap Dump”开关打开，或在发生 OOM 时由 JVM 自动生成 .hprof 文件；使用 Eclipse MAT 或 VisualVM 分析占用最高的对象与引用链。
- 实时监控：在 Ubuntu 上使用 top/htop 观察 RES、%CPU；必要时用 jstat -gc 观察 YGC/FGC 次数与耗时，配合 jstack 检查是否存在线程阻塞与长事务。
- 区分系统层 OOM：用 dmesg | tail -n 50 检查 Out of memory: Kill process，必要时调整 oom_score_adj 避免关键进程被系统终止。
以上步骤能快速判断是应用内存泄漏、JVM 参数不足，还是系统资源瓶颈。
二、JVM堆与元空间的参数建议
- 设置堆大小：在域目录 bin/setDomainEnv.sh 中调整 JAVA_OPTS，将 -Xms 与 -Xmx 设为相同值（如 -Xms4g -Xmx4g），避免运行期扩缩堆带来的抖动；仅在物理内存充足且容器/系统限制允许时再上调。
- 元空间配置：JDK 8 及以后使用 -XX:MetaspaceSize 与 -XX:MaxMetaspaceSize（如 -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m）；避免无限制导致系统内存被耗尽。
- 旧版本注意：JDK 7 及更早使用 -XX:PermSize / -XX:MaxPermSize（如 -XX:MaxPermSize=512m），部署期类加载多时可适当增大。
- GC 选择：优先使用 G1 GC（如 -XX:+UseG1GC），并配合 -XX:MaxGCPauseMillis、-XX:G1HeapRegionSize 等按业务延迟与吞吐目标微调。
- 触发条件：发生 OutOfMemoryError 时自动生成堆转储，便于后续分析（如 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/weblogic/dumps）。
示例（放在 setDomainEnv.sh 的 JAVA_OPTS 中，注意放在已存在的 JAVA_OPTS 引用之后）：
-Xms4g -Xmx4g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/weblogic/dumps
上述做法覆盖堆、元空间与 GC 的关键调优点，并结合堆转储进行根因分析。
三、应用侧常见根因与修复
- 缓存与会话膨胀：如 **Hibernate 一级缓存（StatefulPersistenceContext）**在 Session 未及时 evict/clear 时持续增长，易触发 Java heap space。建议在批量/定时任务中分批处理、及时清理会话，或优化查询与对象生命周期管理。
- 线程与任务堆积：大量 ExecuteThread 或 Quartz Worker 持有对象且长时间不释放，会导致堆被占满。应限制并发、缩短事务、避免在请求线程中执行大对象聚合与导出，必要时增加超时与熔断。
- 资源未释放：未关闭的 JDBC Connection/Statement/ResultSet、大文件流、缓存未设上限等，都会造成对象无法回收。审计代码、引入连接池监控与泄漏检测（如 JDBC 泄漏、对象生命周期探针）。
- 部署期 OOM：应用启动阶段类加载多，旧版本 PermGen 不足会报错，适当增大 -XX:MaxPermSize 可缓解（JDK 8+ 请使用 Metaspace 方案）。
以上问题在生产中较为常见，需结合堆转储与线程栈定位具体对象与代码路径。
四、Ubuntu系统层面的保障
- 资源与监控：用 top/htop、vmstat、iostat、sar 持续观察 CPU、内存、I/O；必要时用 cgroups 限制 WebLogic 最大内存占用，避免影响同机其他服务。
- OOM Killer 调优：为 WebLogic 进程设置更不易被杀死的 oom_score_adj（如调低数值），降低系统在内存紧张时误杀中间件的概率。
- 内存压缩与交换：启用 zram/zswap 提升低内存场景下的稳定性；合理规划 swap 分区，避免频繁换页导致性能劣化。
- 文件句柄与内核参数：适度提升 fs.file-max 等内核参数，避免因句柄不足引发间接故障。
这些系统级措施能减少外部因素对 WebLogic 稳定性的影响。
五、可操作的处置流程
- 紧急止血：先保留现场（日志、堆转储、线程栈），再重启受影响的 Managed Server；必要时滚动重启，避免业务大面积中断。
- 参数回滚与验证：将 -Xms/-Xmx 先恢复到稳定基线，确认问题是否与参数变更相关；再按“堆→元空间→GC”的顺序逐步调优。
- 压测与回归：在预发环境用接近生产的负载进行压测，观察 FGC、Heap/Meta 使用曲线与业务 RT，确认优化有效。
- 持续监控与告警：在 WebLogic Console / WLST / JMX 上建立内存与 GC 指标监控，结合 Prometheus + Grafana 设置阈值告警，做到问题早发现、早处置。
以上流程兼顾应急与根治，能显著降低复发概率。