标签：流程 ima 重试 启动 相等 说话 ota blog autowired
背景某天运营反馈，点了一次保存，但是后台出现了3条数据，我当时就想，不应该啊，这代码我几万年没动了，我当时就叫他先别操作了，保留一下现场，我去排查一下。
我看了下新增的代码，直接右键查看作者
没想到三歪做过改动，我就去问三歪，XX模块的新增代码你是不是动过？
他沉默了很久没说话，然后抓起桌子上用剩下来的纸擦了擦鬓角留下的汗水，咽了一下口水说，是的我改过，我把之前dubbo的xml配置方式改成了注解的方式。
怎么了？现在出BUG了？
你呀你，下次这种改动跟我说一下，我估计是dubbo源码的bug吧，不要慌，让我去看看什么问题。
其实dubbo配置的方式有很多种，大家用的最多的就是xml配置的方式，如果不需要重试次数，我们会加上重试次数为0，因为他默认是有多次的。
<dubbo:reference id="testService" interface="heiidea.trade.service.sdk.interfice.TestService" retries="0"/> 或者使用注解的方式
@Reference(retries =0) 其实我已经大概知道是什么原因了，但是为了证实自己的猜想，于是开启了接下来的debug之旅~~~br/>注：dubbo版本：2.6.2
首先是在采用@Reference注解条件下：
br/>采用@Reference注解配置重试次数
首先是都找到了dubbo重试的代码位置（启动dubbo项目，到调用接口时，F5进入方法，会跳转到InvokerInvocationHandler中的invoke方法中，继续跟踪进入MockClusterInvoker中的invoke方法，然后进入AbstractClusterInvoker中的invoke方法中，这里主要是拿到配置的负载均衡策略，后面会到FailoverClusterInvoker的doInvoke方法中）。br/>重点来了，这里会获取配置的retries值，可以看到上面配置的是0，但是取出来居然是null，如图：
value为null
所以会返回defaultValue，加上本身调用的那一次，计算之后就会为3，如图：
值为3
所以可以发现，采用@Reference注解的形式配置retries为0时，dubbo重试次数为2次（3中包含本身调用的那次）。
后面是采用 dubbo:reference 标签的方式：
dubbo标签方式
方式如上，在获取属性的时候，可以看到获得的值为0，和注解形式配置的一致，如图：
value为0
加上本身调用的那一次，计算之后就会为1，如图：
value为1
所以可以发现，采用 dubbo:reference 标签形式配置retries为0时，dubbo重试次数为0（1为本身调用的那次）。
dubbo会把每个接口先解析为ReferenceBean，加上ReferenceBean实现了FactoryBean接口，所以在注入的时候，会调用getObject方法，生成代理对象。br/>但是这不是关键，因为到这一步时，所有的属性都已经加载完成，所以需要找到dubbo解析注解中属性的代码位置。
dubbo会使用自定义驱动器ReferenceAnnotationBeanPostProcessor来注入属性，而具体执行注入的代码位置是在ReferenceAnnotationBeanPostProcessor类的postProcessPropertyValues方法中调用inject方法执行的。
重点来了，因为采用标签时，是采用@Autowired注解注入，所以是采用spring原生方式注入，而在采用@Reference注解时，注入时会走到dubbo自己的ReferenceAnnotationBeanPostProcessor中私有内部类ReferenceFieldElement的inject方法中，然后调用buildReferenceBean创建ReferenceBean。
离原因越来越近了，在该方法中可以看到beanBuilder中的retries值还是0，说明到这一步还没有被解析为null，如图：
retries为“0”
继续往下走，调用build方法中的configureBean时，在第一步preConfigureBean中方法，在该方法中会创建AnnotationPropertyValuesAdapter对象，在该对象构造方法中会调用adapt方法，然后走到AnnotationUtils中的getAttributes方法中，有一个关键方法nullSafeEquals，该方法会传入当前属性值和默认值。
如果相等，则会忽略掉该属性，然后将符合条件的属性放入actualAttributes这个map中，而我们的retries属性是0，和默认值一致，所以map中不会保存retries属性的值，只有timeout属性，因此出现了后面获取的值为null。
注解方式debug告一段落。
map不包含retries
上面说到了，标签形式走到inject时，会和注解形式有所不同，采用该标签时，dubbo会使用自定义的名称空间解析器去解析，很容易理解，spring也不知道它自定义标签里面那些玩意儿是什么意思，所以dubbo会继承spring的。
NamespaceHandlerSupport，采用自定义的DubboNamespaceHandler解析器来解析的标签，如下图：
dubbo自定义名称空间解析器
然后调用该类中的parse方法进行解析，而解析retries的地方就是获取class（此时的class就是上图绿色标明的ReferenceBean的class，其父类中有好多好多set方法，其中就包含setRetries方法）中所有的方法，过滤出set开头的方法，然后切割出属性名，放入属性池中，可以看到此处解析出的值为0，并不为null，如下图：
获取属性名的位置
获取retries值为0
画个简单图：
大致流程
标签：流程 ima 重试 启动 相等 说话 ota blog autowired
原文地址：https://blog.51cto.com/14689292/2545771
value为null所以会返回defaultValue，加上本身调用的那一次，计算之后就会为3，如图：值为3所以可以发现，采用@Reference注解的形式配置retries为0时，dubbo重试次数为2次（3中包含本身调用的那次）。后面是采用 dubbo:reference 标签的方式：](mailto:br/>重点来了，这里会获取配置的retries值，可以看到上面配置的是0，但是取出来居然是null，如图：<br/><br/>value为null<br/>所以会返回defaultValue，加上本身调用的那一次，计算之后就会为3，如图：<br/><br/>值为3<br/>所以可以发现，采用@Reference注解的形式配置retries为0时，dubbo重试次数为2次（3中包含本身调用的那次）。<br/){kind=link}