按照自己的思路研究Spring AOP源码【2】

探究Spring高版本和低版本对于Advice排序的不同，一步步地解开其面纱，包括了高低版本的详细对比以及原因。

问题的提出
哪一步导致了顺序的改变
AbstractAdvisorAutoProxyCreator.sortAdvisors()方法
总结

问题的提出

上面这篇文章介绍了Spring AOP源码的核心流程，根据上面这篇文章提出的问题，我们继续来探讨一下为什么通知顺序是不一样的。

首先我们看一下新版本(5.3.5-SNAPSHOT)的通知顺序与输出结果，如下图：

顺序：Around Before After AfterReturning
输出如下：
===== Around before =====
===== Before =====
do service
===== AfterReturning =====
===== After =====
===== Around after =====

我们再来看一下旧版本(5.2.6.RELEASE)的通知顺序与输出结果，如下图：

顺序：AfterReturning After Around Before
===== Around before =====
===== Before =====
do service
===== Around after =====
===== After =====
===== AfterReturning =====

我们看到不同的顺序是对结果的输出也是有影响的
还有一个就是对After通知是否执行的影响，我们都知道After通知的定义是不管方法有没有抛异常，它都会执行
但是如果我们在Before通知或者Around通知中抛一个异常，那上面的两种排序对于After通知是否执行是不一样的，具体的执行结果我们来看一下：

我们先在Before通知中抛一个异常，代码如下：

@Before("pointCut()")
public void methodBefore() {
    System.out.println("===== Before =====");
    throw new RuntimeException();
}

下面是不同版本的执行结果：

新版本如下：
===== Around before =====
===== Before =====
Exception in thread "main" java.lang.RuntimeException
老版本如下：
===== Around before =====
===== Before =====
===== After =====
Exception in thread "main" java.lang.RuntimeException

从上面的结果可以看出，新版本的After通知是没有执行的，而老版本的After通知是执行了的，这就是通知顺序所导致的后果，所以小伙伴们在开发时碰到此类问题时，可以往这方面想想喔~

哪一步导致了顺序的改变

我们以旧版本来debug，原因到后面就知道了，所以以下的debug流程是基于旧版本的，我们来看看这个顺序是一直不变的呢，还是在某个方法执行之后发生了变化

我们就从JdkDynamicAopProxy.invoke开始，一步一步的debug，一起来看看顺序的变化。

在debug的时候，有一个极其方便的技巧，那就是：我画出的那个图标：drop frame，这个功能就是返回上一个函数，这样的话就不用重新运行然后重新打断点，就相当于一个后悔药，果然程序的世界和现实的世界是不一样的，你可以为所欲为，好，我们要做好心理准备开始debug了。

首先，我们看一下这个chain是怎么生成的，进到AdvisedSupport.getInterceptorsAndDynamicInterceptionAdvice：

我们可以看到这个链通过getInterceptorsAndDynamicInterceptionAdvice方法获得，并放到了一个缓存里

进到DefaultAdvisorChainFactory.getInterceptorsAndDynamicInterceptionAdvice：

看到有个advisors数组，最终的链就是根据这个数组得来的，发现这个顺序就是最终顺序，可以看到这个数组是由config.getAdvisors()得来的

进到AdvisedSupport.getAdvisors：

我们可以看到返回的数组是this.advisorArray，那我们来猜一下谁会把这个数组填充好

尝试在AdvisedSupport这个类里搜索addAdvisor，发现有11处：

在这些地方都打上断点，然后重新运行，看看具体会运行到哪个位置

发现是在AdvisedSupport.addAdvisors(Advisor... advisors)这个方法：

这一步的结果还是最终顺序，我们想知道谁调用了这个方法，这时候就可以用drop frame了

可以看到在AbstractAutoProxyCreator.createProxy调用了此方法：

可以看到数据是由specificInterceptors得来的，并且依旧是最终顺序，继续drop frame

可以看到在AbstractAutoProxyCreator.wrapIfNecessary调用了此方法：

可以看到调用getAdvicesAndAdvisorsForBean这个方法获得了数组

进到AbstractAdvisorAutoProxyCreator.getAdvicesAndAdvisorsForBean这个方法：

进到AbstractAdvisorAutoProxyCreator.findEligibleAdvisors这个方法：

在这里，我们发现顺序和最终顺序不一样了，终于找到你

来看一下后面的返回结果：

从上面的结果，我们可以猜测是sortAdvisors这个方法改变了顺序

进到AbstractAdvisorAutoProxyCreator.sortAdvisors这个方法：

从上图可以看出，是PartialOrder.sort(partiallyComparableAdvisors)这个方法改变了顺序

为了确认一下，我们看一下新版的顺序是怎么样的

AbstractAdvisorAutoProxyCreator.findEligibleAdvisors中sortAdvisors之前的结果：

