大多数Java开发人员都熟悉臭名昭著且非常常见的java.lang.ClassNotFoundException 。 虽然通常已经很好地了解了此问题的根源(类路径中缺少类/库,类加载器委派问题等),但对整体JVM和性能的影响通常是未知的。 这种情况可能会严重影响您的应用程序响应时间和可伸缩性。
部署了多个应用程序的大型Java EE企业系统最容易遭受此类问题的影响,因为在运行时会激活大量不同的应用程序类加载器。 除非确定了明确的业务影响并实施了紧密的日志监视,否则这将面临面临“未检测到” ClassNotFoundException的风险,从而导致:持续的性能影响以及可能的JVM类加载IO和线程锁争用。
下面的文章和示例程序将说明从客户生产系统中发现的ClassNotFoundException的任何出现都应予以认真对待并Swift解决。
Java类加载:缺少链接以获得最佳性能
对性能问题的正确理解始于对Java类加载模型的正确了解。 ClassNotFoundException本质上意味着JVM无法定位和/或加载特定的Java类,例如:
- Class.forName()方法
- ClassLoader.findSystemClass()方法
- ClassLoader.loadClass()方法
尽管应用程序类的类加载在JVM生命周期中(或通过动态重新部署功能)应该只发生一次,但某些应用程序也依赖于动态类加载操作。
无论如何,重复的有效和“失败”类加载操作可能非常麻烦,特别是当默认JDK java.lang.ClassLoader本身尝试加载过程时。 实际上,由于向后兼容性,默认的JDK 1.7+行为将仅允许一次加载一个类,除非将类加载器标记为“具有并行功能”。 请记住,即使同步仅在类级别完成,针对相同类名的重复类加载失败仍将触发线程锁争用,具体取决于您正在处理的Java线程并发级别。 回到JDK 1.6时,情况最糟糕,在类加载器实例级别系统地完成了同步。
因此,诸如JBoss WildFly 8之类的Java EE容器正在使用它们自己的内部并发类加载器来加载应用程序类。 这些类加载器实现了更细粒度的锁定,因此允许从类加载器的同一实例中同时加载不同的类。 这也与最新的JDK 1.7+改进保持一致,后者引入了对多线程自定义类加载器的支持,这也有助于防止某些类加载器出现死锁情况。
话虽这么说,系统级类(例如java。*和Java EE容器模块)的类加载仍然依靠默认的JDK ClassLoader。 这意味着相同类名(例如ClassNotFoundException)的重复类加载失败仍会触发严重的线程锁争用。 这正是我们将在本文的其余部分中重复和演示的内容。
线程锁争用–问题复制
为了重新创建和模拟此问题,我们根据以下规范创建了一个简单的应用程序:
- 一个JAX-RS(REST)Web服务,对系统包级别中“定位”的虚拟类名称执行Class.forName():
字符串className =“ java.lang.WrongClassName”;
类。 forName (className);
- JRE:HotSpot JDK 1.7 @ 64位
- Java EE容器: JBoss WildFly 8
- 负载测试工具: Apache JMeter
- Java监控:JVisualVM
- Java并发故障排除: JVM线程转储分析
该仿真实际上与20个线程同时执行JAX-RS Web服务。 每次调用都会生成ClassNotFoundException。 为了减少对IO的影响并仅关注类加载争用,完全禁用了日志记录。
现在,让我们看看从30到60秒的运行情况来看JVisualVM的结果。 我们可以清楚地看到很多BLOCKED线程正在等待获取对象监视器上的锁。
对JVM线程转储的分析清楚地揭示了问题所在:线程锁争用。 从执行堆栈跟踪中我们可以看到JBoss将类的加载委托给JDK ClassLoader ...为什么? 这是因为检测到我们错误的Java类名称是系统类路径的一部分,例如java。*。 在这种情况下,JBoss将把加载委托给系统类加载器,从而触发该特定类名称的系统同步,并等待来自其他线程的服务员等待获取锁以加载相同的类名称。
许多线程正在等待获取LOCK 0x00000000ab84c0c8…
"default task-15" prio=6 tid=0x0000000014849800 nid=0x2050 waiting for monitor entry [0x000000001009d000] java.lang.Thread.State: BLOCKED (on object monitor) at java.lang.ClassLoader.loadClass(ClassLoader.java:403) - waiting to lock <0x00000000ab84c0c8> (a java.lang.Object)// Waiting to acquire a LOCK held by Thread “default task-20” at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) // JBoss now delegates to system ClassLoader.. at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:371) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:186) at org.jboss.tools.examples.rest.MemberResourceRESTService.SystemCLFailure(MemberResourceRESTService.java:176) at org.jboss.tools.examples.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.SystemCLFailure(Unknown Source) at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601)
……………………..
罪魁祸首线程–默认任务20
"default task-20" prio=6 tid=0x000000000e3a3000 nid=0x21d8 runnable [0x0000000010e7d000] java.lang.Thread.State: RUNNABLE at java.lang.Throwable.fillInStackTrace(Native Method) at java.lang.Throwable.fillInStackTrace(Throwable.java:782) - locked <0x00000000a09585c8> (a java.lang.ClassNotFoundException) at java.lang.Throwable.<init>(Throwable.java:287) at java.lang.Exception.<init>(Exception.java:84) at java.lang.ReflectiveOperationException.<init>(ReflectiveOperationException.java:75)
at java.lang.ClassNotFoundException.<init>(ClassNotFoundException.java:82) // ClassNotFoundException! at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:423) - locked <0x00000000ab84c0e0> (a java.lang.Object) at java.lang.ClassLoader.loadClass(ClassLoader.java:410)
- locked <0x00000000ab84c0c8> (a java.lang.Object) // java.lang.ClassLoader: LOCK acquired at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:371) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:186) at org.jboss.tools.examples.rest.MemberResourceRESTService.SystemCLFailure(MemberResourceRESTService.java:176) at org.jboss.tools.examples.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.SystemCLFailure(Unknown Source)
…………………………………
现在,让我们用标记为“应用程序”包的一部分的Java类替换我们的类名称,然后在相同的负载条件下重新运行测试。
String className = "org.ph.WrongClassName";
Class.forName(className);
如我们所见,我们不再处理阻塞的线程……为什么呢? 让我们看一下JVM线程转储,以更好地了解这种行为变化。
"default task-51" prio=6 tid=0x000000000dd33000 nid=0x200c runnable [0x000000001d76d000] java.lang.Thread.State: RUNNABLE at java.io.WinNTFileSystem.getBooleanAttributes(Native Method) // IO overhead due to JAR file search operation at java.io.File.exists(File.java:772) at org.jboss.vfs.spi.RootFileSystem.exists(RootFileSystem.java:99) at org.jboss.vfs.VirtualFile.exists(VirtualFile.java:192) at org.jboss.as.server.deployment.module.VFSResourceLoader$2.run(VFSResourceLoader.java:127) at org.jboss.as.server.deployment.module.VFSResourceLoader$2.run(VFSResourceLoader.java:124) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.as.server.deployment.module.VFSResourceLoader.getClassSpec(VFSResourceLoader.java:124) at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:252) at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76) at org.jboss.modules.Module.loadModuleClass(Module.java:526) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:189) // JBoss now fully responsible to load the class at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) // Unchecked since using JDK 1.7 e.g. tagged as “safe” JDK at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:186) at org.jboss.tools.examples.rest.MemberResourceRESTService.AppCLFailure(MemberResourceRESTService.java:196) at org.jboss.tools.examples.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.AppCLFailure(Unknown Source) at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source)
……………….
上面的执行堆栈跟踪非常揭示:
- 由于未检测到Java类名称是Java系统包的一部分,因此不会执行ClassLoader委派,因此不会进行同步。
- 由于JBoss认为JDK 1.7+是“安全的” JDK,因此使用了ConcurrentClassLoader .performLoadClassUnchecked()方法,而不触发任何对象监视器锁定。
- 没有同步意味着由于不间断的ClassNotFoundException错误而没有触发线程锁争用。
仍然需要注意的是,尽管在这种情况下JBoss在防止线程锁争用方面做得很出色,但是由于与过多的JAR文件搜索操作相关的IO开销,重复的类加载尝试仍会在一定程度上降低性能。加强了立即采取纠正措施的需要。
最后的话
我希望您喜欢这篇文章,并且现在对由于过多的类加载操作而可能对性能产生的影响有了更好的了解。 尽管JDK 1.7和现代Java EE容器在类加载器相关问题(例如死锁和线程锁争用)上带来了很大的改进,但仍然存在潜在的问题场景。 因此,我强烈建议您密切监视应用程序的行为,记录日志,并确保积极纠正与类加载器相关的错误,例如java.lang.ClassNotFoundException和java.lang.NoClassDefFoundError 。
我期待您的意见,并请与Java类加载器分享您的故障排除经验。
翻译自: https://www.javacodegeeks.com/2014/04/classnotfoundexception-is-it-slowing-down-your-jvm.html