Java 1.8安全點超時

Question

我似乎遇到了JVM在幾個小時後無限期地嘗試到達安全點的情況。但是，如果我使用-F選項來執行jstack，它看起來會脫離等待並繼續執行。

jdk1.8.0_45 /斌/ jstack -F 39924> a.out的

我使用jdk1.8.0_45在CentOS

我的問題是：

我）看來，當從jstack發送中斷時，JVM可以從這個安全點無限期的等待中走出來。沒有jstack，它怎麼會不出來。有沒有我可以用來避免無限期等待的jvm選項。

ii）我可以得到導致問題的線程的更明確的線程轉儲。來自安全點日誌的輸出似乎不準確。

我正在使用的選項是：。

-server 
-XX:+AggressiveOpts 
-XX:+UseG1GC 
-XX:+UnlockExperimentalVMOptions 
-XX:G1MixedGCLiveThresholdPercent=85 
-XX:InitiatingHeapOccupancyPercent=30 
-XX:G1HeapWastePercent=5 
-XX:MaxGCPauseMillis=1000 
-XX:G1HeapRegionSize=4M 
-XX:+PrintGC 
-XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps 
-XX:+PrintGCDateStamps 
-XX:+UnlockExperimentalVMOptions 
-XX:G1LogLevel=finest 
-Xmx6000m 
-Xdebug 
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=999 
-XX:+SafepointTimeout 
-XX:+UnlockDiagnosticVMOptions 
-XX:SafepointTimeoutDelay=20000 
-XX:+PrintSafepointStatistics 
-XX:PrintSafepointStatisticsCount=1 

的還原點日誌

vmop     [threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count 
17771.115: G1IncCollectionPause    [  170   0    0 ]  [  0  0  0  0  8 ] 0 

vmop     [threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count 
17771.125: RevokeBias      [  170   1    2 ]  [  0  0  0  0  0 ] 0 

vmop     [threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count 
17771.127: RevokeBias      [  170   1    1 ]  [  0  0  0  0  0 ] 0 

vmop     [threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count 
17771.131: RevokeBias      [  170   1    2 ]  [  0  0  0  0  0 ] 0 

vmop     [threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count 
17771.955: RevokeBias      [  169   0    2 ]  [  0  0  0  0  0 ] 0 

vmop     [threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count 
17772.160: BulkRevokeBias     [  171   0    2 ]  [  0  0  0  0  0 ] 0 

vmop     [threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count 
17772.352: RevokeBias      [  170   1    3 ]  [  0  0  0  0  0 ] 0 

vmop     [threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count 
17773.596: RevokeBias      [  169   0    1 ]  [  0  0  0  0  0 ] 0 

# SafepointSynchronize::begin: Timeout detected: 
# SafepointSynchronize::begin: Timed out while spinning to reach a safepoint. 
# SafepointSynchronize::begin: Threads which did not reach the safepoint: 
# "Thread-14" #115 prio=5 os_prio=0 tid=0x00007f20c8029000 nid=0x9cd0 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE 
# SafepointSynchronize::begin: (End of list) 

的jstack中斷之後就是我從還原點日誌

vmop     [threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count 
17779.826: G1IncCollectionPause    [  169   1    1 ]  [3315603  03315603  0  8 ] 1 

vmop     [threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count 
21095.439: RevokeBias      [  169   2    13 ]  [  0  0  0  0  0 ] 0 

vmop     [threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count 
21095.439: RevokeBias      [  169   1    2 ]  [  0  0  0  0  0 ] 0 

vmop     [threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count 
21095.441: RevokeBias      [  184   3    4 ]  [  0  0  3  0  1 ] 0 

vmop     [threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count 
21095.447: RevokeBias      [  190   0    2 ]  [  0  0  4  0  2 ] 0 

Answer 1

看既然你都能夠通過中斷虛擬機來解決這個問題，並你在CentOS上的問題讓我想起了this kernel bug。

線程列出了以下受影響的版本（假設標準內核）：

• RHEL 6（和CentOS 6，和SL 6）：6.0-6.5都不錯。 6.6是壞的。 6.6.z 是不錯的。
• RHEL 7（和CentOS 7和SL 7）：7.1是BAD。截至昨天。 還沒有出現7.x修正。
• RHEL 5（和CentOS 5和 SL 5）：所有版本都很好（包括5.11）。