【Spring源码分析】AOP源码解析(下篇)

AspectJAwareAdvisorAutoProxyCreator及为Bean生成代理时机分析

上篇文章说了,org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator这个类是Spring提供给开发者的AOP的核心类,就是AspectJAwareAdvisorAutoProxyCreator完成了【类/接口-->代理】的转换过程,首先我们看一下AspectJAwareAdvisorAutoProxyCreator的层次结构:

这里最值得注意的一点是最左下角的那个方框,我用几句话总结一下:

  1. AspectJAwareAdvisorAutoProxyCreator是BeanPostProcessor接口的实现类
  2. postProcessBeforeInitialization方法与postProcessAfterInitialization方法实现在父类AbstractAutoProxyCreator
  3. postProcessBeforeInitialization方法是一个空实现
  4. 逻辑代码在postProcessAfterInitialization方法中

基于以上的分析,将Bean生成代理的时机已经一目了然了:在每个Bean初始化之后,如果需要,调用AspectJAwareAdvisorAutoProxyCreator中的postProcessBeforeInitialization为Bean生成代理

代理对象实例化----判断是否为<bean>生成代理

上文分析了Bean生成代理的时机是在每个Bean初始化之后,下面把代码定位到Bean初始化之后,先是AbstractAutowireCapableBeanFactory的initializeBean方法进行初始化:

 1 protected Object initializeBean(final String beanName, final Object bean, RootBeanDefinition mbd) {
 2     if (System.getSecurityManager() != null) {
 3         AccessController.doPrivileged(new PrivilegedAction<Object>() {
 4             public Object run() {
 5                 invokeAwareMethods(beanName, bean);
 6                 return null;
 7             }
 8         }, getAccessControlContext());
 9     }
10     else {
11         invokeAwareMethods(beanName, bean);
12     }
13
14     Object wrappedBean = bean;
15     if (mbd == null || !mbd.isSynthetic()) {
16         wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);
17     }
18
19     try {
20     invokeInitMethods(beanName, wrappedBean, mbd);
21     }
22     catch (Throwable ex) {
23         throw new BeanCreationException(
24                 (mbd != null ? mbd.getResourceDescription() : null),
25                 beanName, "Invocation of init method failed", ex);
26     }
27
28     if (mbd == null || !mbd.isSynthetic()) {
29         wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
30     }
31     return wrappedBean;
32 }

初始化之前是第16行的applyBeanPostProcessorsBeforeInitialization方法,初始化之后即29行的applyBeanPostProcessorsAfterInitialization方法:

 1 public Object applyBeanPostProcessorsAfterInitialization(Object existingBean, String beanName)
 2         throws BeansException {
 3
 4     Object result = existingBean;
 5     for (BeanPostProcessor beanProcessor : getBeanPostProcessors()) {
 6         result = beanProcessor.postProcessAfterInitialization(result, beanName);
 7         if (result == null) {
 8             return result;
 9         }
10     }
11     return result;
12 }

这里调用每个BeanPostProcessor的postProcessBeforeInitialization方法。按照之前的分析,看一下AbstractAutoProxyCreator的postProcessAfterInitialization方法实现:

1 public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
2     if (bean != null) {
3         Object cacheKey = getCacheKey(bean.getClass(), beanName);
4         if (!this.earlyProxyReferences.contains(cacheKey)) {
5             return wrapIfNecessary(bean, beanName, cacheKey);
6         }
7     }
8     return bean;
9 }

