不可思议的堆栈跟踪

Question

通过分析一个问题，我试图理解这个奇怪的堆栈跟踪：

Thread 3049: (state = BLOCKED)
- java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
- java.io.PipedInputStream.read() @bci=142, line=326 (Compiled frame)
- java.io.PipedInputStream.read(byte[], int, int) @bci=43, line=377 (Compiled frame)
- org.apache.http.entity.InputStreamEntity.writeTo(java.io.OutputStream) @bci=75, line=140 (Compiled frame)
- org.apache.http.impl.execchain.RequestEntityProxy.writeTo(java.io.OutputStream) @bci=10, line=123 (Compiled frame)
- org.apache.http.impl.DefaultBHttpClientConnection.sendRequestEntity(org.apache.http.HttpEntityEnclosingRequest) @bci=31, line=156 (Compiled frame)
- org.apache.http.impl.conn.CPoolProxy.sendRequestEntity(org.apache.http.HttpEntityEnclosingRequest) @bci=5, line=162 (Compiled frame)
- org.apache.http.protocol.HttpRequestExecutor.doSendRequest(org.apache.http.HttpRequest, org.apache.http.HttpClientConnection, org.apache.http.protocol.HttpContext) @bci=223, line=238 (Compiled frame)
- org.apache.http.protocol.HttpRequestExecutor.execute(org.apache.http.HttpRequest, org.apache.http.HttpClientConnection, org.apache.http.protocol.HttpContext) @bci=25, line=123 (Compiled frame)
- org.apache.http.impl.execchain.MainClientExec.execute(org.apache.http.conn.routing.HttpRoute, org.apache.http.client.methods.HttpRequestWrapper, org.apache.http.client.protocol.HttpClientContext, org.apache.http.client.methods.HttpExecutionAware) @bci=714, line=271 (Compiled frame)
- org.apache.http.impl.execchain.ProtocolExec.execute(org.apache.http.conn.routing.HttpRoute, org.apache.http.client.methods.HttpRequestWrapper, org.apache.http.client.protocol.HttpClientContext, org.apache.http.client.methods.HttpExecutionAware) @bci=447, line=184 (Compiled frame)
- org.apache.http.impl.execchain.RetryExec.execute(org.apache.http.conn.routing.HttpRoute, org.apache.http.client.methods.HttpRequestWrapper, org.apache.http.client.protocol.HttpClientContext, org.apache.http.client.methods.HttpExecutionAware) @bci=39, line=88 (Compiled frame)
- org.apache.http.impl.client.InternalHttpClient.doExecute(org.apache.http.HttpHost, org.apache.http.HttpRequest, org.apache.http.protocol.HttpContext) @bci=168, line=184 (Compiled frame)
- java.util.concurrent.locks.AbstractQueuedSynchronizer.doReleaseShared() @bci=69, line=695 (Compiled frame)
- java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(int) @bci=9, line=1342 (Compiled frame)
- java.util.concurrent.CountDownLatch.countDown() @bci=5, line=291 (Compiled frame)
- com.mycompany.browse.concurrent.stream.CustomPipedInputStream.close() @bci=8, line=43 (Compiled frame)
- com.mycompany.browse.mina.handler.BrowseHttpMessageProcessor.run() @bci=57, line=200 (Compiled frame)
- java.util.concurrent.Executors$RunnableAdapter.call() @bci=4, line=511 (Compiled frame)
- java.util.concurrent.FutureTask.run() @bci=42, line=266 (Compiled frame)
- java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) @bci=95, line=1142 (Compiled frame)
- java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, line=617 (Compiled frame)
- java.lang.Thread.run() @bci=11, line=745 (Compiled frame)

根据堆栈跟踪，AbstractQueuedSynchronizer 调用 Apache HTTP 客户端。怎么会这样？我们是运行 Oracle Java 亚马逊上的 1.8 Linux

而且我有很多线程具有完全相同的堆栈跟踪。随时。

后期编辑：按照建议从不可能重命名为不可思议

Answer 1

据我所知，您在强制模式下获得了此堆栈跟踪：jstack -F。 jstack和jstack -F描述的here有很大区别。

强制模式工作 out-of-process，异步且无需 JVM 的合作。它不如常规 jstack 可靠，因为 JVM 不在安全点并且其状态可能不一致。例如，它可以在垃圾收集过程中。

第二个原因是stack dump是通过外部工具（Serviceability Agent）重建的，还不是很完善。因此，为了获得可靠的堆栈跟踪，我建议尽可能在正常模式下使用 jstack。

不可思议的堆栈跟踪

Inconceivable stack trace

java

jvm

stack-trace