Kann ein nativer Thread einen Java-Thread blockieren

Question

Ich habe zwei Threads in einem Thread-Pool ausgeführt. Meine Anwendung hängt einfach, nachdem ich sie ausgeführt habe. Ich kann in Thread-Dump sehen, dass ein Thread in MONITOR ist und der andere in RUNNING-Status ist. Der Thread im Zustand RUNNING zeigt, dass er eine synchronisierte Methode und eine erfasste Sperre eingegeben und schließlich eine native Methode aufgerufen hat und nicht mehr reagiert. Aber es ist State Shows RUNNING. Der zweite Thread im Status MONITOR ist blockiert, während er darauf wartet, dass der erste Thread MONITOR freigibt. Mein suspiscion ist, dass die zwei zwei Threads festgefahren sind, obwohl der Thread-Dump zeigt, dass der erste Thread RUNNING ist. Ich vermute, dass versucht wird, einen Monitor von nativem Code zu erhalten, den der Thread-Stack nicht anzeigen kann. Ist es möglich, dass der Thread im systemeigenen Aufruf und der Java-Thread festgefahren sind? Siehe unten. Eine weitere Sache. Wenn ich die App wiederholt laufe, treten 'Deadlocks' wie oben erklärt wahllos bei verschiedenen Teilen des Codes auf und nicht nur was unten eingefügt wird. Normalerweise zwischen Java und Native und manchmal zwischen nativen und nativen bei File IO Operationen (was verständlich ist) . Aber können Java und Native in Deadlocks geraten? Vielen Dank.

"pool-1-thread-2@4640" prio=5 tid=0x14 nid=NA runnable 
    java.lang.Thread.State: RUNNABLE 
    blocks pool-1-thread-1@4641 
     at java.lang.Object.clone(Object.java:-1) 
     at java.util.ResourceBundle$CacheKey.clone(ResourceBundle.java:655) 
     at java.util.ResourceBundle.putBundleInCache(ResourceBundle.java:1693) 
     at java.util.ResourceBundle.findBundle(ResourceBundle.java:1477) 
     at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1361) 
     at java.util.ResourceBundle.getBundle(ResourceBundle.java:845) 
     at com.sun.org.apache.xerces.internal.utils.SecuritySupport$7.run(SecuritySupport.java:169) 
     at com.sun.org.apache.xerces.internal.utils.SecuritySupport$7.run(SecuritySupport.java:166) 
     at java.security.AccessController.doPrivileged(AccessController.java:-1) 
     at com.sun.org.apache.xerces.internal.utils.SecuritySupport.getResourceBundle(SecuritySupport.java:166) 
     at com.sun.org.apache.xerces.internal.impl.xpath.regex.RegexParser.setLocale(RegexParser.java:99) 
     at com.sun.org.apache.xerces.internal.impl.xpath.regex.RegexParser.<init>(RegexParser.java:93) 
     at com.sun.org.apache.xerces.internal.impl.xpath.regex.ParserForXMLSchema.<init>(ParserForXMLSchema.java:41) 
     at com.sun.org.apache.xerces.internal.impl.xpath.regex.RegularExpression.setPattern(RegularExpression.java:2291) 
     at com.sun.org.apache.xerces.internal.impl.xpath.regex.RegularExpression.setPattern(RegularExpression.java:2308) 
     at com.sun.org.apache.xerces.internal.impl.xpath.regex.RegularExpression.<init>(RegularExpression.java:2266) 
     at com.sun.org.apache.xerces.internal.impl.dv.xs.XSSimpleTypeDecl.applyFacets(XSSimpleTypeDecl.java:844) 
     at com.sun.org.apache.xerces.internal.impl.dv.xs.XSSimpleTypeDecl.applyFacets1(XSSimpleTypeDecl.java:751) 
     at com.sun.org.apache.xerces.internal.impl.dv.xs.BaseSchemaDVFactory.createBuiltInTypes(BaseSchemaDVFactory.java:208) 
     at com.sun.org.apache.xerces.internal.impl.dv.xs.SchemaDVFactoryImpl.createBuiltInTypes(SchemaDVFactoryImpl.java:47) 
     at com.sun.org.apache.xerces.internal.impl.dv.xs.SchemaDVFactoryImpl.<clinit>(SchemaDVFactoryImpl.java:42) 
     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeConstructorAccessorImpl.java:-1) 
     at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) 
     at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) 
     at java.lang.reflect.Constructor.newInstance(Constructor.java:423) 
     at java.lang.Class.newInstance(Class.java:442) 
     at com.sun.org.apache.xerces.internal.utils.ObjectFactory.newInstance(ObjectFactory.java:158) 
     at com.sun.org.apache.xerces.internal.utils.ObjectFactory.newInstance(ObjectFactory.java:143) 
     at com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory.getInstance(SchemaDVFactory.java:73) 
     - locked <0x1226> (a java.lang.Class) 
     at com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory.getInstance(SchemaDVFactory.java:57) 
     at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.reset(XMLSchemaLoader.java:1027) 
     at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:559) 
     at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:538) 
     at com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:255) 
     at com.fmr.feeds.transformation.XmlProcessor.validateXml(XmlProcessor.java:52) 
     at com.fmr.feeds.transformation.XmlProcessor.validateInputXML(XmlProcessor.java:34) 
     at com.fmr.feeds.transformation.Controller.processRecord(Controller.java:99) 
     at com.fmr.feeds.transformation.Controller.lambda$invokeTransformationService$1(Controller.java:80) 
     at com.fmr.feeds.transformation.Controller$$Lambda$29.1090160486.run(Unknown Source:-1) 
     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
     at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
     at java.lang.Thread.run(Thread.java:748) 

"pool-1-thread-1@4641" prio=5 tid=0x13 nid=NA waiting for monitor entry 
    java.lang.Thread.State: BLOCKED 
    waiting for pool-1-thread-2@4640 to release lock on <0x1226> (a java.lang.Class) 
     at com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory.getInstance(SchemaDVFactory.java:57) 
     at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.reset(XMLSchemaLoader.java:1027) 
     at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:559) 
     at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:538) 
     at com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:255) 
     at com.fmr.feeds.transformation.XmlProcessor.validateXml(XmlProcessor.java:52) 
     at com.fmr.feeds.transformation.XmlProcessor.validateInputXML(XmlProcessor.java:34) 
     at com.fmr.feeds.transformation.Controller.processRecord(Controller.java:99) 
     at com.fmr.feeds.transformation.Controller.lambda$invokeTransformationService$1(Controller.java:80) 
     at com.fmr.feeds.transformation.Controller$$Lambda$29.1090160486.run(Unknown Source:-1) 
     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
     at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
     at java.lang.Thread.run(Thread.java:748) 

Answer 1

Nur über das Betriebssystem (z. B. für CPU oder Dateisystemressourcen konkurrieren).

Nativer Code kann Threads hochfahren, die nicht von der JVM überwacht werden, aber Threads in der JVM können nur sprachabhängige Sprachen für andere Threads blockieren, die auch von der JVM verwaltet werden (sofern der native Code nicht besonders clever ist)).

Es sieht aus wie Thread pool-1-thread-2@4640 ist derzeit etwas in Ihrem Thread-Dump. Vielleicht auf CPU- oder Betriebssystemressourcen warten. Der andere Thread wartet auf eine Sperre, die im Aufruf-Stack dieses Threads enthalten ist.