Troubleshooting Java Thread Blocking issues

I developed the worker, every few months on the line will be blocked once, has not found the problem. I finally got the knot today. Summarize the settlement process and share with you.

The entire thread stack for this process is first typed with the Jstack command. After you get the thread dump file, search for your worker name.

"Defaultquartzscheduler_worker-10" prio=10 tid=0x00007f55cd54d800 nid=0x3e2e waiting for monitor entry [ 0X00007F51AB8F7000]   Java.lang.Thread.State:BLOCKED (on object monitor) at Com.jd.chat.worker.service.impl.NewPopAccountSyncServiceImpl.addAccounts (newpopaccountsyncserviceimpl.java:86) -Waiting to lock <0x0000000782359268> (a Com.jd.chat.worker.service.impl.NewPopAccountSyncServiceImpl) at Com.jd.chat.worker.service.timer.AccountIncSyncTimer.run (accountincsynctimer.java:114) at Com.jd.chat.worker.service.timer.AbstractTimer.start (abstracttimer.java:44) at Com.jd.chat.worker.service.timer.AbstractTimer.doJob (abstracttimer.java:49) at Com.jd.chat.worker.web.context.startapplistener$timerjob.execute (startapplistener.java:188) at Org.quartz.core.JobRunShell.run (jobrunshell.java:202) at Org.quartz.simpl.simplethreadpool$workerthread.run ( simplethreadpool.java:573)-Locked <0x0000000783641c68> (a java.lang.Object)

quickly found out which line the thread was blocking. But wine bottles so little information, and can not find out the real cause of the problem, here is recommended a tool, called Tda.bat. Colleague to me, there should be a download online. Import this dump file into the TDA. Locate the blocked thread. The blocked thread is red.

The reason this software is good, is because when you find the blocked thread, underneath the interface, the blocking more detailed thread stack will be played. Intercept some of this stack's information.

At Org.mariadb.jdbc.MySQLPreparedStatement.execute (mysqlpreparedstatement.java:141) at Org.apache.commons.dbcp.DelegatingPreparedStatement.execute (delegatingpreparedstatement.java:172) at Org.apache.commons.dbcp.DelegatingPreparedStatement.execute (delegatingpreparedstatement.java:172) at Com.ibatis.sqlmap.engine.execution.SqlExecutor.executeUpdate (sqlexecutor.java:80) at Com.ibatis.sqlmap.engine.mapping.statement.MappedStatement.sqlExecuteUpdate (mappedstatement.java:216) at Com.ibatis.sqlmap.engine.mapping.statement.MappedStatement.executeUpdate (mappedstatement.java:94) at Com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.update (sqlmapexecutordelegate.java:457) at Com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.update (sqlmapsessionimpl.java:90) at Org.springframework.orm.ibatis.sqlmapclienttemplate$9.doinsqlmapclient (sqlmapclienttemplate.java:380) at Org.springframework.orm.ibatis.sqlmapclienttemplate$9.doinsqlmapclient (sqlmapclienttemplate.java:1) at Org.springframework.orm.ibatis.SqlMapClieNttemplate.execute (sqlmapclienttemplate.java:200) at Org.springframework.orm.ibatis.SqlMapClientTemplate.update ( sqlmapclienttemplate.java:378) at Com.jd.im.data.dataresource.ImSqlMapClientTemplate.retriedWithoutAnyInterventionUpdate ( imsqlmapclienttemplate.java:169) at Com.jd.im.data.dataresource.ImSqlMapClientTemplate.update ( imsqlmapclienttemplate.java:137) at Com.jd.chat.dao.impl.WriteDaoImpl.update (writedaoimpl.java:21) at Com.jd.chat.zone.service.impl.GroupServiceImpl.updateRoute (groupserviceimpl.java:766) at Com.jd.chat.worker.service.impl.NewPopAccountSyncServiceImpl.addAccounts (newpopaccountsyncserviceimpl.java:267 )-Locked <0x0000000782359268> (a Com.jd.chat.worker.service.impl.NewPopAccountSyncServiceImpl)

This is really a useful stack! It tells me that the program is executing SQL, the SQL deadlock, and then the thread is blocked. It also provides more useful information about which SQL is causing the deadlock. The third line to the bottom of the stack indicates the SQL that caused the deadlock.

But is it necessary to use this tool to find the exact reason? The answer is, of course, no!.

Tell us how not to find the real reason for blocking through the tool!

The thread stack was just searched through the "BLOCKED" keyword, and its thread name "Defaultquartzscheduler_worker-10" was found. OK, then, change the last 10 to 1, that is, "defaultquartzscheduler_worker-1", and then take this keyword to search the entire process stack.

"Defaultquartzscheduler_worker-1" prio=10 tid=0x00007f55cd2aa000 nid=0x3e25 runnable [0x00007f51b02c0000] Java.lang.Thread.State:RUNNABLEat java.net.SocketInputStream.socketRead0 (Native Method) at Java.net.SocketInputStream.read (socketinputstream.java:129) at Java.io.BufferedInputStream.fill ( bufferedinputstream.java:218) at Java.io.BufferedInputStream.read1 (bufferedinputstream.java:258) at Java.io.BufferedInputStream.read (bufferedinputstream.java:317)-Locked <0x0000000791370d50> (a Java.io.BufferedInputStream) at org.mariadb.jdbc.internal.common.packet.buffer.ReadUtil.readFully (Readutil.java : In Org.mariadb.jdbc.internal.common.packet.buffer.ReadUtil.readFully (readutil.java:92) at Org.mariadb.jdbc.internal.common.packet.RawPacket.nextPacket (rawpacket.java:77) at Org.mariadb.jdbc.internal.common.packet.SyncPacketFetcher.getRawPacket (syncpacketfetcher.java:67) at Org.mariadb.jdbc.internal.mysql.MySQLProtocol.getResult (mysqlprotocol.java:891) at Org.mariadb.jdbc.internal.mysql.MySQLProTocol.executequery (mysqlprotocol.java:982) at Org.mariadb.jdbc.MySQLStatement.execute (mysqlstatement.java:280)- Locked <0x0000000791370678> (a org.mariadb.jdbc.internal.mysql.MySQLProtocol) at Org.mariadb.jdbc.MySQLPreparedStatement.execute (mysqlpreparedstatement.java:141)

post a portion of the process stack. This process stack is actually the real stack that has just been shown underneath the TDA software interface causing the thread to block! This thread is runnable state, but MySQL is locked. That means it's stuck in MySQL.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Troubleshooting Java Thread Blocking issues