盘点WebLogic常见报错，运维人员该如何快速排查并解决？

内存溢出错误

这是Java应用中最经典也最令人头疼的问题之一,在WebLogic中同样普遍。

现象：
日志中出现 java.lang.OutOfMemoryError: Java heap space 或 java.lang.OutOfMemoryError: PermGen space（JDK 7及更早版本）或 Metaspace（JDK 8及更新版本）。

常见原因：

1. JVM内存配置不足： 分配给WebLogic Server的堆内存（Heap Memory）或永久代/元空间（PermGen/Metaspace）过小，无法满足应用程序的正常运行需求。
2. 内存泄漏： 应用程序代码存在缺陷，导致对象无法被垃圾回收器回收，随着时间的推移，可用内存越来越少。
3. 对象创建过度： 代码逻辑不合理，在短时间内创建了大量对象，超出了垃圾回收的处理能力。

解决方案：

1. 调整JVM参数： 登录WebLogic控制台，在“服务器”->“配置”->“服务器启动”->“参数”中，调整JVM内存设置，增加堆大小：-Xms2048m -Xmx4096m，对于JDK 8，调整元空间大小：-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m。
2. 分析内存快照： 当发生OutOfMemoryError时，可以配置JVM在内存溢出时自动生成堆转储文件（Heap Dump），参数为 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump，然后使用Memory Analyzer Tool (MAT)、JProfiler等工具分析该文件，定位内存泄漏的根源。
3. 代码审查与优化： 检查代码中是否存在未关闭的资源（如数据库连接、文件流）或无限循环创建对象的情况。

---

数据库连接池问题

WebLogic通过JDBC连接池管理数据库连接,连接池配置不当或应用代码问题是引发数据库相关错误的常见原因。

现象：
日志中出现 Cannot get a connection, pool exhausted、Waiting for connection to become available 或 Connection has already been closed 等错误。

常见原因：

1. 连接泄漏： 应用程序从连接池获取连接后，没有在finally块中正确关闭（connection.close()），导致连接被长期占用，最终耗尽。
2. 连接池容量过小： 最大连接数设置过低，无法满足高并发场景下的连接请求。
3. 数据库性能瓶颈： 数据库服务器响应缓慢，导致连接长时间被占用，无法及时返回池中。

解决方案：

1. 启用连接泄漏检测： 在WebLogic控制台的JDBC数据源配置中，启用“连接泄漏分析”并设置合适的“非活动连接超时时间”，WebLogic会自动检测并回收疑似泄漏的连接，并在日志中报警。
2. 调整连接池参数： 根据应用负载和数据库能力，合理设置“初始容量”、“最大容量”和“容量增长”等参数。
3. 代码审查： 确保所有数据库操作都遵循“获取-使用-关闭”的模式，并使用try-with-resources语句或finally块来保证连接的关闭。

---

线程阻塞错误

当某个线程执行时间过长,超过了WebLogic设定的阈值，就会报告线程阻塞警告。

现象：
日志中频繁出现 <Warning> <WebLogicServer> <BEA-000337> <[STUCK] ExecuteThread: 'XX' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "XXX" seconds working on the request "...">。

常见原因：

1. 长时间运行的业务逻辑： 某些业务操作本身就很耗时，如大数据量查询、复杂计算等。
2. 死锁： 多个线程互相等待对方持有的锁，导致都无法继续执行。
3. 外部资源调用缓慢： 应用调用外部Web服务、数据库或文件系统时，由于网络延迟或对方系统性能问题导致等待时间过长。

解决方案：

1. 生成线程转储： 使用 kill -3 <pid> (Linux/Unix) 或 Ctrl+Break (Windows) 命令，或通过WebLogic控制台的“线程转储”功能，生成线程快照，分析快照中处于 RUNNABLE 状态但长时间未变的线程，查看其调用栈，定位问题代码。
2. 优化代码逻辑： 对于耗时的操作，考虑进行异步化处理或分批执行，优化数据库查询，减少不必要的锁竞争。
3. 调整超时设置： 如果确认某些长时间操作是业务必需的，可以在服务器配置中适当调高“阻塞线程最大时间”（StuckThreadMaxTime），但这通常是治标不治本的方法。

为了更直观地对比,以下是一个简化的常见报错排查速查表：

错误现象	可能原因	快速排查方向
OutOfMemoryError	JVM内存不足、内存泄漏	调整JVM内存参数，生成堆转储文件分析
Pool Exhausted	连接泄漏、连接池容量小	检查应用代码，调整数据源连接池配置
Server in FAILED 状态	端口冲突、配置文件错误	查看启动日志，检查端口占用和config.xml
[STUCK] Thread 警告	长时间任务、死锁、外部调用慢	生成线程转储进行分析，优化代码逻辑

---

相关问答FAQs

问题1：如何有效预防WebLogic的常见报错，而不是等问题出现后再去解决？

解答： 预防远胜于治疗，建立完善的监控体系，使用WLDF（WebLogic Diagnostic Framework）或第三方监控工具（如Prometheus、Zabbix）对JVM内存、线程池状态、JDBC连接池使用率、服务器响应时间等关键指标进行实时监控和告警，进行充分的容量规划和压力测试，确保系统在峰值负载下依然稳定，加强代码审查，特别是对资源管理、并发控制和数据库访问逻辑的审查，保持WebLogic版本和JDK版本的更新，及时安装官方补丁，修复已知的安全漏洞和性能缺陷。

问题2：WebLogic的关键日志文件有哪些，它们分别记录什么信息？

解答： WebLogic的日志系统非常关键，主要有以下几种：

1. 这是最重要的日志文件，位于每个服务器实例的目录下（如 <DOMAIN_HOME>/servers/<SERVER_NAME>/logs/），它记录了服务器的所有生命周期事件、部署信息、应用错误、JDBC警告、安全审计等几乎所有详细信息，是排查问题的首要依据。
2. 该文件捕获了服务器进程的标准输出（stdout）和标准错误（stderr），通常包含JVM启动参数、OutOfMemoryError时生成的hs_err_pid*.log文件路径等信息。
3. Access Log (access.log)： 默认位于服务器目录下，记录了所有通过HTTP协议访问WebLogic服务器的请求信息，包括客户端IP、请求时间、请求URL、HTTP状态码、响应大小等，主要用于访问分析和安全审计。
4. 位于域目录下（<DOMAIN_HOME>/），记录了整个域级别的管理事件和消息，如管理服务器的启动、关闭、配置变更等。