跟一下第5行的方法wrapIfNecessary:

 1 protected Object wrapIfNecessary(Object bean, String beanName, Object cacheKey) {
 2     if (this.targetSourcedBeans.contains(beanName)) {
 3         return bean;
 4     }
 5     if (this.nonAdvisedBeans.contains(cacheKey)) {
 6         return bean;
 7     }
 8     if (isInfrastructureClass(bean.getClass()) || shouldSkip(bean.getClass(), beanName)) {
 9         this.nonAdvisedBeans.add(cacheKey);
10         return bean;
11     }
12
13     // Create proxy if we have advice.
14     Object[] specificInterceptors = getAdvicesAndAdvisorsForBean(bean.getClass(), beanName, null);
15     if (specificInterceptors != DO_NOT_PROXY) {
16         this.advisedBeans.add(cacheKey);
17         Object proxy = createProxy(bean.getClass(), beanName, specificInterceptors, new SingletonTargetSource(bean));
18         this.proxyTypes.put(cacheKey, proxy.getClass());
19         return proxy;
20     }
21
22     this.nonAdvisedBeans.add(cacheKey);
23     return bean;
24 }

第2行~第11行是一些不需要生成代理的场景判断,这里略过。首先我们要思考的第一个问题是:哪些目标对象需要生成代理因为配置文件里面有很多Bean,肯定不能对每个Bean都生成代理,因此需要一套规则判断Bean是不是需要生成代理,这套规则就是第14行的代码getAdvicesAndAdvisorsForBean:

1 protected List<Advisor> findEligibleAdvisors(Class beanClass, String beanName) {
2     List<Advisor> candidateAdvisors = findCandidateAdvisors();
3     List<Advisor> eligibleAdvisors = findAdvisorsThatCanApply(candidateAdvisors, beanClass, beanName);
4     extendAdvisors(eligibleAdvisors);
5     if (!eligibleAdvisors.isEmpty()) {
6         eligibleAdvisors = sortAdvisors(eligibleAdvisors);
7     }
8     return eligibleAdvisors;
9 }

顾名思义,方法的意思是为指定class寻找合适的Advisor。

第2行代码,寻找候选Advisors,根据上文的配置文件,有两个候选Advisor,分别是<aop:aspect>节点下的<aop:before>和<aop:after>这两个,这两个在XML解析的时候已经被转换生成了RootBeanDefinition。

跳过第3行的代码,先看下第4行的代码extendAdvisors方法,之后再重点看一下第3行的代码。第4行的代码extendAdvisors方法作用是向候选Advisor链的开头(也就是List.get(0)的位置)添加一个org.springframework.aop.support.DefaultPointcutAdvisor

第3行代码,根据候选Advisors,寻找可以使用的Advisor,跟一下方法实现:

 1 public static List<Advisor> findAdvisorsThatCanApply(List<Advisor> candidateAdvisors, Class<?> clazz) {
 2     if (candidateAdvisors.isEmpty()) {
 3         return candidateAdvisors;
 4     }
 5     List<Advisor> eligibleAdvisors = new LinkedList<Advisor>();
 6     for (Advisor candidate : candidateAdvisors) {
 7         if (candidate instanceof IntroductionAdvisor && canApply(candidate, clazz)) {
 8             eligibleAdvisors.add(candidate);
 9         }
10     }
11     boolean hasIntroductions = !eligibleAdvisors.isEmpty();
12     for (Advisor candidate : candidateAdvisors) {
13         if (candidate instanceof IntroductionAdvisor) {
14             // already processed
15             continue;
16         }
17         if (canApply(candidate, clazz, hasIntroductions)) {
18             eligibleAdvisors.add(candidate);
19         }
20     }
21     return eligibleAdvisors;
22 }

整个方法的主要判断都围绕canApply展开方法:

 1 public static boolean canApply(Advisor advisor, Class<?> targetClass, boolean hasIntroductions) {
 2     if (advisor instanceof IntroductionAdvisor) {
 3         return ((IntroductionAdvisor) advisor).getClassFilter().matches(targetClass);
 4     }
 5     else if (advisor instanceof PointcutAdvisor) {
 6         PointcutAdvisor pca = (PointcutAdvisor) advisor;
 7         return canApply(pca.getPointcut(), targetClass, hasIntroductions);
 8     }
 9     else {
10         // It doesn‘t have a pointcut so we assume it applies.
11         return true;
12     }
13 }

