并发类加载引起的死锁

最新推荐文章于 2023-05-13 11:09:56 发布
最新推荐文章于 2023-05-13 11:09:56 发布
阅读量880 收藏
点赞数
分类专栏： java JVM 文章标签： osgi jvm 类加载 死锁
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/roc08/article/details/84611967
版权
JVM 同时被 2 个专栏收录
6 篇文章 0 订阅
订阅专栏
java
2 篇文章 0 订阅
订阅专栏
近来系统启动经常出现卡死现象，要启动几次才能起来，由于是OSGi环境，系统启动时会加载大量的类，并且由不同classloader加载，因此怀疑是类加载死锁，通过jconsole看到进程间相互等待的现象，通过dump 得到很多进程block的信息，分析找到问题位置
xxxxx.base.dao.Activator.registerPOJO在注册po时发生了死锁。由于使用OSGi时hibernate并不支持osgi环境，因此po的加载注册是平台自己写的。
定位到出现问题的位置后，下面来分析原因，
registerPOJO方法如下，

[img]http://dl2.iteye.com/upload/attachment/0098/7852/14296cbf-fbb0-3f53-8022-b3751f44454d.jpg[/img]

可以看到此方法是synchronized的，应该不会出现死锁，继续看方法中的parseBundleClasses方法

[img]http://dl2.iteye.com/upload/attachment/0098/7854/1ad60d97-9283-3823-88c7-e842d99fc09b.jpg[/img]

注意到此方法中存在synchronized静态变量，因此同时存在了类锁和对象锁，如果有一个线程拿到类锁，另外一个线程拿到对象锁，变出现了死锁，上网搜索发现阿里也出现过这个情况
http://alipaymiddleware.com/%E6%9C%8D%E5%8A%A1%E5%AE%B9%E5%99%A8/osgi%E7%B1%BB%E5%8A%A0%E8%BD%BD%E6%AD%BB%E9%94%81%E5%88%86%E6%9E%90/
文章中给出的解决方法稍后再说，我怀疑还有其他情况导致死锁，我们的po分布的不同的bundle中，但po中使用了枚举类型，而枚举会分布在其他bundle中，因此在加载本bundle的po时需要同时加载其枚举类型，这时会需要其他bundle的加载器进行加载，因此此线程出现阻塞，而其他bundle也需要其他bundle的加载器加载其需要的枚举类型，这样极有可能出现循环等待。
下面说一下解决方法，根据上面文章中提到的，解决的办法就是去掉锁和加锁，
去掉锁就是采用并发加载的方式，不同的线程就不会需要在去获取classloader的对象锁，也就不会有这个死锁的问题，同时并发加载的方式对于系统的性能是有提升的。加锁就是在加载自定义的类的时候也对当前的classloader对象进行加锁，这样可以保证不再出现死锁。
结合我们的实际代码，我觉得适合我们的
去掉锁
如果是jdk1.6可以升级到1.7或者在jvm中加入参数

dump信息

"SpringOsgiExtenderThread-74" prio=5 tid=104 BLOCKED
at java.lang.ClassLoader.checkCerts(ClassLoader.java:782)
at java.lang.ClassLoader.preDefineClass(ClassLoader.java:487)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:625)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2279)
Local Variable: byte[]#2006
Local Variable: java.lang.String#71363
Local Variable: java.lang.String#71364
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1501)
Local Variable: java.util.HashSet#5911
Local Variable: java.lang.String#71365
at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1844)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:937)
at gboat2.base.dao.Activator.parseBundleClasses(Activator.java:314)
Local Variable: org.apache.felix.framework.BundleImpl#35
Local Variable: java.lang.String#70146
Local Variable: java.lang.String#43279
Local Variable: java.util.AbstractList$Itr#23
Local Variable: java.lang.ClassNotFoundException#1
Local Variable: java.util.ArrayList#12164
Local Variable: java.util.AbstractList$Itr#22
Local Variable: java.util.ArrayList#12163
Local Variable: java.lang.String[]#2192
at gboat2.base.dao.Activator.registerPOJO(Activator.java:177)
at gboat2.base.dao.Activator.setApplicationContext(Activator.java:93)
Local Variable: java.util.LinkedHashMap#15659
Local Variable: java.util.LinkedHashMap#15601
at org.springframework.context.support.ApplicationContextAwareProcessor.invokeAwareInterfaces(ApplicationContextAwareProcessor.java:117)
at org.springframework.context.support.ApplicationContextAwareProcessor.postProcessBeforeInitialization(ApplicationContextAwareProcessor.java:92)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:396)
Local Variable: org.springframework.context.support.ApplicationContextAwareProcessor#2
Local Variable: java.util.AbstractList$Itr#24
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1475)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:521)
Local Variable: class gboat2.base.dao.Activator
Local Variable: org.springframework.beans.BeanWrapperImpl#3
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:295)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
Local Variable: org.springframework.beans.factory.support.AbstractBeanFactory$1#3
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:626)
Local Variable: java.util.ArrayList#11365
Local Variable: java.util.AbstractList$Itr#14
Local Variable: org.springframework.beans.factory.support.RootBeanDefinition#642
Local Variable: java.lang.String#55756
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932)
Local Variable: java.lang.String[]#1978
at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$1600(AbstractDelegatedExecutionApplicationContext.java:69)
at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$4.run(AbstractDelegatedExecutionApplicationContext.java:355)
Local Variable: org.springframework.beans.factory.support.DefaultListableBeanFactory#2
at org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)
Local Variable: org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$4#12
Local Variable: org.springframework.osgi.util.BundleDelegatingClassLoader#8
at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.completeRefresh(AbstractDelegatedExecutionApplicationContext.java:320)
Local Variable: org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext#7
at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$CompleteRefreshTask.run(DependencyWaiterApplicationContextExecutor.java:132)
Local Variable: java.lang.Object#341
Local Variable: org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$CompleteRefreshTask#12
at java.lang.Thread.run(Thread.java:662)

