Websphere Liberty Profile在AIX 7.1 TL3启用dropins后CPU占100%求助

针对你在AIX 7.1 TL3上启用Liberty dropins后CPU直接拉满的问题，结合你已经尝试的禁用轮询、调整JVM堆、排查GC这些操作，我给你几个更针对性的排查方向：

1. 先排查Dropins目录本身的异常 #

AIX的文件系统特性和Linux有差异，先确认dropins目录有没有潜在问题：

• 检查目录下是不是堆了大量文件/子目录（比如上千个jar/war），哪怕禁用了轮询，初始扫描阶段也可能因为递归遍历触发高CPU
• 有没有符号链接循环，或者不小心把dropins指向了根目录这类超大目录——Liberty的扫描逻辑可能陷入无限递归
• 执行ls -lR /path/to/your-liberty-server/dropins查看目录结构，有没有异常的文件或链接

另外可以做个快速验证：手动把dropins里的应用移到apps目录，直接在server.xml里配置<application>部署，看CPU能不能降下来。如果能，那问题肯定出在dropins的扫描逻辑上。

2. 开启Liberty的dropins专项跟踪日志 #

Liberty有专门的跟踪组件可以记录dropins扫描的细节，在server.xml里添加这段配置：

<logging traceSpecification="com.ibm.ws.app.manager.dropins.*=all:com.ibm.ws.app.manager.internal.*=all" />

启动服务器后去logs/trace.log里找线索：

• 有没有频繁触发扫描循环（比如每隔几毫秒就扫一次，哪怕你设了pollingRate=-1）
• 有没有某个文件/目录的扫描耗时特别长
• 有没有未捕获的异常（哪怕GC正常，循环里的异常重试也会持续占用CPU）

3. 用AIX工具定位占用CPU的线程 #

AIX上有专门的工具能精准定位到哪个线程在消耗CPU：

1. 用ps -ef | grep java找到Liberty的进程ID（PID）
2. 执行top -H -p <PID>查看该进程下的线程CPU占比，找到最高的那个线程ID（注意是十进制）
3. 将十进制线程ID转成十六进制：printf "%x\n" <线程ID>
4. 用jstack <PID>导出线程栈，在栈中搜索刚才转换的十六进制ID，看这个线程在执行什么逻辑
   • 如果栈里全是com.ibm.ws.app.manager.dropins相关的代码，那就是扫描逻辑的问题
   • 如果是java.io.File.listFiles这类本地方法，那大概率是AIX文件系统的性能坑

4. 确认禁用dropins轮询的配置真的生效了 #

有时候配置写错位置会导致不生效，你可以再核对下：
正确的配置是在server.xml里添加：

<applicationManager autoExpand="false" pollingRate="-1"/>

或者通过JVM参数配置：

-Dcom.ibm.ws.app.manager.dropins.pollingRate=-1

不确定配置是否加载的话，可以执行server dump <你的服务器名>生成dump包，解压后查看server.xml和jvm.options里的配置是否正确生效。

5. 排查AIX系统层面的兼容性问题 #

AIX 7.1 TL3算是比较老的版本了，虽然Liberty 19.0.0.x支持，但可能存在底层兼容性bug：

• 给AIX更新到TL3的最新Service Pack，修复文件系统或系统调用的已知bug
• 检查Liberty使用的IBM SDK版本，确保是Java 8的最新补丁（Liberty 19.0.0.x推荐IBM SDK 8 SR6 FP10及以上），旧JVM在AIX上处理文件事件可能有性能问题

如果以上步骤还是找不到原因，建议收集这些信息提交给IBM支持：

• Liberty的console.log和trace.log
• AIX的svmon -P <PID>输出（内存使用详情）
• jstack和jmap -heap <PID>的输出
• top -H -p <PID>的线程CPU统计

内容的提问来源于stack exchange，提问作者Zlatko Treščec