第一个参数advisor的实际类型是AspectJPointcutAdvisor,它是PointcutAdvisor的子类,因此执行第7行的方法:

 1 public static boolean canApply(Pointcut pc, Class<?> targetClass, boolean hasIntroductions) {
 2     if (!pc.getClassFilter().matches(targetClass)) {
 3         return false;
 4     }
 5
 6     MethodMatcher methodMatcher = pc.getMethodMatcher();
 7     IntroductionAwareMethodMatcher introductionAwareMethodMatcher = null;
 8     if (methodMatcher instanceof IntroductionAwareMethodMatcher) {
 9         introductionAwareMethodMatcher = (IntroductionAwareMethodMatcher) methodMatcher;
10     }
11
12     Set<Class> classes = new HashSet<Class>(ClassUtils.getAllInterfacesForClassAsSet(targetClass));
13     classes.add(targetClass);
14     for (Class<?> clazz : classes) {
15         Method[] methods = clazz.getMethods();
16         for (Method method : methods) {
17             if ((introductionAwareMethodMatcher != null &&
18                 introductionAwareMethodMatcher.matches(method, targetClass, hasIntroductions)) ||
19                     methodMatcher.matches(method, targetClass)) {
20                 return true;
21             }
22         }
23     }
24     return false;
25 }

这个方法其实就是拿当前Advisor对应的expression做了两层判断:

  1. 目标类必须满足expression的匹配规则
  2. 目标类中的方法必须满足expression的匹配规则,当然这里方法不是全部需要满足expression的匹配规则,有一个方法满足即可

如果以上两条都满足,那么容器则会判断该<bean>满足条件,需要被生成代理对象,具体方式为返回一个数组对象,该数组对象中存储的是<bean>对应的Advisor。

代理对象实例化----为<bean>生成代理代码上下文梳理

上文分析了为<bean>生成代理的条件,现在就正式看一下Spring上下文是如何为<bean>生成代理的。回到AbstractAutoProxyCreator的wrapIfNecessary方法:

 1 protected Object wrapIfNecessary(Object bean, String beanName, Object cacheKey) {
 2     if (this.targetSourcedBeans.contains(beanName)) {
 3         return bean;
 4     }
 5     if (this.nonAdvisedBeans.contains(cacheKey)) {
 6         return bean;
 7     }
 8     if (isInfrastructureClass(bean.getClass()) || shouldSkip(bean.getClass(), beanName)) {
 9         this.nonAdvisedBeans.add(cacheKey);
10         return bean;
11     }
12
13     // Create proxy if we have advice.
14     Object[] specificInterceptors = getAdvicesAndAdvisorsForBean(bean.getClass(), beanName, null);
15     if (specificInterceptors != DO_NOT_PROXY) {
16         this.advisedBeans.add(cacheKey);
17         Object proxy = createProxy(bean.getClass(), beanName, specificInterceptors, new SingletonTargetSource(bean));
18         this.proxyTypes.put(cacheKey, proxy.getClass());
19         return proxy;
20     }
21
22     this.nonAdvisedBeans.add(cacheKey);
23     return bean;
24 }

