Question

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

我运行此命令以查看线程正在做什么：

asadmin generate-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。任何有关正在发生的事情的见解都受到高度赞赏。

Answer 1

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

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

Glassfish灰熊线程占用100％的CPU时间

1 个答案: