Question

最近我们刚刚注意到我们的许多服务器偶尔和突然（没有明显的逐渐降级）锁定以下堆栈（所有其他的主题是BLOCKED，IN_NATIVE或IN_VM）（在我们的代码启动时被截断），使用jstack获得 - ˚F

Thread 18334: (state = IN_JAVA)
 - java.util.Calendar.updateTime() @bci=1, line=2469 (Compiled frame; information may be imprecise)
 - java.util.Calendar.getTimeInMillis() @bci=8, line=1088 (Compiled frame)
(truncated)

失败似乎是在一个完整的gc之后不久发生的，并且top -H -p显示有两个线程，一个似乎是上面的线程，另一个是gc线程或jitc，按照以下输出of pstack（不是VMThread :: run（））：

Thread 331 (Thread 0x7f59641bc700 (LWP 16461)):
#0  0x00007f63f9ed0ef8 in SafepointSynchronize::begin() () from /usr/java/jdk1.6.0_33/jre/lib/amd64/server/libjvm.so
#1  0x00007f63f9fbab7c in VMThread::loop() () from /usr/java/jdk1.6.0_33/jre/lib/amd64/server/libjvm.so
#2  0x00007f63f9fba68e in VMThread::run() () from /usr/java/jdk1.6.0_33/jre/lib/amd64/server/libjvm.so
#3  0x00007f63f9e5e7af in java_start(Thread*) () from /usr/java/jdk1.6.0_33/jre/lib/amd64/server/libjvm.so
#4  0x00000035bb807851 in start_thread () from /lib64/libpthread.so.0
#5  0x00000035bb4e811d in clone () from /lib64/libc.so.6

有没有人知道为什么这可能已经开始发生？

我们在CentOS版本5.7和6.3上使用jdk1.6.0_33在具有24个核心（12个物理）的服务器上。

这里有一些堆栈，我们的代码被截断了：

Thread 22561: (state = IN_VM)
 - java.lang.String.toLowerCase(java.util.Locale) @bci=428, line=2782 (Compiled frame; information may be imprecise)
 - java.lang.String.toLowerCase() @bci=4, line=2847 (Compiled frame)
(truncated)

Thread 22562: (state = IN_VM)
 - java.util.HashMap.put(java.lang.Object, java.lang.Object) @bci=20, line=403 (Compiled frame; information may be imprecise)
 - java.util.HashSet.add(java.lang.Object) @bci=8, line=200 (Compiled frame)
(truncated)

Thread 22558: (state = BLOCKED)
 - sun.nio.ch.EPollSelectorImpl.wakeup() @bci=6, line=173 (Compiled frame)
 - org.mortbay.io.nio.SelectorManager$SelectSet.wakeup() @bci=10, line=706 (Compiled frame)
 - org.mortbay.io.nio.SelectChannelEndPoint.updateKey() @bci=135, line=344 (Compiled frame)
 - org.mortbay.io.nio.SelectChannelEndPoint.undispatch() @bci=10, line=204 (Compiled frame)
 - org.mortbay.jetty.nio.SelectChannelConnector$ConnectorEndPoint.undispatch() @bci=54, line=382 (Compiled frame)
 - org.mortbay.io.nio.SelectChannelEndPoint.run() @bci=44, line=449 (Compiled frame)
 - org.mortbay.thread.QueuedThreadPool$PoolThread.run() @bci=25, line=534 (Compiled frame)

Thread 22557: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - java.lang.Object.wait(long, int) @bci=58, line=443 (Compiled frame)
 - com.stumbleupon.async.Deferred.doJoin(boolean, long) @bci=244, line=1148 (Compiled frame)
 - com.stumbleupon.async.Deferred.join(long) @bci=3, line=1028 (Compiled frame)
(truncated)

Thread 20907: (state = IN_NATIVE)
 - java.net.PlainSocketImpl.socketAccept(java.net.SocketImpl) @bci=0 (Interpreted frame)
 - java.net.PlainSocketImpl.accept(java.net.SocketImpl) @bci=7, line=408 (Interpreted frame)
 - java.net.ServerSocket.implAccept(java.net.Socket) @bci=60, line=462 (Interpreted frame)
 - java.net.ServerSocket.accept() @bci=48, line=430 (Interpreted frame)
 - sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop() @bci=55, line=369 (Interpreted frame)
 - sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run() @bci=1, line=341 (Interpreted frame)
 - java.lang.Thread.run() @bci=11, line=662 (Interpreted frame)