第14行拿到<bean>对应的Advisor数组,第15行判断只要Advisor数组不为空,那么就会通过第17行的代码为<bean>创建代理:

 1 protected Object createProxy(
 2         Class<?> beanClass, String beanName, Object[] specificInterceptors, TargetSource targetSource) {
 3
 4     ProxyFactory proxyFactory = new ProxyFactory();
 5     // Copy our properties (proxyTargetClass etc) inherited from ProxyConfig.
 6     proxyFactory.copyFrom(this);
 7
 8     if (!shouldProxyTargetClass(beanClass, beanName)) {
 9         // Must allow for introductions; can‘t just set interfaces to
10         // the target‘s interfaces only.
11         Class<?>[] targetInterfaces = ClassUtils.getAllInterfacesForClass(beanClass, this.proxyClassLoader);
12         for (Class<?> targetInterface : targetInterfaces) {
13             proxyFactory.addInterface(targetInterface);
14         }
15     }
16
17     Advisor[] advisors = buildAdvisors(beanName, specificInterceptors);
18     for (Advisor advisor : advisors) {
19         proxyFactory.addAdvisor(advisor);
20     }
21
22     proxyFactory.setTargetSource(targetSource);
23     customizeProxyFactory(proxyFactory);
24
25     proxyFactory.setFrozen(this.freezeProxy);
26     if (advisorsPreFiltered()) {
27         proxyFactory.setPreFiltered(true);
28     }
29
30     return proxyFactory.getProxy(this.proxyClassLoader);
31 }

第4行~第6行new出了一个ProxyFactory,Proxy,顾名思义,代理工厂的意思,提供了简单的方式使用代码获取和配置AOP代理。

第8行的代码做了一个判断,判断的内容是<aop:config>这个节点中proxy-target-class="false"或者proxy-target-class不配置,即不使用CGLIB生成代理。如果满足条件,进判断,获取当前Bean实现的所有接口,讲这些接口Class对象都添加到ProxyFactory中。

第17行~第28行的代码没什么看的必要,向ProxyFactory中添加一些参数而已。重点看第30行proxyFactory.getProxy(this.proxyClassLoader)这句:

 1 public Object getProxy(ClassLoader classLoader) {
 2     return createAopProxy().getProxy(classLoader);
 3 }

实现代码就一行,但是却明确告诉我们做了两件事情:

  1. 创建AopProxy接口实现类
  2. 通过AopProxy接口的实现类的getProxy方法获取<bean>对应的代理

就从这两个点出发,分两部分分析一下。

代理对象实例化----创建AopProxy接口实现类

看一下createAopProxy()方法的实现,它位于DefaultAopProxyFactory类中:

1 protected final synchronized AopProxy createAopProxy() {
2     if (!this.active) {
3         activate();
4     }
5     return getAopProxyFactory().createAopProxy(this);
6 }

前面的部分没什么必要看,直接进入重点即createAopProxy方法:

 1 public AopProxy createAopProxy(AdvisedSupport config) throws AopConfigException {
 2     if (config.isOptimize() || config.isProxyTargetClass() || hasNoUserSuppliedProxyInterfaces(config)) {
 3         Class targetClass = config.getTargetClass();
 4         if (targetClass == null) {
 5             throw new AopConfigException("TargetSource cannot determine target class: " +
 6                     "Either an interface or a target is required for proxy creation.");
 7         }
 8         if (targetClass.isInterface()) {
 9             return new JdkDynamicAopProxy(config);
10         }
11         if (!cglibAvailable) {
12             throw new AopConfigException(
13                     "Cannot proxy target class because CGLIB2 is not available. " +
14                     "Add CGLIB to the class path or specify proxy interfaces.");
15         }
16         return CglibProxyFactory.createCglibProxy(config);
17     }
18     else {
19         return new JdkDynamicAopProxy(config);
20     }
21 }

平时我们说AOP原理三句话就能概括:

  1. 对类生成代理使用CGLIB
  2. 对接口生成代理使用JDK原生的Proxy
  3. 可以通过配置文件指定对接口使用CGLIB生成代理

这三句话的出处就是createAopProxy方法。看到默认是第19行的代码使用JDK自带的Proxy生成代理,碰到以下三种情况例外:

  1. ProxyConfig的isOptimize方法为true,这表示让Spring自己去优化而不是用户指定
  2. ProxyConfig的isProxyTargetClass方法为true,这表示配置了proxy-target-class="true"
  3. ProxyConfig满足hasNoUserSuppliedProxyInterfaces方法执行结果为true,这表示<bean>对象没有实现任何接口或者实现的接口是SpringProxy接口

