玻璃鱼灰线程消耗100%的CPU时间

Question

最近我们注意到一个问题，在成功运行几个小时后，我们的Glassifish服务器突然将其中一个CPU锁定为100%。在这段时间里，我们的应用程序变得没有响应能力。重新启动后，问题最终会再次发生(通常在几个小时之后)。

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

asadmin生成-jvm-报告类型=线程

在结果输出中，有一个线程看起来非常可疑(比任何其他线程消耗的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次

此线程等待通知的次数(即处于等待状态或TIMED_WAITING状态)：0

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

这个线程的用户级CPU时间: 2,753秒，703,125,000纳秒.

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

这个线程拥有的可拥有的同步器(例如ReentrantLock和ReentrantReadWriteLock)：[]

我们正在Windows 2008 R2企业上运行Glassfish 3.1.2.2。任何对正在发生的事情的洞察力都会受到高度赞赏。

Answer 1

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

我可以让你创作玻璃鱼或灰熊的作品吗？