前阵子有个朋友从容器环境切回传统中间件部署一套老系统电话里跟我吐槽现在还有人用WebLogic吗我回他说你不是正在用吗。这句玩笑背后其实是个很现实的问题WebLogic在国内的银行、证券、制造、物流这些行业里存量系统的占比远比很多人想象中高。我这些年陆陆续续部署过几十套WebLogic环境从10.3.6一路装到14c中间踩过的坑攒下来确实不少。这篇不打算复述官方文档而是从一次相对完整的部署经历出发把版本选择、环境准备、安装方式、Domain创建、应用部署、安全加固和故障排查这几个环节里真正值得注意的事串起来。无论你是第一次接触WebLogic的新手还是部署过几台但总在某个环节卡壳的运维这篇应该都能让你少走点弯路。1. 为什么还在用WebLogic版本选型与真实生态很多人不理解都什么年代了还在用商业中间件。这个问题的答案其实很简单不是想用是不得不用。很多核心业务系统在十多年前选型时就绑定了WebLogic这些年业务模型、事务逻辑、定制化API全都跑在这套容器上迁移成本远高于购买许可的成本。1.1 WebLogic在中间件市场的真实位置Oracle WebLogic Server是Java EE规范层面的重型应用服务器支持EJB、JMS、JTA、分布式事务、集群、Session复制等全套企业级能力。和Tomcat这种轻量级Servlet容器相比它多了完整的事务管理、消息中间件、集群会话保持和运维控制台。对单机小应用来说Tomcat够用但对需要强一致性事务、跨节点Session、集中式管理的系统来说WebLogic依然是很多企业架构师的首选。从版本分布看目前生产环境里最常见的还是下面几个大版本WebLogic版本官方支持的JDK常见部署场景我的实际感受10.3.6JDK 1.6 / 1.7老系统、长周期维护项目存量最大问题也最多12.1.3JDK 1.7 / 1.8中等规模业务系统稳定但功能较老12.2.1.4JDK 1.8 / 11新老交替的主力版本推荐新项目优先选14.1.1JDK 8 / 11新建系统部署少兼容性需要验证1.2 版本选型时容易忽略的几件事选版本不能只看WebLogic本身的版本号要看三个方面第一JDK版本。WebLogic和JDK的匹配关系是硬约束装错了轻则启动报错重则运行期出现各种莫名奇妙的类加载异常。比如10.3.6官方推荐JDK 1.6/1.7硬让它跑在JDK 1.8上某些并发场景下会出现线程池异常。第二应用的编译目标。很多老应用是用JDK 1.6编译的强行放到高版本WebLogic上跑虽然大部分情况没问题但遇到反射、字节码增强这类操作时很容易因为模块化限制或者类库变更出问题。第三补丁支持周期。10.3.6的官方补丁支持早已结束如果系统必须跑在这个版本上至少需要在前面加一层访问控制不能裸奔在公网。1.3 什么情况下真的需要用WebLogic如果你在做技术选型我的建议是没有外部约束时Spring Boot加内嵌Tomcat的方案开发效率更高也更容易招人维护。但如果你遇到下面这些情况WebLogic依然是合理选择系统原本就跑在WebLogic上存在大量EJB或JMS调用甲方技术规范里明确指定了WebLogic业务需要强一致性的JTA分布式事务且不希望引入额外中间件项目要求集群部署、Session复制、多机热备需要一个成熟的控制台统一管理2. 安装前必须先对齐的三件事JDK匹配、系统账号与目录规划正式执行安装文件之前有大量准备工作要做。省略这一步直接去敲命令后面大概率要返工。我见过太多在安装过程中突然停下来查为什么这里选不了JDK的人基本都是环境准备阶段偷了懒。2.1 JDK版本匹配是硬指标WebLogic的安装程序本身是用Java写的所以安装机器上必须先有一个可用的JDK。这里有个关键细节安装程序和目标运行环境可以共用同一个JDK但版本必须落在WebLogic官方兼容矩阵里。以12.2.1.4为例官方支持Oracle JDK 8update 171及以上和JDK 11。我个人的建议是生产环境用Oracle JDK 8尽量选较新的update版本。不要图新鲜用JDK 11除非你的应用已经完整验证过。虽然官方说支持但不少老程序的字节码操作和ClassLoader行为在JDK 11上表现不一样。验证JDK是否可用就两行命令java -version javac -version注意输出里要看到的是厂商和版本号比如java version 1.8.0_202。如果你装的是OpenJDK也没问题但建议先在测试环境跑一遍应用确认没有依赖Oracle JDK的私有接口。2.2 创建专用系统账号别用root跑这是我在生产环境踩过最深刻的坑之一。用root安装WebLogic安装过程一路畅通但启动后的Managed Server进程可能会以root权限运行。一旦应用出问题被利用整个机器就沦陷了。正确的做法是创建一个专用账号groupadd weblogic useradd -g weblogic -d /u01/weblogic weblogic后续所有安装和部署都用这个账号操作。数据目录和日志目录单独建例如mkdir -p /u01/weblogic mkdir -p /u01/weblogic/domain mkdir -p /u01/weblogic/applogs chown -R weblogic:weblogic /u01/weblogic磁盘规划也要提前想好。WebLogic本身安装目录大概占用2-3GB但Domain目录会随运行时间膨胀因为日志、临时文件、部署的快照都会写进去。建议给Domain挂一个独立分区或者至少预留50GB以上空间。2.3 安装包的选择通用jar包还是开发版Oracle官方提供两种安装介质一种是可以跨平台执行的jar包如fmw_12.2.1.4.0_wls.jar另一种是针对特定平台的二进制安装包。我个人建议用通用jar包因为它在Linux和Windows上统一用java -jar触发安装行为一致也好做静默安装脚本。下载时注意文件名里的版本标识10.3.6时代的包名和12c以后的包名规则不一样。到了12.2.1.x以后Oracle把WebLogic、Coherence等组件打包在Fusion Middleware介质里安装时可以选择要装哪些组件。提示如果你所在的网络环境无法直接从Oracle官网下载可以去Oracle Software Delivery Cloud找历史版本但一定先确认版本与JDK的匹配关系再下载。3. 两种安装路线图形化向导与静默安装各踩过的坑WebLogic安装程序有两种启动方式对应两种使用场景。新手和图形界面环境可以走图形向导生产环境或者虚拟机没有显示器的场景必须用静默安装。两条路线我都走过多遍各自说点实用的。3.1 图形化安装的完整流程图形化安装适合本机有显示环境、只装一两台的场景。执行java -jar fmw_12.2.1.4.0_wls.jar安装程序会弹出一个Java Swing界面核心步骤就几步选择安装目录、选择安装组件、填写Oracle Home位置、选JDK。有几个地方容易踩坑第一组件选择。默认会勾选WebLogic Server和Oracle Coherence。如果系统用不到Coherence可以不勾减少安装面积和补丁范围。第二Oracle Home目录和WebLogic Home目录是有区别的。Oracle Home是Fusion Middleware产品的顶层目录WebLogic Home在其下。很多人搞混这两个路径导致后面WLST脚本连接时报错。安装完成后默认会创建一个$ORACLE_HOME/wlserver目录这就是WebLogic的Home。后续启动脚本、Deployer命令都会从这里找类库。3.2 静默安装才是生产环境的正确姿势生产环境往往没有图形界面甚至在安全加固后连X11转发都禁了。这时候用响应文件做静默安装是最可靠的。响应文件是一个properties格式的文本核心内容如下[ENGINE] Response File Version1.0.0.0.0 [GENERIC] ORACLE_HOME/u01/weblogic/install_home INSTALL_TYPEWebLogic Server DECLINE_SECURITY_UPDATEStrue SECURITY_UPDATES_VIA_MYORACLESUPPORTfalse几个参数说明一下ORACLE_HOME是安装的绝对路径INSTALL_TYPE可以指定完整安装或自定义安装DECLINE_SECURITY_UPDATES和SECURITY_UPDATES_VIA_MYORACLESUPPORT是用于跳过Oracle在线注册流程的。不写这两个参数安装程序会卡在更新设置那一步。执行静默安装的命令是java -jar fmw_12.2.1.4.0_wls.jar -silent -responseFile /path/to/wls.rsp -invPtrLoc /path/to/oraInst.loc-invPtrLoc指定无效列表文件位置Linux下这个文件通常放在/etc/oraInst.loc如果没有可以手动生成内容类似inventory_loc/u01/weblogic/oraInventory inst_groupweblogic静默安装的坑主要出在权限和路径。oraInventory目录如果没有写权限安装程序会直接报错退出日志里通常只有一句Failed to create inventory。所以安装前一定先确认的是执行用户对/u01/weblogic全链路有读写权限。3.3 安装完成后的目录结构详解装完后你会看到类似这样的目录结构/u01/weblogic/install_home/ ├── domain-registry.xml ├── logs ├── oracle_common ├── oraInst.loc ├── uninstall ├── wlserver │ ├── common │ ├── integration │ ├── modules │ ├── server │ └── uninstall └── wlsdeploy真正关键的是wlserver目录。这里藏着全套WebLogic运行时包括startWebLogic.sh、WLST脚本库、默认模板文件。startWebLogic.sh是启动Domain的入口脚本但注意它不在安装目录根下而是在每个具体Domain的bin目录里。安装包本身没有提供任何可运行的Server实例装完只是搭好了引擎必须进入下一步——创建Domain。4. 创建Domain比安装本身更容易出错的关键环节WebLogic和Tomcat一个很大的区别是它引入了Domain域的概念。简单理解Domain就是一个独立的管理单元包含一个AdminServer管理服务器和若干个ManagedServer受管服务器。所有配置都由AdminServer集中管理应用可以部署到任意ManagedServer上。这个概念搞不清楚后面集群配置、部署目标选择都会一头雾水。4.1 用配置向导创建DomainWebLogic安装包里自带Configuration Wizard。在图形环境里直接执行$ORACLE_HOME/oracle_common/common/bin/config.sh向导会引导你选择或创建模板填写管理员账号密码、Domain名称、端口号等信息。默认生成的AdminServer监听地址是0.0.0.0端口7001。生产环境建议把监听地址改成具体IP端口也改掉减少被扫描到的概率。有一点特别容易忽略向导里会问你要不要创建管理服务器启动后自动启动受管服务器。在很多企业环境里为了统一启停管理会把这个选项设成视情况手动启动。如果你选中了自动启动每次重启AdminServer时它会尝试拉起所有受管服务器在资源不足的机器上反而会导致启动风暴。4.2 用WLST脚本创建Domain一劳永逸如果让我选一种方式我会选WLSTWebLogic Scripting Tool。它支持脚本化创建Domain一次编写多套环境复现。对于要部署多套环境的项目来说这不只是省事更关键的是保证每套环境的配置完全一致。下面这个脚本是我常用的保存成create_domain.py执行# create_domain.py readTemplate(/u01/weblogic/install_home/wlserver/common/templates/wls/wls.jar) # 修改域名 set(Name, MyDomain) # 修改 AdminServer 监听地址和端口 cd(/Servers/AdminServer) set(ListenAddress, 0.0.0.0) set(ListenPort, 7001) # 修改 JVM 参数 cd(/Servers/AdminServer/ServerStart/MyDomain) set(Arguments, -Xms2048m -Xmx2048m -XX:MaxPermSize512m) # 设置管理员账号 cd(/Security/base_domain/User/weblogic) cmo.setPassword(YourStrongPassw0rd) # 写回并关闭模板 setOption(CreateStartMenu, false) setOption(ServerStartMode, prod) writeDomain(/u01/weblogic/domain/MyDomain) closeTemplate() exit()执行命令$ORACLE_HOME/oracle_common/common/bin/wlst.sh create_domain.py脚本里的ServerStartMode我建议设成prod。Developer模式下某些安全检查会放宽生产环境必须用prod模式。4.3 Domain目录结构知道文件放哪才能准确排错创建完成后Domain目录是这个样子的目录/文件作用出现问题时的排查方向bin/startWebLogic.shAdminServer启动脚本看启动日志bin/setDomainEnv.sh环境变量设置入口JVM参数不对先查这里config/config.xml所有核心配置的汇总Server、集群、数据源都在里面config/jdbc数据源配置目录数据源连不上先看这里servers/AdminServer/logsAdminServer日志目录启动失败先翻*.log和*.outsecurity/demoidentity.jks演示用的身份密钥库安全扫描会盯这里lib可以放公共类库和JDBC驱动类冲突从这个目录下手排查启动Domain只需要执行cd /u01/weblogic/domain/MyDomain/bin ./startWebLogic.sh启动成功后在浏览器访问http://IP:7001/console就能看到WebLogic控制台登录页。4.4 JVM参数配置不当会埋下定时炸弹Domain创建时就要把JVM参数想清楚。AdminServer本身承担管理职责内存给1-2GB足够ManagedServer要跑业务应用堆内存得根据应用实际负载来定。常见的一个配置误区是所有人都在setDomainEnv.sh里改USER_MEM_ARGS但改完后又发现ManagedServer和AdminServer的JVM参数被一视同仁了。我的做法是分别定义变量# setDomainEnv.sh 末尾追加 if [ ${SERVER_NAME} AdminServer ]; then USER_MEM_ARGS-Xms1024m -Xmx1024m -XX:MaxMetaspaceSize512m elif [ ${SERVER_NAME} ManagedServer_1 ]; then USER_MEM_ARGS-Xms4096m -Xmx4096m -XX:MaxMetaspaceSize1024m fi export USER_MEM_ARGS注意12.2.1之后的版本默认使用JDK 8和元空间MaxPermSize已经不再适用设置无效还可能造成误导。10.3.6及更老的版本才需要MaxPermSize参数。5. 应用部署的三种方式控制台、Deployer命令行与WLST脚本Domain创建好、AdminServer跑起来接下来就是部署应用。很多教程只讲控制台点几下但实际项目里自动化部署才是刚需。我把三种方式都走一遍对比一下各自适合的场景和坑。5.1 控制台部署最直观但最不适合批量操作登录控制台后导航到部署页面点击安装选择WAR包或EAR包然后按向导一步步完成。整个操作很简单但有几个点容易出错第一部署目标的选择。如果选了AdministrationServer应用就只在AdminServer上跑一般不建议这样。正确做法是选中业务项目的ManagedServer。第二部署阶段选择。可以选择将部署上载到管理服务器或将此部署作为生产模式暂存。如果不理解这两个选项的差异建议选择默认值等跑熟了再改。第三应用名称不能和已有部署冲突否则控制台会让你强制覆盖容易误操作。控制台部署适合单机调试和临时上线一旦涉及几十套环境这种方式效率太低。5.2 Deployer命令行批量部署的利器WebLogic自带了一个完善的部署工具weblogic.Deployer。通过命令行调用可以完成部署、更新、卸载、重部署等操作。基本用法如下java -cp $ORACLE_HOME/wlserver/server/lib/weblogic.jar weblogic.Deployer \ -adminurl t3://10.0.0.10:7001 \ -username weblogic \ -password YourPassword \ -deploy \ -name order-service \ -targets ManagedServer_1 \ /u01/apps/order-service.war各参数含义-deploy表示执行部署操作-name指定应用名-targets指定目标服务器。执行成功后命令行会返回Deployment completed successfully。部署完成后再上线新的WAR包不需要先undeploy再redeploy直接用-redeploy即可java -cp $ORACLE_HOME/wlserver/server/lib/weblogic.jar weblogic.Deployer \ -adminurl t3://10.0.0.10:7001 \ -username weblogic \ -password YourPassword \ -redeploy \ -name order-service \ -source /u01/apps/order-service.war这里有个常见坑直接使用-deploy部署一个同名应用会报already exists错误。所以自动化脚本里要先判断应用是否已存在存在就-redeploy不存在才-deploy。5.3 WLST脚本化部署把它嵌进CI/CD流程比Deployer更进一步的是用WLST脚本做部署好处是可以把连接、部署、健康检查、日志收集串成一个完整流程。下面是我常用的一段# deploy_app.py username weblogic password YourPassword url t3://10.0.0.10:7001 connect(username, password, url) deployment order-service app_path /u01/apps/order-service.war targets ManagedServer_1 if deploymentExists(deployment): print(Deployment exists, redeploying...) deploy(appNamedeployment, pathapp_path, targetstargets, stageModestage) else: print(Creating new deployment...) deploy(appNamedeployment, pathapp_path, targetstargets, stageModestage) disconnect() exit()执行$ORACLE_HOME/oracle_common/common/bin/wlst.sh deploy_app.pyWLST里deploy函数如果检测到同名的应用不会直接覆盖所以before执行时用deploymentExists做判断。stageModestage表示将部署包复制到每个目标服务器的指定暂存目录这种方式在网络传输上有一定开销但能保证各节点文件一致性。还有一种external_stage模式适用于从共享存储批量部署的场景多节点集群下更省带宽。5.4 部署完成后的健康检查清单无论用哪种方式部署完成后我都建议做一次系统验证查看部署状态确认应用处于活动状态而不是准备就绪或失败使用curl -I http://IP:7001/order-service或访问一个真实的业务接口确认HTTP返回200查看ManagedServer的日志确认没有类加载异常或者数据源连接失败的报错如果应用有JMX暴露顺手查一下内存和线程池指标6. WebLogic安全加固关于漏洞、默认账号和jks那点事聊WebLogic绕不开安全问题。WebLogic历史上爆过的高危漏洞不少被列为重点排查对象也不算冤。对这一块我认为正确的态度不是回避而是搞清楚它为什么会成为目标然后踏踏实实做加固。6.1 为什么WebLogic经常成为攻击目标原因有两点第一WebLogic通常承载核心业务系统价值高第二它的攻击面确实不小既有基于HTTP的Web服务也有基于T3和IIOP协议的远程调用入口。T3协议是WebLogic集群和各节点间通信的协议但历史上多个反序列化漏洞都出在这个协议上。网上那些针对WebLogic的攻击工具大多瞄准的是T3协议处理流程里的过滤缺陷。攻击者要利用这些漏洞在大多数场景下需要能直接访问7001端口或者T3端口。所以安全加固的核心思路就是减少暴露面、升级修补漏洞、降低端口可访问性。6.2 安全基线配置清单结合这么多年的实操经验下面这几项是我认为每个WebLogic服务器都必须落实的加固项具体操作原因说明防火墙限制只对外暴露必要的HTTP端口管理端口和T3端口限制来源IPWebLogic管理端口被公网访问是大忌修改默认账号密码部署完成后立即修改weblogic管理员密码禁止使用弱口令默认账号是爆破重点更换demoidentity.jks生产环境用keytool重新生成身份密钥库并更新配置默认密钥库密码公开存在被仿冒风险关闭不需要的协议如果应用不用T3则在config.xml中关闭T3协议通道减少攻击面升级补丁保持Oracle官方季度补丁更新节奏已知漏洞只能靠补丁封堵6.3 demoidentity.jks这个高频检查项这些年WebLogic被扫出问题的记录里demoidentity.jks出现频率非常高。这是WebLogic默认生成的一个身份密钥库用于SSL握手和节点间通信。问题在于它的密码是公开的默认密码是DemoIdentityKeyStore很多系统上线后压根没改过。安全扫描工具一探测到这个文件的存在和默认密码就直接判成高风险。处理方法是用keytool重新生成一个密钥库并把路径和密码更新到Domain配置里。大概流程如下keytool -genkeypair -alias demoidentity -keyalg RSA -keysize 2048 \ -dname CNweblogic-node, OUIT, OCompany, LCity, STState, CCN \ -validity 3650 \ -keystore /u01/weblogic/domain/MyDomain/security/demoidentity.jks \ -storepass YourNewStrongPassword生成后还需要在WebLogic控制台里更新SSL配置中的私钥别名和密码否则重启后SSL相关操作会报错。做完这一步再跑安全扫描就不会在这个点上被卡住。6.4 补丁更新是最容易拖后腿的一环安全加固方案定了但真正落地的难点在补丁。Oracle的季度补丁更新需要企业账号才能下载但即使拿到补丁往生产环境上打也需要停机窗口。我见过不少团队把补丁更新一拖再拖最后拖成了上了新闻的事件。如果短期无法停机打补丁至少在访问控制层面做好补救在服务器前面加WAF或安全组白名单限制T3协议来源IP对WebLogic管理端口做强访问控制。这些措施不能根治漏洞但能把实际风险降到可控范围。注意不要在WebLogic配置里留-Dcom.sun.management.jmxremote等远程管理参数尤其不要监听非本地端口否则等于开放了一个不需要认证的监控入口。7. 运行时故障排查我从实际项目里总结的排错清单部署这件事最花时间的环节往往不是安装和部署本身而是部署完后的各种运行时问题。我把自己在项目里排查过的WebLogic故障做了个分类挑了几个高频、有代表性的场景说下排查思路。7.1 内存溢出两种表现两种对策WebLogic的Java进程内存溢出分两种堆内存溢出和元空间溢出。堆内存溢出OutOfMemoryError: Java heap space的典型表现是应用响应越来越慢最后直接无法处理请求日志里频繁出现OutOfMemoryError。排查时先用jmap或jstat看堆使用曲线如果发现GC频繁且回收不掉再考虑是内存泄漏还是堆开小了。我遇到最多的情况其实是连接池缓存导致的对象无法回收处理方式是先压测定位泄漏点然后增加堆内存同时调大Xms和Xmx到一致避免运行期动态扩缩带来的停顿。元空间溢出在JDK 8及以后主要表现是OutOfMemoryError: Metaspace。排查时先看-XX:MaxMetaspaceSize是否给了足够空间。如果应用用了大量动态代理或者反射元空间增长会很快。建议初始设置512MB以上再通过监控曲线做调整。7.2 启动失败日志文件才是最好的线索WebLogic启动失败时第一反应不应该是去猜而是看日志。AdminServer的启动日志在Domain/servers/AdminServer/logs下关注三个文件文件作用AdminServer.logServer运行日志包含启动过程中的错误AdminServer.outnohup输出文件记录了控制台的标准输出access.logHTTP访问日志可以用来排查端口监听是否成功一条典型的启动失败报错长这样JDK is incompatible with this version of WebLogic Server or the JVM mode is incorrect看到这句话基本可以锁定JDK版本不匹配。还有一类报错是端口被占用BEA-000365: Server failed to listen on port 7001排查方法是netstat或lsof看7001被谁占了大概率是上一个Server进程没彻底杀死。WebLogic的进程是一组Java进程杀的时候用kill -9之前先确认父进程和子进程都退出否则会留下一堆僵死进程。7.3 类加载冲突NoSuchMethodError的元凶WebLogic部署和Tomcat有一个明显的不同点WebLogic的类加载体系更严格父子委派的层级关系更复杂。应用里如果依赖了和WebLogic自带的第三方库比如Log4j、Saxon、JAXP实现等版本不一致的类往往会出现NoSuchMethodError或者ClassCastException而且报错位置千奇百怪。排查思路是在Domain的lib目录下检查是否有冲突的jar包或者在应用的WEB-INF/lib里搜一下重复类。也可以用-Dweblogic.debug.DebugClassLoadingtrue开启类加载调试日志启动时从日志里定位实际加载的jar来源。我遇到过最典型的一个案例应用里带了老版本的xercesImpl.jarWebLogic自带的XML解析器版本更新结果程序一跑就报XML解析错误。最后排除掉应用里的老jar才恢复正常。这个经验让我养成了一个习惯部署应用前先对比一下应用依赖和WebLogic自带模块的版本清单。7.4 时区与编码问题看似不起眼影响很直接WebLogic部署在Linux上时时区默认跟随系统。如果系统的/etc/localtime没有配置成业务需要的时区日志时间戳、数据库写入时间都可能偏差8小时。检查命令date -R如果时区不对要么改系统时区要么在setDomainEnv.sh里给JVM加参数JAVA_OPTIONS${JAVA_OPTIONS} -Duser.timezoneAsia/Shanghai export JAVA_OPTIONS编码问题同样隐蔽。WebLogic默认文件编码依赖操作系统的locale如果系统locale是en_US.UTF-8而业务数据是GBK控制台和日志里看到的中文就会变成乱码。建议启动参数里显式设置JAVA_OPTIONS${JAVA_OPTIONS} -Dfile.encodingUTF-8 export JAVA_OPTIONS不要小看这两行参数遇到过一次系统间乱码导致的对账不平排查了两天才定位到是时区加编码的双重问题。7.5 一个完整的排查过程示例最后分享一个真实的排查案例。当时有个同事反馈应用部署后首次访问很慢大概要等30秒才有响应。查了一圈数据库没问题网络没问题最后打开AdminServer日志发现启动时有一条警告WARNING: Low Memory. The server will enter low memory state...再一看AdminServer和ManagedServer在同一台机器上AdminServer把4GB堆用掉了2GBManagedServer启动时堆也只给了2GB机器总内存8GBOS还要留一部分内存压力自然大。解决方式是给机器加到16GBAdminServer堆降到1GBManagedServer堆调到4GB并且在启动顺序上先启动ManagedServer。调整后首次访问慢的问题彻底消失。这个案例很有代表性很多WebLogic性能问题不是应用代码的问题而是资源分配不合理导致的。写在最后关于WebLogic部署的几个长期习惯部署WebLogic这件事装一遍不算会能在出了问题后快速定位才算真正掌握。我个人的经验是从第一次部署开始就坚持做运维文档把每套环境的版本、JDK路径、JVM参数、部署包清单、安全加固记录都写清楚。出问题时这份文档的价值无法估量。平时做巡检时也建议多关注这几个指标堆内存使用率、GC频率、连接池活跃连接数、日志里WARN和ERROR的数量。WebLogic的控制台和JMX都能提供这些指标不用额外装监控组件先把基本功用起来。如果这篇内容对你有些帮助或者你部署时遇到了不一样的问题欢迎在评论区聊聊具体报错现象。毕竟中间件这套东西很多时候就是靠一条一条踩坑记录堆起来的经验。