在进入第2行的if判断之后再根据目标<bean>的类型决定返回哪种AopProxy。简单总结起来就是:

  1. proxy-target-class没有配置或者proxy-target-class="false",返回JdkDynamicAopProxy
  2. proxy-target-class="true"或者<bean>对象没有实现任何接口或者只实现了SpringProxy接口,返回Cglib2AopProxy

当然,不管是JdkDynamicAopProxy还是Cglib2AopProxy,AdvisedSupport都是作为构造函数参数传入的,里面存储了具体的Advisor。

代理对象实例化----通过getProxy方法获取<bean>对应的代理

其实代码已经分析到了JdkDynamicAopProxy和Cglib2AopProxy,剩下的就没什么好讲的了,无非就是看对这两种方式生成代理的熟悉程度而已。

Cglib2AopProxy生成代理的代码就不看了,对Cglib不熟悉的朋友可以看Cglib及其基本使用一文。

JdkDynamicAopProxy生成代理的方式稍微看一下:

1 public Object getProxy(ClassLoader classLoader) {
2     if (logger.isDebugEnabled()) {
3         logger.debug("Creating JDK dynamic proxy: target source is " + this.advised.getTargetSource());
4     }
5     Class[] proxiedInterfaces = AopProxyUtils.completeProxiedInterfaces(this.advised);
6     findDefinedEqualsAndHashCodeMethods(proxiedInterfaces);
7     return Proxy.newProxyInstance(classLoader, proxiedInterfaces, this);
8 }

这边解释一下第5行和第6行的代码,第5行代码的作用是拿到所有要代理的接口,第6行代码的作用是尝试寻找这些接口方法里面有没有equals方法和hashCode方法,同时都有的话打个标记,寻找结束,equals方法和hashCode方法有特殊处理。

最终通过第7行的Proxy.newProxyInstance方法获取接口/类对应的代理对象,Proxy是JDK原生支持的生成代理的方式。

代理方法调用原理

前面已经详细分析了为接口/类生成代理的原理,生成代理之后就要调用方法了,这里看一下使用JdkDynamicAopProxy调用方法的原理。

由于JdkDynamicAopProxy本身实现了InvocationHandler接口,因此具体代理前后处理的逻辑在invoke方法中:

 1 public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
 2     MethodInvocation invocation;
 3     Object oldProxy = null;
 4     boolean setProxyContext = false;
 5
 6     TargetSource targetSource = this.advised.targetSource;
 7     Class targetClass = null;
 8     Object target = null;
 9
