诡异的SPRING IOC容器

SPRING已经几乎成为我们日常开发必不可少的框架了,它对IOC以及AOP思想的实现得到了广泛的认可和推崇。
IOC作为一个容器,管控了大部分运行期的JAVA对象,由于IOC的高可配置性,使得传统的JAVA工厂模式,单例模式几乎不再出现于代码中。

然而本文的标题何故冠以诡异二字,这还得从一次项目组遇到的问题说起。

这个项目不无例外地使用了SPRING框架。然而在应用启动一段时间后,原本运行中没问题的一些对象,会忽然“无故”地报错找不到,出现Spring容器getBean失败。而这些对象在应用重启以后又是可以找到的!这使得项目组的同事百思不得其解。而且出现这些对象不见的时机也很蹊跷,时而隔天出现,时而隔一小时就报错。
此时,传说中的神器SPRING仿佛成了一个难以捉摸的幽灵,IOC容器则成了一个黑洞,时不时地把对象给吞了,不得不说诡异二字。真的是这样么,我们展开了一番排摸。

我们发现,当出现对象找不到的情况时,去获取这些对象用的是一个ApplicationContextUtil工具类,这个工具类继承实现了Spring的ApplicationContextAware,并且注册到IOC的配置XML里,按照SPRING的加载机制,会自动把ApplicationContext交到ApplicationContextUtil手里。而这次,这个工具好像出问题了。
同时我们又发现,在这种情况下,使用WebApplicationContextUtils.getWebApplicationContext(ServletContext sc)来获取ApplicationContext的时候,这些丢失的类都还在里面!

至此,问题是不是变得更为扑朔迷离?还是渐渐有了头绪?

这种情况下,感觉可能是运行期存在了多个IOC容器。经过代码排查,果然发现在这个项目引用JAR包的一个工具类里,存在这样的写法:
private static final String CONTEXT_FILE_NAME = "/applicationContext-service.xml";

private static ApplicationContext fac=null;

public AdapterServiceFactory(String str) {
fac = new ClassPathXmlApplicationContext(
CONTEXT_FILE_NAME);
((AbstractApplicationContext) fac).registerShutdownHook();
this.serviseName=str;
}
也就是说,一旦利用这个工具获取对象,就会产生一个额外的IOC容器。
如此这个问题就变得很明了了,IOC容器没有错,错的是运行期产生了多个IOC容器。
新容器产生的同时,将实现了ApplicationContextAware的工具类ApplicationContextUtil中的ApplicationContext给覆盖了,因此ApplicationContextUtil只能读到applicationContext-service.xml这个文件中的配置类,而其他对象都丢失了。但在使用WebApplicationContextUtils这个方法的时候,取得的IOC容器是另一个,这个时候,其他的对象都还在!而这一切都是要看这个新的IOC容器何时产生,因此出现问题的时间是随机的。在出现问题后重启应用,则暂时只会存在一个IOC容器,看似一切正常。

终于,诡异的疑云消散了。之后就是对于这个问题的改造了。
改造就很简单了,将在代码中生成IOC容器new ClassPathXmlApplicationContext()的代码去掉,将该类改为实现ApplicationContextAware,通过Spring自身的web加载机制来获的。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值