<2008-4-12 20时48分52秒 GMT+08:00> <Error> <WebLogicServer> <BEA-000337> <ExecuteThread: '8' for queue: 'weblogic.kernel.Default' has been busy for "624" seconds working on the request "Http Request: /webbi/click.do", which is more than the configured time (StuckThreadMaxTime) of "600" seconds.>
如果代码中存在同步方法,并且是调用率比较高的,那么可能会出现CPU利用率低并且TPS也低的情况。通常Java应用自身的同步代码并不是很多,但是所用到的一些扩展的包,就有可能用到了同步代码。最典型的一个例子是Log4j. 给出一个示例的Thread Dump
"ExecuteThread: '152' for queue: 'weblogic.kernel.Default'" daemon prio=1 tid=0x08d9fef8 nid=0x1f28 waiting for monitor entry [5a1fd000..5a1fe24c]
at org.apache.log4j.Category.callAppenders(Category.java:185)
- waiting to lock <0x838664b0> (a org.apache.log4j.spi.RootCategory)
at org.apache.log4j.Category.forcedLog(Category.java:372)
at org.apache.log4j.Category.info(Category.java:674)
...
152号执行线程在等待<0x838664b0> (a org.apache.log4j.spi.RootCategory) 对象被其他线程释放同步锁。在完整的Thread dump中可以看出,有大量的线程都在等待同一个对象。这个对象被158号线程使用:
"ExecuteThread: '158' for queue: 'weblogic.kernel.Default'" daemon prio=1 tid=0x08da4d28 nid=0x1f28 waiting for monitor entry [59efd000..59efe24c]
at java.lang.StackTraceElement.toString(StackTraceElement.java:130)
at java.lang.String.valueOf(String.java:2131)
at java.lang.StringBuffer.append(StringBuffer.java:370)
- locked <0xa32e5370> (a java.lang.StringBuffer)
at java.lang.Throwable.printStackTrace(Throwable.java:512)
- locked <0xa326af28> (a org.apache.log4j.spi.VectorWriter)
at org.apache.log4j.spi.ThrowableInformation.getThrowableStrRep(ThrowableInformation.java:50)
at org.apache.log4j.spi.LoggingEvent.getThrowableStrRep(LoggingEvent.java:333)
at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:295)
at org.apache.log4j.WriterAppender.append(WriterAppender.java:150)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:221)
- locked <0x83866430> (a org.apache.log4j.ConsoleAppender)
at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:57)
at org.apache.log4j.Category.callAppenders(Category.java:187)
- locked <0x838664b0> (a org.apache.log4j.spi.RootCategory)
at org.apache.log4j.Category.forcedLog(Category.java:372)
由于Log4j的同步代码导致出现上述的问题。所以,如果不是为了跟踪问题,尽量将Log4j的日志级别设置的高一些。减少同步代码的调用,能够极大的利用硬件资源。
如果代码中存在同步方法,并且是调用率比较高的,那么可能会出现CPU利用率低并且TPS也低的情况。通常Java应用自身的同步代码并不是很多,但是所用到的一些扩展的包,就有可能用到了同步代码。最典型的一个例子是Log4j. 给出一个示例的Thread Dump
"ExecuteThread: '152' for queue: 'weblogic.kernel.Default'" daemon prio=1 tid=0x08d9fef8 nid=0x1f28 waiting for monitor entry [5a1fd000..5a1fe24c]
at org.apache.log4j.Category.callAppenders(Category.java:185)
- waiting to lock <0x838664b0> (a org.apache.log4j.spi.RootCategory)
at org.apache.log4j.Category.forcedLog(Category.java:372)
at org.apache.log4j.Category.info(Category.java:674)
...
152号执行线程在等待<0x838664b0> (a org.apache.log4j.spi.RootCategory) 对象被其他线程释放同步锁。在完整的Thread dump中可以看出,有大量的线程都在等待同一个对象。这个对象被158号线程使用:
"ExecuteThread: '158' for queue: 'weblogic.kernel.Default'" daemon prio=1 tid=0x08da4d28 nid=0x1f28 waiting for monitor entry [59efd000..59efe24c]
at java.lang.StackTraceElement.toString(StackTraceElement.java:130)
at java.lang.String.valueOf(String.java:2131)
at java.lang.StringBuffer.append(StringBuffer.java:370)
- locked <0xa32e5370> (a java.lang.StringBuffer)
at java.lang.Throwable.printStackTrace(Throwable.java:512)
- locked <0xa326af28> (a org.apache.log4j.spi.VectorWriter)
at org.apache.log4j.spi.ThrowableInformation.getThrowableStrRep(ThrowableInformation.java:50)
at org.apache.log4j.spi.LoggingEvent.getThrowableStrRep(LoggingEvent.java:333)
at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:295)
at org.apache.log4j.WriterAppender.append(WriterAppender.java:150)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:221)
- locked <0x83866430> (a org.apache.log4j.ConsoleAppender)
at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:57)
at org.apache.log4j.Category.callAppenders(Category.java:187)
- locked <0x838664b0> (a org.apache.log4j.spi.RootCategory)
at org.apache.log4j.Category.forcedLog(Category.java:372)
由于Log4j的同步代码导致出现上述的问题。所以,如果不是为了跟踪问题,尽量将Log4j的日志级别设置的高一些。减少同步代码的调用,能够极大的利用硬件资源。