10     try {
11         if (!this.equalsDefined && AopUtils.isEqualsMethod(method)) {
12             // The target does not implement the equals(Object) method itself.
13             return equals(args[0]);
14         }
15         if (!this.hashCodeDefined && AopUtils.isHashCodeMethod(method)) {
16             // The target does not implement the hashCode() method itself.
17             return hashCode();
18         }
19         if (!this.advised.opaque && method.getDeclaringClass().isInterface() &&
20                 method.getDeclaringClass().isAssignableFrom(Advised.class)) {
21             // Service invocations on ProxyConfig with the proxy config...
22             return AopUtils.invokeJoinpointUsingReflection(this.advised, method, args);
23         }
24
25         Object retVal;
26
27         if (this.advised.exposeProxy) {
28             // Make invocation available if necessary.
29             oldProxy = AopContext.setCurrentProxy(proxy);
30             setProxyContext = true;
31         }
32
33         // May be null. Get as late as possible to minimize the time we "own" the target,
34         // in case it comes from a pool.
35         target = targetSource.getTarget();
36         if (target != null) {
37             targetClass = target.getClass();
38         }
39
40         // Get the interception chain for this method.
41         List<Object> chain = this.advised.getInterceptorsAndDynamicInterceptionAdvice(method, targetClass);
42
43         // Check whether we have any advice. If we don‘t, we can fallback on direct
44         // reflective invocation of the target, and avoid creating a MethodInvocation.
45         if (chain.isEmpty()) {
46             // We can skip creating a MethodInvocation: just invoke the target directly
47             // Note that the final invoker must be an InvokerInterceptor so we know it does
48             // nothing but a reflective operation on the target, and no hot swapping or fancy proxying.
49             retVal = AopUtils.invokeJoinpointUsingReflection(target, method, args);
50         }
51         else {
52             // We need to create a method invocation...
53             invocation = new ReflectiveMethodInvocation(proxy, target, method, args, targetClass, chain);
54             // Proceed to the joinpoint through the interceptor chain.
55             retVal = invocation.proceed();
56         }
57
58         // Massage return value if necessary.
59         if (retVal != null && retVal == target && method.getReturnType().isInstance(proxy) &&
60                 !RawTargetAccess.class.isAssignableFrom(method.getDeclaringClass())) {
61             // Special case: it returned "this" and the return type of the method
62             // is type-compatible. Note that we can‘t help if the target sets
63             // a reference to itself in another returned object.
64             retVal = proxy;
65         }
66         return retVal;
67     }
68     finally {
69         if (target != null && !targetSource.isStatic()) {
70             // Must have come from TargetSource.
71             targetSource.releaseTarget(target);
72         }
73         if (setProxyContext) {
74             // Restore old proxy.
75             AopContext.setCurrentProxy(oldProxy);
76         }
77     }
78 }

第11行~第18行的代码,表示equals方法与hashCode方法即使满足expression规则,也不会为之产生代理内容,调用的是JdkDynamicAopProxy的equals方法与hashCode方法。至于这两个方法是什么作用,可以自己查看一下源代码。

第19行~第23行的代码,表示方法所属的Class是一个接口并且方法所属的Class是AdvisedSupport的父类或者父接口,直接通过反射调用该方法。

第27行~第30行的代码,是用于判断是否将代理暴露出去的,由<aop:config>标签中的expose-proxy="true/false"配置。

第41行的代码,获取AdvisedSupport中的所有拦截器和动态拦截器列表,用于拦截方法,具体到我们的实际代码,列表中有三个Object,分别是:

  • chain.get(0):ExposeInvocationInterceptor,这是一个默认的拦截器,对应的原Advisor为DefaultPointcutAdvisor
  • chain.get(1):MethodBeforeAdviceInterceptor,用于在实际方法调用之前的拦截,对应的原Advisor为AspectJMethodBeforeAdvice
  • chain.get(2):AspectJAfterAdvice,用于在实际方法调用之后的处理

第45行~第50行的代码,如果拦截器列表为空,很正常,因为某个类/接口下的某个方法可能不满足expression的匹配规则,因此此时通过反射直接调用该方法。

第51行~第56行的代码,如果拦截器列表不为空,按照注释的意思,需要一个ReflectiveMethodInvocation,并通过proceed方法对原方法进行拦截,proceed方法感兴趣的朋友可以去看一下,里面使用到了递归的思想对chain中的Object进行了层层的调用。

时间: 2024-07-30 17:59:40

【Spring源码分析】AOP源码解析(下篇)的相关文章

Android源码分析--MediaServer源码分析(二)

在上一篇博客中Android源码分析–MediaServer源码分析(一),我们知道了ProcessState和defaultServiceManager,在分析源码的过程中,我们被Android的Binder通信机制中的各种复杂的类关系搞的眼花缭乱,接下来我们就以MediaPlayerService为例来分析一下Binder的通信机制.首先来回顾一下: BpBinder和BBinder都是Android中Binder通信的代表类,其中BpBinder是客户端用来与Server交互的代理类,p代

OpenStack_Swift源码分析——Object-auditor源码分析(2)

