消耗100％CPU時間的Glassfish灰熊線程

我們最近注意到一個問題，即我們的Glassfish服務器在成功運行幾個小時後突然以100％掛住其中一個CPU。在此期間，我們的應用程序無響應。重新啓動後，問題最終會再次發生（通常在幾個小時後）。消耗100％CPU時間的Glassfish灰熊線程

我跑這個命令，看看有什麼線程正在做的：

的asadmin產生JVM的報告--type =線程

輸出結果中，一個線程顯得非常可疑（消費數量級更多的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上運行的Glassfish 3.1.2.2 R2企業版。任何有關發展的見解都將受到高度讚賞。

來源

2012-12-11 Jeff

您正在使用哪個jdk？ –

我們正在使用JDK版本1.6.0_37。 – Jeff

這可能是JDK問題。在Grizzly中，針對空選擇器旋轉問題提供了一種解決方法，該問題發生在使用早期版本的JDK 6的Linux上，但它不適用於Windows。

我可以要求您創建Glassfish或灰熊問題嗎？

來源

2012-12-12 10:34:36 alexey

好的。我已經提交了Glassfish issue 19444：http://java.net/jira/browse/GLASSFISH-19444 – Jeff

消耗100％CPU時間的Glassfish灰熊線程

回答

相關問題