centos weblogic内存溢出解决

一、获取应用进程号
首先需要定位WebLogic应用的运行进程，使用ps -ef | grep 应用名命令过滤出目标进程的PID（进程ID），这是后续分析的基础。

二、查看JVM堆内存与GC情况
通过jstat -gcutil PID 1000 10命令（间隔1秒输出10次），监控堆内存各区域（Eden、Survivor、老年代）的使用率及GC次数、耗时。重点关注老年代使用率（若接近100%）和Full GC频率（若过高），这些是内存溢出的典型信号。

三、开启OOM堆快照
为定位内存泄漏点，在WebLogic启动脚本（如setDomainEnv.sh）中添加以下JVM参数，当发生OutOfMemoryError时自动生成堆转储文件：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/heapdump.hprof
堆转储文件记录了内存中所有对象的状态，是分析泄漏根源的关键。

四、捕获线程栈信息
使用jstack -l PID > /path/to/jstack.txt命令获取线程栈快照，分析是否有线程阻塞（如等待数据库连接、死锁）或异常线程（如长时间处于RUNNABLE状态的线程）。重点关注STUCK线程（可通过WebLogic控制台“监控->线程”查看），其堆栈信息能指向内存消耗的代码路径。

五、分析内存分配与泄漏点
使用jmap -heap PID > /path/to/jmapHeap.txt命令查看JVM内存分配详情（如堆大小、各代占比、类加载数量），确认是否符合应用需求。更推荐使用Eclipse Memory Analyzer (MAT)或VisualVM工具打开堆转储文件，通过“Dominator Tree”（支配树）功能找出占用内存最多的对象（如java.util.HashMap、自定义集合类），结合线程栈分析其引用链，定位泄漏的具体代码（如未关闭的数据库连接、缓存的无限增长）。

六、调整JVM内存参数
根据应用负载和服务器资源（物理内存），合理配置JVM参数（以setDomainEnv.sh为例）：

• 堆内存：初始堆（-Xms）与最大堆（-Xmx）设置为相同值（如-Xms2048m -Xmx2048m），避免堆内存动态扩展带来的性能损耗；
• 新生代：通过-XX:NewRatio设置新生代与老年代比例（如-XX:NewRatio=2表示新生代占堆的1/3），适合短生命周期对象多的应用；
• 永久代/元空间：Java 8前用-XX:PermSize/-XX:MaxPermSize（如-XX:PermSize=512m -XX:MaxPermSize=512m），Java 8后用-XX:MetaspaceSize/-XX:MaxMetaspaceSize（如-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m），避免类元数据溢出；
• 垃圾回收器：推荐使用CMS（-XX:+UseConcMarkSweepGC）或G1（-XX:+UseG1GC）回收器，减少Full GC停顿时间（如CMS需添加-XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection优化碎片整理）。

七、优化应用程序代码
内存泄漏的根本原因多在代码层面，需重点检查：

• 资源未释放：数据库连接、IO流、Session等未在finally块中关闭；
• 缓存滥用：静态集合（如static HashMap）无限存储对象，未设置过期时间或大小上限；
• 循环引用：对象间相互引用（如父子对象互相持有引用），导致GC无法回收；
• 大对象分配：一次性加载大量数据到内存（如全表查询未分页），超过堆容量。

八、增加系统资源与监控

• 扩展物理内存：若应用确实需要更多内存，升级服务器RAM（如从8GB增至16GB），并相应调整JVM堆大小；
• 配置监控告警：使用WebLogic自带的“诊断框架”或第三方工具（如Prometheus+Granafa），监控JVM内存使用率、GC频率、线程数等指标，设置阈值告警（如内存使用率达80%时触发邮件通知），提前发现问题。

九、定期维护与测试

• 代码审查：定期检查代码中的内存管理逻辑，避免引入新的泄漏点；
• 性能测试：使用JMeter等工具模拟高负载场景，验证JVM参数配置的合理性（如逐步增加并发用户数，观察内存使用趋势）；
• 日志分析：定期查看server.log中的OutOfMemoryError记录，总结常见泄漏模式（如某页面访问频繁导致内存增长），针对性优化。