1 Object-aduitor审计具体分析 上一篇文章中,讲解了Object-aduitor的启动,其中审计的具体执行是AuditorWorker实现的,在run_audit中实例化了AuditorWorker类,并调用audit_all_objects方法,下面看此方法的具体代码实现: def audit_all_objects(self, mode='once', device_dirs=None): #run_forever传过来的mode 为forever description =

OpenStack_Swift源码分析——Object-auditor源码分析(1)

1 Object-auditor 的启动 Object-auditor的启动和object-replicator的启动过程是一样的,首先是执行启动脚本 swift-init object-auditor start 启动脚本会运行swift源码bin目录下的swift-ojbect-auditor if __name__ == '__main__': parser = OptionParser("%prog CONFIG [options]") parser.add_option('-

nginx源码分析--从源码看nginx框架总结

nginx源码总结: 1)代码中没有特别绕特别别扭的编码实现,从变量的定义调用函数的实现封装,都非常恰当,比如从函数命名或者变量命名就可以看出来定义的大体意义,函数的基本功能,再好的架构实现在编码习惯差的人实现也会黯然失色,如果透彻理解代码的实现,领悟架构的设计初衷,觉得每块代码就想经过耐心雕琢一样,不仅仅实现了基本的功能给你,为其他人阅读也会提供很好的支持.细致恰当的命名规则就可以看出作者的功力. 2)更好更高的软件性能体现在架构设计上,好的架构会让软件更加稳定.容易维护.便于扩展.从核心模块

OpenStack_Swift源码分析——ObjectReplicator源码分析(1)

1.ObjectorReplicator的启动 首先运行启动脚本 swift-init object-replicator start 此运行脚本的运行过程和ring运行脚本运行过程差不多,找到swift 源码bin下的swift-object-replicator其代码如下所示 if __name__ == '__main__': parser = OptionParser("%prog CONFIG [options]") parser.add_option('-d', '--de

OpenStack_Swift源码分析——ObjectReplicator源码分析(2)

1.Replicator执行代码详细分析 上篇问中介绍了启动Replicator的具体过程,下面讲解Replicator的执行代码的具体实现,首先看replicate方法: def replicate(self, override_devices=None, override_partitions=None): """Run a replication pass""" self.start = time.time() self.suffix_co

区块链教程以太坊源码分析core-state-process源码分析(二)

兄弟连区块链教程以太坊源码分析core-state-process源码分析(二):关于g0的计算,在黄皮书上由详细的介绍和黄皮书有一定出入的部分在于if contractCreation && homestead {igas.SetUint64(params.TxGasContractCreation) 这是因为 Gtxcreate+Gtransaction = TxGasContractCreation func IntrinsicGas(data []byte, contractCre

Dubbo 源码分析 - 服务导出全过程解析

1.服务导出过程 本篇文章,我们来研究一下 Dubbo 导出服务的过程.Dubbo 服务导出过程始于 Spring 容器发布刷新事件,Dubbo 在接收到事件后,会立即执行服务导出逻辑.整个逻辑大致可分为三个部分,第一是前置工作,主要用于检查参数,组装 URL.第二是导出服务,包含导出服务到本地 (JVM),和导出服务到远程两个过程.第三是向注册中心注册服务,用于服务发现.本篇文章将会对这三个部分代码进行详细的分析,在分析之前,我们先来了解一下服务的导出过程. Dubbo 支持两种服务导出方式,

jQuery源码分析:源码结构与核心函数

jQuery源码分析-03构造jQuery对象-源码结构和核心函数 jQuery.fn和jQuery.prototype区别

Spring IOC 容器源码分析 - getBean调用方法解析(三) -- 实例化 Bean 对象

1. createBeanInstance protected BeanWrapper createBeanInstance(String beanName, RootBeanDefinition mbd, @Nullable Object[] args) { // 解析 bean ,将 bean 类名解析为 class 引用 Class<?> beanClass = resolveBeanClass(mbd, beanName); /* * 检测类的访问权限.默认情况下,对于非 public