GlassFish 4.1 CPU占用率飙升问题咨询及诱因排查请求

问题背景 #

一套部署在AWS EC2实例上、基于GlassFish运行的ERP系统已稳定运行4-5年，期间未进行任何更新或软件变更，但一个多月前开始出现故障：单个CPU核心持续处于100%占用状态。需排查故障原因，并解释为何长期稳定运行后突然出现该问题。

抓取到的线程Dump日志 #

"Thread "http-listener-3-kernel(1) SelectorRunner" thread-id: 58 thread-state: RUNNABLE
 at: sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
 at: sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
 at: sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
 at: sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
 at: sun.nio.ch.SelectorImpl.selectNow(SelectorImpl.java:105)
 at: org.glassfish.grizzly.nio.DefaultSelectorHandler.select(DefaultSelectorHandler.java:114)
 at: org.glassfish.grizzly.nio.SelectorRunner.doSelect(SelectorRunner.java:338)
 at: org.glassfish.grizzly.nio.SelectorRunner.run(SelectorRunner.java:278)
 at: org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
 at: org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
 at: java.lang.Thread.run(Thread.java:748)"

故障分析与突发原因解释 #

从线程Dump看，问题线程是GlassFish Grizzly NIO框架的SelectorRunner，负责处理HTTP监听端口的IO事件。正常情况下epollWait是阻塞调用，不会持续占用CPU，但当前线程却导致单核心满载，结合系统长期稳定后突发故障的情况，可能的原因包括：

• AWS底层环境变更：EC2宿主机可能发生硬件故障、资源争用，或是AWS对虚拟化层、内核进行了静默更新。这些底层变化可能导致EPoll机制异常，使Selector无法正常阻塞，进入忙等循环。
• 连接资源堆积：长期运行中积累了大量半开连接、无效连接（比如客户端异常断开未释放连接）。这些无效连接会让Selector不断轮询对应文件描述符，若处理逻辑存在缺陷，就会引发无限循环。
• JVM资源耗尽：当系统文件描述符达到上限时，EPoll调用出现异常，导致selectNow()（非阻塞调用）每次立即返回，线程陷入持续循环，占满CPU核心。
• 网络规则变更：EC2安全组、NACL规则被误操作修改，或AWS自动调整网络配置，导致网络数据包异常，触发Selector的异常轮询逻辑。

内容的提问来源于stack exchange，提问作者user2950508