AbstractAdvisorAutoProxyCreator.findEligibleAdvisors中sortAdvisors之后的结果：

经观察，新版的顺序没有变化

`AbstractAdvisorAutoProxyCreator.sortAdvisors()`方法

现在我们知道是哪个地方把顺序改变了，那我们就看一下PartialOrder.sort这个方法

public class PartialOrder {
	public static <T extends PartialComparable> List<T> sort(List<T> objects) {
		// lists of size 0 or 1 don't need any sorting
		if (objects.size() < 2) {
			return objects;
		}
		// ??? we might want to optimize a few other cases of small size
		// ??? I don't like creating this data structure, but it does give good
		// ??? separation of concerns.
		List<SortObject<T>> sortList = new LinkedList<SortObject<T>>();
		for (Iterator<T> i = objects.iterator(); i.hasNext();) {
			addNewPartialComparable(sortList, i.next());
		}
		// System.out.println(sortList);
		// now we have built our directed graph
		// use a simple sort algorithm from here
		// can increase efficiency later
		// List ret = new ArrayList(objects.size());
		final int N = objects.size();
		for (int index = 0; index < N; index++) {
			// System.out.println(sortList);
			// System.out.println("-->" + ret);
			SortObject<T> leastWithNoSmallers = null;
			for (SortObject<T> so: sortList) {
				if (so.hasNoSmallerObjects()) {
					if (leastWithNoSmallers == null || so.object.fallbackCompareTo(leastWithNoSmallers.object) < 0) {
						leastWithNoSmallers = so;
					}
				}
			}
			if (leastWithNoSmallers == null) {
				return null;
			}
			removeFromGraph(sortList, leastWithNoSmallers);
			objects.set(index, leastWithNoSmallers.object);
		}
		return objects;
	}
}

首先看一下下面的代码：

List<SortObject<T>> sortList = new LinkedList<SortObject<T>>();
for (Iterator<T> i = objects.iterator(); i.hasNext();) {
    addNewPartialComparable(sortList, i.next());
}

我们从上面的代码可以看到，它为会每一个advice构造一个SortObject结构：

private static class SortObject<T extends PartialComparable> {
    T object;
    List<SortObject<T>> smallerObjects = new LinkedList<SortObject<T>>();
    List<SortObject<T>> biggerObjects = new LinkedList<SortObject<T>>();
}

object是它自己本身，smallerObjects包含了比它优先级高的advice，biggerObjects包含了比它优先级低的advice

我们看一下构造结果是这样的：

根据这个结构，它是怎么排序的呢？看如下代码：

		final int N = objects.size();
		for (int index = 0; index < N; index++) {
			// System.out.println(sortList);
			// System.out.println("-->" + ret);
			SortObject<T> leastWithNoSmallers = null;
			for (SortObject<T> so: sortList) {
				if (so.hasNoSmallerObjects()) {
					if (leastWithNoSmallers == null || so.object.fallbackCompareTo(leastWithNoSmallers.object) < 0) {
						leastWithNoSmallers = so;
					}
				}
			}
			if (leastWithNoSmallers == null) {
				return null;
			}
			removeFromGraph(sortList, leastWithNoSmallers);
			objects.set(index, leastWithNoSmallers.object);
		}

		boolean hasNoSmallerObjects() {
			return smallerObjects.size() == 0;
		}

每次找到smallerObjects对象size为0的对象，也就是此时它是优先级最高的

从上面的结果图可以看出，首先是ExposeInvocationInterceptor这个类，这个类是个扩展的advisor，它优先级最高，所以它的smallerObjects的大小为0，
所以它的顺序就是0，它被敲定之后，就会被移除掉，别人的smallerObjects和biggerObjects会把它移除掉，
然后AspectJAfterReturningAdvice的smallerObjects就会删除它，它的smallerObjects的size就会变成0，之后它就是顺序1
依次类推，AspectJAfterAdvice为顺序2 AspectJAroundAdvice为顺序3 最后AspectJMethodBeforeAdvice为顺序4。

那我们再来看一下SortObject是怎么生成的，看下面的代码：

public class PartialOrder {
      	private static <T extends PartialComparable> void addNewPartialComparable(List<SortObject<T>> graph, T o) {
      		SortObject<T> so = new SortObject<T>(o);
      		for (Iterator<SortObject<T>> i = graph.iterator(); i.hasNext();) {
      			SortObject<T> other = i.next();
      			so.addDirectedLinks(other);
      		}
      		graph.add(so);
      	}
}
private static class SortObject<T extends PartialComparable> {
	void addDirectedLinks(SortObject<T> other) {
		int cmp = object.compareTo(other.object);
		if (cmp == 0) {
			return;
		}
		if (cmp > 0) {
			this.smallerObjects.add(other);
			other.biggerObjects.add(this);
		} else {
			this.biggerObjects.add(other);
			other.smallerObjects.add(this);
		}
	}
}