Thread 22901: (state = IN_NATIVE)
 - sun.nio.ch.EPollArrayWrapper.epollWait(long, int, long, int) @bci=0 (Compiled frame; information may be imprecise)
 - sun.nio.ch.EPollArrayWrapper.poll(long) @bci=18, line=210 (Compiled frame)
 - sun.nio.ch.EPollSelectorImpl.doSelect(long) @bci=28, line=65 (Compiled frame)
 - sun.nio.ch.SelectorImpl.lockAndDoSelect(long) @bci=37, line=69 (Compiled frame)
 - sun.nio.ch.SelectorImpl.select(long) @bci=30, line=80 (Compiled frame)
 - net.spy.memcached.MemcachedConnection.handleIO() @bci=126, line=188 (Compiled frame)
 - net.spy.memcached.MemcachedClient.run() @bci=11, line=1591 (Compiled frame)

Answer 1

回答我自己的问题，因为我们部分找到了问题的根源。我们的系统中有一段代码如下：

LinkedList<Foo> foo = getSomePotentiallyLargeList();
long someValue = someCalendar.getTimeInMillis();
for (int i = 0; i < foo.size; i++) {
    if (foo.get(i).someField < someValue) break;
}

这本质上是我们代码中的一个错误，因为上面的for循环需要n ^ 2次才能执行，因为foo是LinkedList。但是，如果我们在一个线程中遇到一个长列表（该线程应该已经卡住了很长时间，而其他线程继续取得进展，并且jvm偶尔会暂停gc等等），它不应该锁定我们所有的线程。）。

我们的应用程序冻结的原因是，当它达到gc时，所有gc线程都会阻塞，直到所有线程都达到安全点，并且所有java线程都会在达到安全点时阻塞，直到gc完成。似乎JVM无法在for循环中放置一个安全点，因此需要继续执行，可能需要数天或更长时间，直到循环结束并且可以达到安全点。

到达的最后一个安全点是在调用getTimeInMillis（）内部，这就是为什么jstack -F报告了那里的近似执行位置。看起来这肯定是一个JVM错误，因为我的理解是安全点应该位于执行中的每个分支中，以防止gc在一个循环线程上等待的问题。

不幸的是，我用一个小例子无法在我自己的桌面上重现这个问题。例如，如果我运行两个线程，其中一个以上述方式执行，另一个只是分配适量的内存，gc不会阻塞第二个线程，而第一个线程卡在一个长循环中。

很高兴验证确实是这种情况并隔离问题，或者更好地了解一旦触发gc，如何确保安全点可以快速到达。毋庸置疑，我们的修复不是花费n ^ 2时间在循环中，但鉴于我们的输出，找到这个特定问题非常困难。 gc不仅被卡住了，而且由于jstack无法在循环中报告jvm的执行位置，因此很难在代码中找到这个bug。

Answer 2

如果你使用像jmxtrans之类的东西每隔5分钟收集一堆VM信息并用Graphite这样的数据绘制数据，它可以帮助调试这类事情。

您可能认为没有什么可辨别的，但这可能是因为您只查看一个数据点，即响应时间。收集JVM通过JMX公开的所有不同的GC相关数据点，并查看其中一个是否提供了一些警告。如果您的应用程序定期分配并释放相同数量（x％）的堆，则可能与获取可用堆空间的x％有关。您需要以各种比例（放大和缩小）来研究图表，以了解应用程序的正常行为。

Answer 3

尝试添加

-XX：+ DisableExplicitGC

切换到Java参数。人们经常遇到使用

在库代码中的某处触发显式GC的时间

的System.gc（）;

为JULL GC提供了一个提示，可能会不必要地触发FULL GC。

-XX：+ DisableExplicitGC将禁用sys调用。

偶尔完全gc后JVM会锁定

3 个答案: