制作化妆品网站,淮北市做网站最好的公司,怎么免费建设金融网站,WordPress插件对seo的影响Spring MVC是美团点评很多团队使用的Web框架。在基于Spring MVC的项目里#xff0c;注解的使用几乎遍布在项目中的各个模块#xff0c;有Java提供的注解#xff0c;如#xff1a;Override、Deprecated等#xff1b;也有Spring提供的注解#xff0c;如#xff1a;Control… Spring MVC是美团点评很多团队使用的Web框架。在基于Spring MVC的项目里注解的使用几乎遍布在项目中的各个模块有Java提供的注解如Override、Deprecated等也有Spring提供的注解如Controller、Service、Autowired等同时还可能有自定义注解等。注解一方面可以作为标记说明使用另一方面也能帮助我们省去一些配置工作加快开发速度。注解就像语法糖一样我有时候会“随心所欲”的把它带入到代码里一直乐 (hú)此(lǐ)不(hú)疲(tú)。直到笔者遇到了一个由Service注解引发的空指针问题时才真正意识到乱用注解的危害同时也有了下文的深入探讨 事件起因 接到业务方需求需要封装上游的一个HTTP接口来提供系统内的服务支持我封装这个接口并通过本地单元测试后就部署到测试环境中开始测试了。没想到一测试就报NullPointerException异常异常栈信息如下 ERROR [qtp384587033-86] 2015-12-21 16:29:00.905 com.meituan.trip.mobile.hermes.common.utils.HttpClientUtils.doRequest(HttpClientUtils.java:359) HttpClientUtils.doRequest invoke get error, url:nullmt/api/test/v1/query?id123456org.apache.http.client.ClientProtocolExceptionat org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186) ~[httpclient-4.3.5.jar:4.3.5]…Caused by: org.apache.http.ProtocolException: Target host is not specified...从异常栈上可以清楚的看出错误原因是由于请求地址不标准以 http:// 开头导致的。这个错误其实很诡异因为我已经在配置文件中通过XML的方式注入URL属性值了而且在本地写单元测试都能通过为什么还会属性注入失败呢经过反复的检查和尝试发现只要在class的定义上加Service注解问题就会重现去掉则正常运行。 问题定位 在保留Service注解的情况下重新在本地部署并启动工程从启动日志上发现此实现Bean被替换过 INFO [main] 2015-12-21 16:28:47.078 org.springframework.beans.factory.support.DefaultListableBeanFactory.registerBeanDefinition(DefaultListableBeanFactory.java:665) Overriding bean definition for bean queryPartnerImpl: replacing [Generic bean: class [com.meituan.trip.mobile.hermes.sal.meilv.impl.QueryPartnerImpl]; scopesingleton; abstractfalse; lazyInitfalse; autowireMode0; dependencyCheck0; autowireCandidatetrue; primaryfalse; factoryBeanNamenull; factoryMethodNamenull; initMethodNamenull; destroyMethodNamenull; defined in file [/Users/hanzhankang/hermes/hermes-sal/target/classes/com/meituan/trip/mobile/hermes/sal/meilv/impl/QueryPartnerImpl.class]] with [Generic bean: class [com.meituan.trip.mobile.hermes.sal.meilv.impl.QueryPartnerImpl]; scope; abstractfalse; lazyInitfalse; autowireMode0; dependencyCheck0; autowireCandidatetrue; primaryfalse; factoryBeanNamenull; factoryMethodNamenull; initMethodNamenull; destroyMethodNamenull; defined in class path resource [sal/service-outer.xml]]Spring Bean发生替换是因为在同一个WebApplicationContext下重复注入同一名称的Bean实例。从上面的日志中我们可以看出queryPartnerImpl对象最终保留的是通过[sal/service-outer.xml]配置文件注入的Bean在这个配置文件里详细的设置了相关属性。从替换结果来看即使发生过替换也不会影响程序到正确运行。那问题会出在哪里呢 经过反复调试发现只要在QueryPartnerImpl类的定义前面加上Service注解问题就会重现。 问题排查及解决 遇到如此诡异的问题且又不能确定此问题是否是系统其他环境配置导致的时候不妨可以从这个类在系统中的实例对象身上着手分析最简单的办法是通过Jmap查询系统中的对象实例个数。 使用Jmap查询QueryPartnerImpl类在系统中的实例个数及结果Jmap是JDK自带的堆分析工具Java Memory Map可以通过此工具打印出某个Java进程内存内的所有对象大小和数量建议在测试环境中使用jmap -histo:live命令查询执行此命令会触发一次Full GC $ jmap -histo:live 20881 | grep QueryPartnerImpl1354: 2 80 com.meituan.trip.mobile.hermes.sal.meilv.impl.QueryPartnerImpl查看发现系统中居然有2个实例这和我们对“Spring创建Bean默认是单例的”认知不符那就把进程Dump出来详细解刨下这2个对象吧通过Jmap的dump参数把进程镜像dump出来 $ jmap -dump:formatb,file/tmp/heap.bin 20881Dumping heap to /private/tmp/dump.data ...Heap dump file created此时可以使用MAT内存分析工具Memory Analysis Tool并配合Jhat快速定位到此类的实例对象上通过对象间的引用关系来查找定位原因。 首先通过Jhat工具来查看QueryPartnerImpl对象及对象间的引用关系 $ jhat /tmp/heap.bin...........................................................................Snapshot resolved.Started HTTP server on port 7000Server is ready.Jhat是JDK自带的堆分析工具Java Heap Analyse Tool可以将堆中的对象以HTML的形式显示出来包括对象的数量、大小等默认端口7000。 通过Jhat加载dump文件成功后访问localhost:7000进入对象列表页此时通过关键字“QueryPartnerImpl”搜索定位到具体的类上再点击进去查看详情 Class 0x6c36938b0class com.meituan.trip.mobile.hermes.sal.meilv.impl.QueryPartnerImplInstances 类的实例Exclude subclassesInclude subclassesReferences summary by Type对象的引用关系References summary by type点击链接Instances - Exclude subclasses查看类的实例对象 com.meituan.trip.mobile.hermes.sal.meilv.impl.QueryPartnerImpl0x6c41b6f80 (64 bytes) com.meituan.trip.mobile.hermes.sal.meilv.impl.QueryPartnerImpl0x7aeafac20 (64 bytes) 这2个就是QueryPartnerImpl在系统中创建的2个实例对象点击查看每个对象属性注入情况 QueryPartnerImpl0x6c41b6f80 (64 bytes)
属性
clientId (L) : trip_trade (28 bytes)
clientSecret (L) : 6ee952489a93b51b1ffcadd040ca562e (28 bytes)
connectTimeout (I) : 15000
encode (L) : UTF-8 (28 bytes)
log (L) : org.apache.logging.slf4j.Log4jLogger0x6c3f26240 (41 bytes)
readTimeout (I) : 15000
url (L) : http://test.url.meituan.com/ (28 bytes)引用关系
com.meituan.trip.mobile.hermes.biz.cs.GroupTravelCsOrderDetailBiz0x6c41b6f60 (48 bytes) : field queryPartnerImpl
java.util.concurrent.ConcurrentHashMap$Node0x6c4420fe8 (44 bytes) : field val
org.springframework.beans.factory.support.DisposableBeanAdapter0x6c41b79f0 (66 bytes) : field bean
com.meituan.trip.mobile.hermes.biz.driven.listener.snapshot.GroupTravelOrderSnapshotEventListener0x7ae57c490 (96 bytes) : field queryPartnerImpl
com.meituan.trip.mobile.hermes.web.controller.api.ApiAliveController0x6c3619fe8 (24 bytes) : field queryPartnerImplQueryPartnerImpl0x7aeafac20 (64 bytes)
属性
clientId (L) : null
clientSecret (L) : null
connectTimeout (I) : 0
encode (L) : null
log (L) : org.apache.logging.slf4j.Log4jLogger0x6c3f26240 (41 bytes)
readTimeout (I) : 0
url (L) : null
引用关系
org.springframework.beans.factory.support.DisposableBeanAdapter0x7aeccfd40 (66 bytes) : field bean
java.util.concurrent.ConcurrentHashMap$Node0x7aeb05b18 (44 bytes) : field val
com.meituan.trip.mobile.hermes.biz.cs.GroupTravelCsOrderDetailBiz0x7aeafab88 (48 bytes) : field queryPartnerImpl
com.meituan.trip.mobile.hermes.web.controller.api.ApiAliveController0x7aeb80228 (24 bytes) : field queryPartnerImpl
com.meituan.trip.mobile.hermes.biz.driven.listener.snapshot.GroupTravelOrderSnapshotEventListener0x7aeb03908 (96 bytes) : field queryPartnerImpl结果发现QueryPartnerImpl0x6c41b6f80对象的属性是注入成功的而QueryPartnerImpl0x7aeafac20对象的属性却注入失败。从这里可以初步判断导致错误的原因是我们使用的对象是属性注入失败的QueryPartnerImpl0x7aeafac20。 问题排除到这里我们不禁有2个疑问 1为什么会出现2个对象 从Spring启动日志看到queryPartnerImpl有被替换的情况其实替换的结果是把通过Service注入的Bean替换成了用XML定义并注入的Bean这也只能有1个对象另一个对象怎么出现的 2谁在使用这2个对象 既然错误已成事实那是谁在使用这个属性注入失败的QueryPartnerImpl0x7aeafac20呢而且我们每次都是使用它而不是属性注入成功的QueryPartnerImpl0x6c41b6f80。 通过Jhat展示的对象引用关系看只有org.springframework.beans.factory.support.DisposableBeanAdapter和java.util.concurrent.ConcurrentHashMap$Node 比较可疑。但DisposableBeanAdapter是用来管理Spring Bean的销毁所以和本事故无关重点就落在java.util.concurrent.ConcurrentHashMap$Node 上了。 通过MAT工具来分析java.util.concurrent.ConcurrentHashMap$Node0x7aeb05b18的引用关系通过对象查找工具并输入对象的内存地址定位 可直接查看此对象 选中这个对象右键打开菜单选项选择Lists objects - with incoming references查看都有哪些对象持有此对象with outgoing references表示此对象拥有哪些对象 通过上面对象引用追踪路径可以看到queryPartnerImpl0x7aeafac20最终被DispatcherServlet0x7ae577e00对象引用。 采用同样的方式来分析queryPartnerImpl0x6c41b6f80的对象引用关系 queryPartnerImpl0x6c41b6f80最终被ContextLoaderListener0x6c358f7f8引用。 通过对比发现: queryPartnerImpl0x6c41b6f80 被 XmlWebApplicationContext0x6c358f810 引用而 XmlWebApplicationContext0x6c358f810 又被 ContextLoaderListener0x6c358f7f8 引用;
queryPartnerImpl0x7aeafac20 被 XmlWebApplicationContext0x7ae9ca338 引用而 XmlWebApplicationContext0x7ae9ca338 又被 DispatcherServlet0x7ae577e00 引用。ContextLoaderListener和DispatcherServlet对我们来说非常熟悉这是在Spring MVC项目中的web.xml中配置的ContextLoaderListener用来初始化root WebApplicationContextDispatcherServlet是请求分发控制器启动时也会初始化一个自己的WebApplicationContext并设置parent为root WebApplicationContext从而形成常说的“父子关系”。DispatcherServlet如果在自己的WebApplicationContext能找到需要用的对象就直接使用只有在找不到对象的情况下才会去查找父容器里的。 到这里我们找到了引起事故发生的根本原因但是我们还需要找出引发事故的罪魁祸首通过前面的分析我们知道这和ContextLoaderListener、DispatcherServlet有关系那就定位到web.xml的配置文件中来 在spring/spring-servlet.xml配置文件中我们开启了注解扫描功能并且从项目路径“com.meituan.trip.mobile.hermes”开始扫描 我们知道Spring会通过Service注解去实例化一个Bean属性如果没有通过注解注入进来的话就用默认值。在此配置文件后面就再没有对queryPartnerImpl的定义也就不会发生替换的情况。DispatcherServlet只能获得由注解加载的半成品Bean。 再来看看ContextLoaderListener的配置文件applicationContext.xml 我们在applicationContext.xml中也同样开启了注解扫描功能也是从项目路径“com.meituan.trip.mobile.hermes”开始扫描但是在下文的sal/service-out.xml配置文件中又重新对queryPartnerImpl通过XML定义所以会发生替换现象。 到这里我们才最终搞清楚发生这次事故的最根本原因解决办法是要让整个系统中只有一个属性注入成功的queryPartnerImpl对象途径有如下几种 1删除Service注解这个方法治标不治本因为配置context:annotation-config/、context:component-scan 注解扫描功能后会开启包括Service在内的超过6种注解而这些注解部分在用 2扫描隔离通过配置context:component-scan的属性use-default-filters并配合include-filter/exclude-filter实现扫描过滤只扫描指定注解。 修改后的spring-servlet.xml配置applicationContext.xml配置也需要做调整 use-default-filterstrue表示Spring将会创建那些被Component, Repository, Service 或 Controller等注解标注的Bean默认值为true。如果use-default-filterstrue同时使用context:exclude-filter并指定注解类表示不扫描指定base-package路径下的此注解如果use-default-filtersfalse同时使用context:include-filter并指定注解类表示扫描指定base-package路径下面的此注解。 问题总结 使用注解并不一定会引起错误但是注解要使用规范不能乱用。如果通过注解注入属性值最好也要通过注解方式注入注解扫描功能虽然很强大、很方便但是要注意区分扫描范围及过滤特定注解单元测试能通过的原因我们一般只指定加载一个配置文件作为测试环境类实例只会出现一个故能测试通过最好最重要的一点就是在使用任何框架时最好按”Best Practice”规范避免出现一些莫名其妙的问题。进一步探讨 通过阅读Spring源码中涉及ContextLoaderListener和DispatcherServlet的部分学习到ContextLoaderListener在Context初始化的时候会创建一个root WebApplicationContext并将此对象存储在ServletContext中Key为WebApplicationContext.class.getName() “.ROOT”DispatcherServlet在初始化过程也实例化了一个自己的WebApplicationContext设置在ServletContext中的key为 FrameworkServlet.class.getName() “.CONTEXT.” getServletName()同时设置此对象的parent为 ContextLoaderListener定义的 root WebApplicationContext。DispatcherServlet所创建的WebApplicationContext被称为子容器子容器可以访问父容器中的内容但父容器不能访问子容器中的内容。 Spring官方在介绍Spring MVC的同时也给我们介绍了WebApplicationContext的继承关系 从图中可以看出每个DispatcherServlet都会去实例化一个自己的WebApplicationContext而这个WebApplicationContext可以获得root WebApplicationContext中已经实例化好的Bean。 参考文献 Spring Web MVC框架文档