从上面代码，我们可以看出，其实就是根据compareTo方法进行比较，以此来判断添加到谁的smallerObjects和biggerObjects里面

关于compareTo的调用，最终跟踪到了如下方法(同一切面下advice优先级的比较)：

class AspectJPrecedenceComparator implements Comparator<Advisor> {
	private int comparePrecedenceWithinAspect(Advisor advisor1, Advisor advisor2) {
		boolean oneOrOtherIsAfterAdvice =
				(AspectJAopUtils.isAfterAdvice(advisor1) || AspectJAopUtils.isAfterAdvice(advisor2));
		int adviceDeclarationOrderDelta = getAspectDeclarationOrder(advisor1) - getAspectDeclarationOrder(advisor2);
		if (oneOrOtherIsAfterAdvice) {
			// the advice declared last has higher precedence
			if (adviceDeclarationOrderDelta < 0) {
				// advice1 was declared before advice2
				// so advice1 has lower precedence
				return LOWER_PRECEDENCE;
			}
			else if (adviceDeclarationOrderDelta == 0) {
				return SAME_PRECEDENCE;
			}
			else {
				return HIGHER_PRECEDENCE;
			}
		}
		else {
			// the advice declared first has higher precedence
			if (adviceDeclarationOrderDelta < 0) {
				// advice1 was declared before advice2
				// so advice1 has higher precedence
				return HIGHER_PRECEDENCE;
			}
			else if (adviceDeclarationOrderDelta == 0) {
				return SAME_PRECEDENCE;
			}
			else {
				return LOWER_PRECEDENCE;
			}
		}
	}
	private int getAspectDeclarationOrder(Advisor anAdvisor) {
		AspectJPrecedenceInformation precedenceInfo =
			AspectJAopUtils.getAspectJPrecedenceInformationFor(anAdvisor);
		if (precedenceInfo != null) {
			return precedenceInfo.getDeclarationOrder();
		}
		else {
			return 0;
		}
	}
}
public abstract class InstantiationModelAwarePointcutAdvisorImpl {
	@Override
	public int getDeclarationOrder() {
		return this.declarationOrder;
	}
}

可以看到，其实比较的就是declarationOrder这个字段

通过查看调用链，查看在哪里赋值了这个字段，如下图：

发现是ReflectiveAspectJAdvisorFactory.getAdvisors中赋的值，如下图：

在旧版中，赋值的大小是advisors的size

由于advisor一个一个的被添加进去的，所以它们的值依次是0，1，2，3，验证结果如下图：

我们再来看一下新版的赋值：

我们看到新版的赋值都是0，这样的话，那大家的优先级都是一样的，所以就是按照默认顺序来进行执行的，

那这个默认的顺序又是怎么来的呢

通知是从切面的advice方法提取出来的，并做了一下排序，具体如下：

来看一下排序的比较器：

那么比较器是怎么比较的呢

public class ConvertingComparator<S, T> implements Comparator<S> {
	@Override
	public int compare(S o1, S o2) {
		T c1 = this.converter.convert(o1);
		T c2 = this.converter.convert(o2);
		return this.comparator.compare(c1, c2);
	}
}
public class InstanceComparator<T> implements Comparator<T> {
	@Override
	public int compare(T o1, T o2) {
		int i1 = getOrder(o1);
		int i2 = getOrder(o2);
		return (Integer.compare(i1, i2));
	}
	private int getOrder(@Nullable T object) {
		if (object != null) {
			for (int i = 0; i < this.instanceOrder.length; i++) {
				if (this.instanceOrder[i].isInstance(object)) {
					return i;
				}
			}
		}
		return this.instanceOrder.length;
	}
	public InstanceComparator(Class<?>... instanceOrder) {
		Assert.notNull(instanceOrder, "'instanceOrder' array must not be null");
		this.instanceOrder = instanceOrder;
	}
}
从上面可以分析出，就是在instanceOrder这个数组里面的位置，而这个又是通过下面的构造函数赋值的
new InstanceComparator<>(Around.class, Before.class, After.class, AfterReturning.class, AfterThrowing.class)
所以就是按照这个顺序来排序的

总结

是因为导致顺序不一致的呢？是spring的版本导致的，如下图：
低版本赋予了优先级，而高版本的没有赋予优先级，采用的默认顺序，那么默认循序是什么呢，如下图：

本文链接：https://www.cnblogs.com/eaglelihh/p/14751827.html

按照自己的思路研究Spring AOP源码【2】

问题的提出

哪一步导致了顺序的改变

`AbstractAdvisorAutoProxyCreator.sortAdvisors()`方法

总结