2

我们最近注意到一个问题，我们的 Glassifish 服务器在成功运行几个小时后，突然将其中一个 CPU 固定在 100%。在此期间，我们的应用程序变得无响应。重新启动后，问题最终会再次发生（通常在几个小时后）。

我运行这个命令来查看线程在做什么：

asadmin 生成-jvm-report --type=thread

在结果输出中，一个线程看起来非常可疑（消耗的 CPU 时间比任何其他线程都多几个数量级）：

线程执行信息：

Thread "Grizzly-kernel-thread(1)" thread-id: 27 thread-state: RUNNABLE Running in native
    at: sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(Native Method)
    at: sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(WindowsSelectorImpl.java:273)
    at: sun.nio.ch.WindowsSelectorImpl$SubSelector.access$400(WindowsSelectorImpl.java:255)
    at: sun.nio.ch.WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:136)
    at: sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
    at: sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
    at: com.sun.grizzly.TCPSelectorHandler.select(TCPSelectorHandler.java:513)
    at: com.sun.grizzly.SelectorHandlerRunner.doSelect(SelectorHandlerRunner.java:190)
    at: com.sun.grizzly.SelectorHandlerRunner.run(SelectorHandlerRunner.java:132)
    at: java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at: java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at: java.lang.Thread.run(Thread.java:662)

线程同步统计：

此线程被阻止的次数（进入/重新进入监视器）：4,520

此线程等待通知的次数（即处于 WAITING 或 TIMED_WAITING 状态）：0

此线程的总 CPU 时间：2,753 秒 703,125,000 纳秒。

此线程的用户级 CPU 时间：2,753 秒 703,125,000 纳秒。

此线程当前持有或请求的对象监视器：[]

此线程持有的可拥有的同步器（例如 ReentrantLock 和 ReentrantReadWriteLock）：[]

我们在 Windows Server 2008 R2 Enterprise 上运行 Glassfish 3.1.2.2。任何对正在发生的事情的见解都将受到高度赞赏。

4

1 回答 1

1

可能是JDK问题。在 Grizzly 中，有一个空选择器旋转问题的解决方法，该问题发生在具有早期版本 JDK 6 的 Linux 上。但它不适用于 Windows。

我可以请您创建 Glassfish 或 Grizzly 问题吗？

于 2012-12-12T10:34:36.747 回答