Viele Threads sind blockiert und Speicher von alten Gen nicht freizugeben

Question

Ich benutze Tomcat Server und wenn ich Thread Dump nahm ich sehe viele Threads sind blockiert (172) und andere Threads sind IN_NATIVE (27). Fast viele blockierte Threads sind wie Smiler nach unten. Kann jemand helfen, was der Grund sein könnte? Mein 8GB OldGen Speicherplatz ist voll. Nach dem Ausführen von GC wird auch nicht freigegeben.

blockierten Threads:

Thread 22614 - threadId:Thread 22614 - state:BLOCKED 
stackTrace: 
- java.net.SocketInputStream.socketRead0(java.io.FileDescriptor, byte[], int, int, int) @bci=0 (Compiled frame; information may be imprecise) 
- java.net.SocketInputStream.read(byte[], int, int, int) @bci=87, line=152 (Compiled frame) 
- java.net.SocketInputStream.read(byte[], int, int) @bci=11, line=122 (Compiled frame) 
- org.apache.coyote.http11.InternalInputBuffer.fill(boolean) @bci=59, line=512 (Compiled frame) 
- org.apache.coyote.http11.InternalInputBuffer.fill() @bci=2, line=497 (Compiled frame) 
- org.apache.coyote.http11.Http11Processor.process(org.apache.tomcat.util.net.SocketWrapper) @bci=263, line=203 (Compiled frame) 
- org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(org.apache.tomcat.util.net.SocketWrapper, org.apache.tomcat.util.net.SocketStatus) @bci=96, line=515 (Compiled frame) 
- org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run() @bci=130, line=302 (Compiled frame) 
- java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) @bci=95, line=1145 (Compiled frame) 
- java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, line=615 (Interpreted frame) 
- java.lang.Thread.run() @bci=11, line=745 (Interpreted frame) 




Thread 23677 - threadId:Thread 23677 - state:BLOCKED 
stackTrace: 
- sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may be imprecise) 
- java.util.concurrent.locks.LockSupport.parkNanos(java.lang.Object, long) @bci=20, line=226 (Compiled frame) 
- java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(long) @bci=68, line=2082 (Compiled frame) 
- java.util.concurrent.LinkedBlockingQueue.poll(long, java.util.concurrent.TimeUnit) @bci=62, line=467 (Compiled frame) 
- org.apache.tomcat.util.threads.TaskQueue.poll(long, java.util.concurrent.TimeUnit) @bci=3, line=86 (Compiled frame) 
- org.apache.tomcat.util.threads.TaskQueue.poll(long, java.util.concurrent.TimeUnit) @bci=3, line=32 (Compiled frame) 
- java.util.concurrent.ThreadPoolExecutor.getTask() @bci=141, line=1068 (Compiled frame) 
- java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) @bci=26, line=1130 (Compiled frame) 
- java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, line=615 (Interpreted frame) 
- java.lang.Thread.run() @bci=11, line=745 (Interpreted frame) 


Thread 23674 - threadId:Thread 23674 - state:BLOCKED 
stackTrace: 
- com.mysql.jdbc.SingleByteCharsetConverter.toString(byte[], int, int) @bci=1, line=322 (Compiled frame) 
- com.mysql.jdbc.ResultSetRow.getString(java.lang.String, com.mysql.jdbc.MySQLConnection, byte[], int, int) @bci=54, line=797 (Compiled frame) 
- com.mysql.jdbc.ByteArrayRow.getString(int, java.lang.String, com.mysql.jdbc.MySQLConnection) @bci=24, line=72 (Compiled frame) 
- com.mysql.jdbc.ResultSetImpl.getStringInternal(int, boolean) @bci=155, line=5699 (Compiled frame) 
- com.mysql.jdbc.ResultSetImpl.getString(int) @bci=3, line=5576 (Compiled frame) 
- com.mysql.jdbc.ResultSetImpl.getString(java.lang.String) @bci=6, line=5616 (Compiled frame) 
- com.mchange.v2.c3p0.impl.NewProxyResultSet.getString(java.lang.String) @bci=19, line=3342 (Compiled frame) 
- org.hibernate.type.StringType.get(java.sql.ResultSet, java.lang.String) @bci=2, line=41 (Compiled frame) 
- org.hibernate.type.NullableType.nullSafeGet(java.sql.ResultSet, java.lang.String) @bci=3, line=184 (Compiled frame) 
- org.hibernate.type.NullableType.nullSafeGet(java.sql.ResultSet, java.lang.String, org.hibernate.engine.SessionImplementor, java.lang.Object) @bci=3, line=210 (Compiled frame) 

Answer 1

• ersten Stapel trace versucht, dieses Gewinde gibt aus einem Sockel und ging in BLOCKED Zustand zu lesen. Die Socket-Leseoperation ist eine Blockierungsoperation, was bedeutet, dass, wenn nichts zu lesen ist oder bis die gesamte Information vollständig gelesen ist, sie blockiert wird.

• Zweitens, LinkedBlockingQueue.poll() ist eine nicht blockierende Operation, so ist dies eine normale Stack-Trace, um üblichen Leerlauf Thread anzuzeigen. Dies wird nicht durch den Benutzercode verursacht

• Zum dritten, das sieht auch nicht problematisch als String-Wert aus der Ergebnismenge zurückgegeben wird.

Ich denke, Sie sollten auch this betrachten.

Stack-Trace # 1 und # 3 könnten verwandt sein, da das Socket-Lesen möglicherweise DB-Lesen ist.

Diese Stack-Traces werden nicht helfen, das Problem zu lösen, aber diese Art von blockierten Threads zeigen einfach ein Problem mit zu viel Speicher und übermäßiger Garbage Collection an.

Möglicherweise gibt es ein Problem mit Ihrem C3P0-Pool oder die Art, wie Sie Statement- und Resultset-Objekte erstellen - alles in allem scheint es einen Fall von Speicherlecks und Ressourcen zu geben, die nicht gut schließen.

Sehr genaue Antwort ist nicht möglich ohne relevanten Anwendungscode. Wie im Kommentar erwähnt, muss die Identität des Sperrobjekts ebenfalls gelöscht werden.

Hoffe es hilft !!