参考文档：
http://osdir.com/ml/dev-felix-apache/2009-04/msg00139.html
https://www.mail-archive.com/users@felix.apache.org/msg15209.html
https://bugs.eclipse.org/bugs/show_bug.cgi?id=121737
http://alipaymiddleware.com/%E6%9C%8D%E5%8A%A1%E5%AE%B9%E5%99%A8/osgi%E7%B1%BB%E5%8A%A0%E8%BD%BD%E6%AD%BB%E9%94%81%E5%88%86%E6%9E%90/
关于类加载的并发控制锁（ClassLoadingLock）
黄智霖的博客
03-16 1万+
死锁 在JDK1.7以前，java.lang.ClassLoader的一些核心方法是被synchronized修饰的，比如loadClass，以下摘自JDK6下java.lang.ClassLoader的部分方法： protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {...} private synchronized Class loa
多线程复习总结之死锁与上下文切换
weixin_45974176的博客
02-16 594
详细介绍了死锁以及上下文切换
类加载器死锁问题
远方的少年
06-16 428
类加载器在加载类时会加锁，当循环加载类时就可能会导致死锁问题，如下示例: public class TestDeadLock { static class A { static { System.out.println("cinit A"); try { TimeUnit.SECONDS.sleep(1); }catch (InterruptedExcepti...
刨根问底-JVM类加载死锁
香农三定律的博客
03-08 661
刨根问底-JVM类加载死锁引言类加载中的初始化类加载中的死锁 引言 单例模式大家都了解，其中懒汉式如下： public class Singleton { private static Singleton singleton; private Singleton(){} public static Singleton getInstance(){ if(singleton == null){ si
把锁的级别从ClassLoader对象本身，降低为要加载的类名这个级别，目的是从底层避免以上这类死锁出现的可能 具体是什么意思？
liuruiaaa的博客
03-01 277
把锁的级别从ClassLoader对象本身，降低为要加载的类名这个级别，目的是从底层避免以上这类死锁出现的可能 具体是什么意思？
classesloader死锁
yyqhwr的博客
10-21 213
public abstract class NestedRuntimeException extends RuntimeException {          private static final long serialVersionUID = -8196151131036307843L;          static{         //加载NestedExceptionUtils类，...
JVM---jstack分析Java线程CPU占用,线程死锁的解决
10-14
Java虚拟机（JVM）是Java程序运行的基础，它负责管理程序的内存、线程以及类加载等核心功能。在开发和运维过程中，有时会遇到Java应用的性能问题，如线程CPU占用过高或者线程死锁。这时，我们就需要用到JVM提供的...
MySQL数据导入锁机制：避免死锁和提高并发性，提升导入效率
[MySQL数据导入锁机制：避免死锁和提高并发性，提升导入效率](https://img-blog.csdnimg.cn/20200627223528313.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG...
并发带来的问题
阿轩的博客
01-01 2227
1.并发带来的问题 并发编程的目的是为了让程序运行的更快的，但是，是不是启动更多的线程就能让程序最大幅度地并发执行？这个问题值得我们深思。 而我们一旦通过多线程去使得程序运行的更快，那么就会遇到几个问题： 上下文切换 死锁 硬件和软件的资源限制 那么当我们出现这些问题的时候，该如何去解决或者是避免呢？ 1.1.上下文切换 1.1.1.解释上下文切换并说明其问题 首先，想一个问题，为什么当我们使用多个线程并发执行的时候，为什么感觉到像是同时执行呢？ 通过我们学习的操作系统的知识来看，当进程从就绪到执行状态
Redis(九)：并发问题
weixin_43844995的博客
03-20 1223
上一篇介绍了 Redis 的内存管理。这节开始介绍 Redis 并发方面的问题。Redis 的单个命令是原子的，但是一个业务操作可能包含多条命令，比如以下场景：客户端查询值，并递增，在高并发场景下就可能出现并发问题，导致数据不一致。为了保证并发访问的正确性，Redis 提供了三种方法，原子操作、分布式锁、事务。本文介绍了 Redis 应对并发问题的三种方案，Redis 中的单条命令都是原子操作，而且还有 INCR/DECR 来应对简单的场景。
JVM（三）：自定义ClassLoader 及 类并发加载问题
天涯明月
09-04 2915
问题： 　　目前大部分JVM实现都采用延迟加载的策略，在运行时，当需要用到某个类时才会去真正装载该类。当JVM加载某个类时，会提取出其中的类型信息存储在方法区中，类的静态变量也同样存在该方法区中，虽然JVM内部以什么样的数据结构来存储类型信息，依赖于JVM的具体实现，但从存储的信息基本是一样的，比如类的基本信息(完全限定名称、父类信息、加载器信息等等)、常量池、字段信息、方法信息（签名、字节码流、...
类加载-java.lang.ClassLoader
致终将逝去的编程青春
01-10 2973
ClassLoader是什么？ Class代表它的作用对象是类，Loader代表它的功能是加载，那么ClassLoader就是把一个以.class结尾的文件以JVM能识别的存储形式加载到内存中。 类加载过程 一个类在被使用之前，会经历class文件生成—>加载—>连接—>初始化等阶段。这些阶段组合起来为完整的类加载过程，其中加载阶段主要完成三件事： 通过类的全限定名来获取定义次类的二
JAVA类加载机制之Classloader以及打破加载机制的方式
m0_64262620的博客
01-04 1006
在jDK1.8中,Classloader加载class的字节码到JVM,它是遵循双亲委派模型的加载机制，主要是由BootstrapClassLoader，ExtClassLoader、AppClassloader，然后是自定义的Classloader加载，这样做主要是保证JDK的内部类加载安全性，所以优先加载JDK的ClassPath的jar包的类.双亲委派模型的如下图所示，其实就是由两级父Classloader加载，分别是BootstrapClassloader和ExtClassloader。 JDK的
Java类加载与锁
可口可乐的博客
04-01 947
本文写作的灵感来自Pierre-Hugues Charbonneau的为什么加载不存在的类会影响系统性能一文。这让我想起了之前的一次调试经历，当时也遇到了类似的问题，只不过表现略有不同。 　　出问题的应用程序是Yet Another Webapp，不管什么脏活累活它都接。直到干趴下为止。它这的症状是，终端用户抱怨说应用很慢，经常超时。我从日志文件中倒没发现什么异常，不过能够看出用户体验确实是下降
一次jdk 1.7 永久带oom信息定位
weixin_33940102的博客
11-13 269
为什么80%的码农都做不了架构师？>>> ...
java.lang.ClassLoader.loadClass
HelloJava1234的专栏
03-08 638
loadClass protected Class&lt;?&gt; loadClass(Stringname, booleanresolve) throws ClassNotFoundException 使用指定的二进制名称来加载类。此方法的默认实现将按以下顺序搜索类： 调用...
Java classload 机制 详解
最新发布
2301_77783312的博客
05-13 1765
所以，可以很清楚的看到，加载一个类的过程，它是层层的像父类委托，然后在层层的向下加载。类加载器在尝试自己去查找某个类的字节代码并定义它时，会先代理给其父类加载器，由父类加载器。应该检查抛出异常的类的类加载器和当前线程的上下文类加载器，从中可以发现问题的所在。它也不能代理给系统类加载器，因为它是系统类加载器的祖先类加载器。当出现找不到类的错误时，检查当前类的类加载器和当前线程的上下文类加载器是否正确。要加载类的接口，加载该接口的子类时，可以用接口引用，而不需要利用反射来实现。虚拟机来说，它们是不同的类。
Java安全编程需要考虑的问题
尘世中迷途小码农的专栏
12-08 5077
这篇文章简要讨论了Java安全编程需要考虑的若干问题，通过对这些问题的深入理解，能够帮助我们在实际编码过程中避免出现安全相关的问题，从而提高代码质量。 由于时间关系，没有给出每个场景的示例代码，仅说明了该场景可能出现的安全问题以及对应的解决办法。 概述 一般而言，安全编程的目标有以下三点： 机密性 完整性 可用性 机密性要求数据不被他人轻易获取，需要进行数据加密。 完整性要求数据不被他人随意修改，需要进行指纹计算。 可用性要求服务不被他人恶意攻击，需要进行数据校验。 在Java中，安全.
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值