Java日志记录线程阻塞

时间:2013-09-11 08:48:57

标签: java multithreading tomcat hang java.util.logging

我遇到了java logger的问题,如下所示。我们的tomcat服务器将在运行大约3到4个小时后挂起。在tomcat重新启动后,它将再次运行大约4个小时然后再次挂起。就像IVM挂起一样。

我获得线程转储后,将显示如下代码所示。据我所知,它具有日志锁定或硬盘读/写操作的问题。任何人都知道这是java 1.6问题,或者它将在java 7中修复。

我使用的是java 1.6.0_18和apache-tomcat-7.0.25。

catalina-exec-49" daemon prio=10 tid=0x00007f2fb000f800 nid=0x2a29 waiting for monitor entry [0x00007f2f6d4d2000]
 java.lang.Thread.State: BLOCKED (on object monitor)
 at it.codegen.logging.CGFileHandler.publish(CGFileHandler.java:684)
 - waiting to lock <0x00007f32dfc56400> (a it.codegen.logging.CGFileHandler)
 at java.util.logging.Logger.log(Logger.java:458)
 at java.util.logging.Logger.doLog(Logger.java:480)
 at java.util.logging.Logger.log(Logger.java:503)
 at it.codegen.tbx.ResourceManager.startResourceManager(ResourceManager.java:246)
 - locked < 0x00007f32f031ad60> (a it.codegen.tbx.ResourceManager)
 at it.codegen.tbx.ResourceManager.createSession(ResourceManager.java:265)
 at it.codegen.tbx.search.service.TravelBoxSearch.createSessionEx(TravelBoxSearch.java:3667)
 at it.codegen.tbx.search.service.TravelBoxSearch.search(TravelBoxSearch.java:3943)
 at sun.reflect.GeneratedMethodAccessor105.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at com.sun.xml.ws.api.server.InstanceResolver$1.invoke(InstanceResolver.java:246)
 at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146)
 at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257)
 at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:95)
 at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:629)
 at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:588)
 at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:573)
 at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:470)
 - locked < 0x00007f30b6f5f208> (a com.sun.xml.ws.api.pipe.Fiber)
 at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:295)
 at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:515)
 at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:285)
 at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:143)
 at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:155)
 at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:189)
 at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:76)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
 at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
 at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
 at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
 at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1600)
 - locked < 0x00007f32744cd100> (a org.apache.tomcat.util.net.NioChannel)
 at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:619) 

// CGFileHandler类发布方法

public synchronized void publish( LogRecord record )
{
    int startPos = meter.written;
    if( !isLoggable( record ) )
    {
        return;
    }
    super.publish( record );
    flush();
    int endPos = meter.written;
    setFileNameAndPossistions( startPos, endPos );
    if( limit > 0 && meter.written >= limit )
    {            
        AccessController.doPrivileged( new PrivilegedAction()
        {
            public Object run()
            {
                rotate();
                return null;
            }
        } );
     }
 }

private void setFileNameAndPossistions( int startPos, int endPos )
{
    String additionalKey = ":" + loggerName + ":"+String.valueOf(    
Thread.currentThread().getId() );

    SoapUtility.setContextData( Loggable.FILE_NAME + additionalKey, currentFileName );
    SoapUtility.setContextData( Loggable.START_POS + additionalKey, startPos );
    SoapUtility.setContextData( Loggable.END_POS + additionalKey, endPos );
}

1 个答案:

答案 0 :(得分:2)

你有一个典型的死锁情况。线程catalina-exec-49拥有3个锁(org.apache.tomcat.util.net.NioChannelcom.sun.xml.ws.api.pipe.Fiberit.codegen.tbx.ResourceManager)并等待获取第4个(进入同步publish方法在it.codegen.logging.CGFileHandler

问题是另一个线程已经获取了CGFileHandler上的锁(可能是通过输入publish方法,或同一实例上的另一个同步方法),并且正在等待获取其中一个catalina-exec-49持有的锁。两个线程都无法前进,导致死锁。

没有看到详细的代码和堆栈转储等,我不能给你具体的建议,但一般你应该:

  • 将同步块的范围限制为最低限度
  • 避免在持有锁的方法之外呼叫
  • 构建代码,以便始终按特定顺序获取锁