网站建设费用包括哪些方面,做网站上面图片的软件,更改网站后台,服务器wordpress版本更新大多数Java开发人员都熟悉臭名昭著且非常常见的java.lang.ClassNotFoundException 。 虽然通常已经很好地了解了此问题的根源#xff08;类路径中缺少类/库#xff0c;类加载器委派问题等#xff09;#xff0c;但对整体JVM和性能的影响通常是未知的。 这种情况可能会严重影… 大多数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-RSRESTWeb服务对系统包级别中“定位”的虚拟类名称执行Class.forName 字符串className “ java.lang.WrongClassName”; 类。 forName className; JREHotSpot 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 prio6 tid0x0000000014849800 nid0x2050 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 prio6 tid0x000000000e3a3000 nid0x21d8 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 prio6 tid0x000000000dd33000 nid0x200c 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类加载器分享您的故障排除经验。 参考 ClassNotFoundException是否减慢了JVM的速度 来自我们的JCG合作伙伴 Pierre Hugues Charbonneau来自Java EE支持模式博客。 翻译自: https://www.javacodegeeks.com/2014/04/classnotfoundexception-is-it-slowing-down-your-jvm.html
