不可思议的堆栈跟踪

Posted 2021-04-17

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

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$1.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客户端。怎么会发生这种情况？我们在Amazon Linux上运行Oracle Java 1.8

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

稍后编辑：根据建议从不可能重命名为不可思议

答案

据我所知，你有强制模式的堆栈跟踪：jstack -F。 jstack和jstack -F描述here有很大的不同。

强制模式在进程外，异步进行，无需JVM的协作。它不如常规jstack可靠，因为JVM不在安全点，其状态可能不一致。例如，它可以处于垃圾收集的中间。

第二个原因是堆栈转储由外部工具（可维护性代理）重建，这不是很完美。因此，为了获得可靠的堆栈跟踪，我建议尽可能在正常模式下使用jstack。