Проблема производительности загрузчика классов tomcat

Наш бенчмаркинг обнаружил загрузочную шину в Apache Tomcat 7.0.59. Когда сервер достигает своего предела производительности, большинство его потоков блокируется ClassLoader.

Следы стека заблокированных потоков выглядит следующим образом:

"http-bio-4504-exec-500" Id=2335 BLOCKED on java.util.jar.JarFile@464f9f8 owned by "[1432628598653] POST /services/signin HTTP/1.0" Id=1990
    at java.util.zip.ZipFile.getEntry(ZipFile.java:304)
    -  blocked on java.util.jar.JarFile@464f9f8
    at java.util.jar.JarFile.getEntry(JarFile.java:226)
    at java.util.jar.JarFile.getJarEntry(JarFile.java:209)
    at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:840)
    at sun.misc.URLClassPath$JarLoader.findResource(URLClassPath.java:818)
    at sun.misc.URLClassPath$1.next(URLClassPath.java:226)
    at sun.misc.URLClassPath$1.hasMoreElements(URLClassPath.java:236)
    at java.net.URLClassLoader$3$1.run(URLClassLoader.java:583)
    at java.net.URLClassLoader$3$1.run(URLClassLoader.java:581)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader$3.next(URLClassLoader.java:580)
    at java.net.URLClassLoader$3.hasMoreElements(URLClassLoader.java:605)
    at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45)
    at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54)
    at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45)
    at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54)
    at com.sun.xml.ws.util.ServiceFinder$LazyIterator.hasNext(ServiceFinder.java:443)
    at com.sun.xml.ws.util.ServiceFinder$CompositeIterator.hasNext(ServiceFinder.java:390)
    at com.sun.xml.ws.api.message.saaj.SAAJFactory.getMessageFactory(SAAJFactory.java:96)
    at com.sun.xml.ws.api.SOAPVersion.getMessageFactory(SOAPVersion.java:221)
    at com.sun.xml.ws.api.message.saaj.SAAJFactory.readAsSOAPMessage(SAAJFactory.java:275)
    at com.sun.xml.ws.api.message.saaj.SAAJFactory.readAsSAAJ(SAAJFactory.java:205)
    at com.sun.xml.ws.api.message.saaj.SAAJFactory.read(SAAJFactory.java:194)
    at com.sun.xml.ws.message.AbstractMessageImpl.toSAAJ(AbstractMessageImpl.java:199)
    at com.sun.xml.ws.api.message.MessageWrapper.readAsSOAPMessage(MessageWrapper.java:160)
    at com.sun.xml.ws.handler.SOAPMessageContextImpl.getMessage(SOAPMessageContextImpl.java:86)

и поток блокировщика работает в том же месте

"[1432628598653] POST /services/signin HTTP/1.0" Id=1990 RUNNABLE
    at java.util.zip.ZipFile.getEntry(ZipFile.java:304)
    -  locked java.util.jar.JarFile@464f9f8
    at java.util.jar.JarFile.getEntry(JarFile.java:226)
    at java.util.jar.JarFile.getJarEntry(JarFile.java:209)
    at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:840)
    at sun.misc.URLClassPath$JarLoader.findResource(URLClassPath.java:818)
    at sun.misc.URLClassPath$1.next(URLClassPath.java:226)
    at sun.misc.URLClassPath$1.hasMoreElements(URLClassPath.java:236)
    at java.net.URLClassLoader$3$1.run(URLClassLoader.java:583)
    at java.net.URLClassLoader$3$1.run(URLClassLoader.java:581)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader$3.next(URLClassLoader.java:580)
    at java.net.URLClassLoader$3.hasMoreElements(URLClassLoader.java:605)
    at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45)
    at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54)
    at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45)
    at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54)
    at com.sun.xml.ws.util.ServiceFinder$LazyIterator.hasNext(ServiceFinder.java:443)
    at com.sun.xml.ws.util.ServiceFinder$CompositeIterator.hasNext(ServiceFinder.java:390)
    at com.sun.xml.ws.api.message.saaj.SAAJFactory.read(SAAJFactory.java:190)
    at com.sun.xml.ws.message.AbstractMessageImpl.toSAAJ(AbstractMessageImpl.java:199)
    at com.sun.xml.ws.api.message.MessageWrapper.readAsSOAPMessage(MessageWrapper.java:160)
    at com.sun.xml.ws.handler.SOAPMessageContextImpl.getMessage(SOAPMessageContextImpl.java:86)

Наши приложения делают что-то неправильно? Есть ли способ избежать блокировки в загрузчиках классов?

1 ответ

Решение

Проблема была полностью исправлена ​​следующим хаком:

  1. Я добавил -Djaxp.debug=true к аргументам JVM.
  2. Затем я нашел в журналах все классы, которые искал JAX-WS.
  3. Я добавил системное свойство для каждого упомянутого класса, и он заставил ServiceFinder исключить поиск файлов service.properties в classpath.

Мои последние аргументы JVM выглядели так:

-Djavax.xml.soap.MetaFactory=com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl
-Djavax.xml.datatype.DatatypeFactory=com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl
-Djavax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl
-Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl
-Djavax.xml.stream.XMLInputFactory=com.ctc.wstx.stax.WstxInputFactory
-Djavax.xml.stream.XMLOutputFactory=com.ctc.wstx.stax.WstxOutputFactory
-Djavax.xml.transform.TransformerFactory=com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl
Другие вопросы по тегам