問題：Spring AOP代理中的運行時期，是在初始化時期織入還是獲取對象時期織入？
織入就是代理的過程，指目標對象進行封裝轉換成代理，實現了代理，就可以運用各種代理的場景模式。
何爲AOP
簡單點來定義就是切面，是一種編程範式。與OOP對比，它是面向切面，爲何需要切面，在開發中，我們的系統從上到下定義的模塊中的過程中會產生一些橫切性的問題，這些橫切性的問題和我們的主業務邏輯關係不大，假如不進行AOP，會散落在代碼的各個地方，造成難以維護。AOP的編程思想就是把業務邏輯和橫切的問題進行分離，從而達到解耦的目的，使代碼的重用性、侵入性低、開發效率高。
AOP使用場景
- 日誌記錄；記錄調用方法的入參和結果返參。
- 用戶的權限驗證；驗證用戶的權限放到AOP中，與主業務進行解耦。
- 性能監控；監控程序運行方法的耗時，找出項目的瓶頸。
- 事務管理；控制Spring事務，Mysql事務等。
AOP概念點
AOP和Spring AOP的關係
在這裏問題中，也有一個類似的一對IOC和DI（dependency injection）的關係，AOP可以理解是一種編程目標，Spring AOP就是這個實現這個目標的一種手段。同理IOC也是一種編程目標，DI就是它的一個手段。
SpringAOP和AspectJ是什麼關係
在Spring官網可以看到，AOP的實現提供了兩種支持分別爲@AspectJ、Schema-based AOP。其實在Spring2.5版本時，Spring自己實現了一套AOP開發的規範和語言，但是這一套規範比較複雜，可讀性差。之後，Spring借用了AspectJ編程風格，纔有了@AspectJ的方式支持，那麼何爲編程風格。
- Annotation註解方式；對應@AspectJ
- JavaConfig；對應Schema-based AOP
SpringAOP和AspectJ的詳細對比，在之後的章節會在進行更加詳細的說明，將會在他們的背景、織入方法、性能做介紹。
Spring AOP的應用
閱讀官網，是我們學習一個新知識的最好途徑，這個就是Spring AOP的核心概念點，跟進它們的重要性，我做了重新的排序，以便好理解，這些會爲我們後續的源碼分析起到作用。
Aspect：切面；使用@Aspect註解的Java類來實現，集合了所有的切點，做爲切點的一個載體，做一個比喻就像是我們的一個數據庫。
Tips：這個要實現的話，一定要交給Spirng IOC去管理，也就是需要加入@Component。
Pointcut：切點；表示爲所有Join point的集合，就像是數據庫中一個表。
Join point：連接點；俗稱爲目標對象，具體來說就是servlet中的method，就像是數據庫表中的記錄。
Advice：通知；這個就是before、after、After throwing、After (finally)。
Weaving：把代理邏輯加入到目標對象上的過程叫做織入。
target：目標對象、原始對象。
aop Proxy：代理對象 包含了原始對象的代碼和增加後的代碼的那個對象。
Tips
這個應用點，有很多的知識點可以讓我們去挖掘，比如Pointcut中execution、within的區別，我相信你去針對性搜索或者官網都未必能有好的解釋，稍後會再專門挑一個文章做重點的使用介紹；
SpringAOP源碼分析
爲了回答我們的一開始的問題，前面的幾個章節我們做了一些簡單的概念介紹做爲鋪墊，那麼接下來我們迴歸正題，正面去切入問題。以碼說話，我們以最簡潔的思路把AOP實現，我們先上代碼。
項目結構介紹
項目目錄結構，比較簡單，5個主要的文件；
pom.xml核心代碼；spring-content是核心jar，已經包含了spring所有的基礎jar，aspectjweaver是爲了實現AOP。
AppConfig.java；定義一個Annotation，做爲我們Spirng IOC容器的啓動類。
package com.will.config;
@Configuration
@ComponentScan("com.will")
@EnableAspectJAutoProxy(proxyTargetClass = false)
public class AppConfig {
}WilAspect.java ；按照官網首推的方式（@AspectJ support），實現AOP代理。
package com.will.config;
/**
* 定義一個切面的載體
*/
@Aspect
@Component
public class WilAspect {
/**
* 定義一個切點
*/
@Pointcut("execution(* com.will.dao.*.*(..))")
public void pointCutExecution(){
}
/**
* 定義一個Advice爲Before，並指定對應的切點
* @param joinPoint
*/
@Before("pointCutExecution()")
public void before(JoinPoint joinPoint){
System.out.println("proxy-before");
}
}Dao.java
package com.will.dao;
public interface Dao {
public void query();
}UserDao.java
package com.will.dao;
import org.springframework.stereotype.Component;
@Component
public class UserDao implements Dao {
public void query() {
System.out.println("query user");
}
}Test.java
package com.will.test;
import com.will.config.AppConfig;
import com.will.dao.Dao;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
public class Test {
public static void main(String[] args) {
/**
* new一個註冊配置類，啓動IOC容器，初始化時期；
*/
AnnotationConfigApplicationContext annotationConfigApplicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
/**
* 獲取Dao對象，獲取對象時期，並進行query打印
*/
Dao dao = annotationConfigApplicationContext.getBean(Dao.class);
dao.query();
annotationConfigApplicationContext.start();
}
}好了，這樣我們整體的AOP代理就已經完成。
問題分析測試
究竟是哪個時期進行對象織入的，比如Test類中，究竟是第一行還是第二行進行織入的，我們只能通過源碼進行分析，假如是你，你會進行如何的分析源碼解讀。
Spring的代碼非常優秀，同時也非常複雜，那是一個大項目，裏面進行了很多的代碼封裝，那麼的代碼你三天三夜也讀不完，甚至於你都不清楚哪一行的該留意的，哪一行是起到關鍵性作用的，這裏教幾個小技巧。
- 看方法返回類型；假如是void返回類型的，看都不看跳過。返回結果是對象，比如T果斷進行去進行跟蹤。
- 假設法；就當前場景，我們大膽假設是第二行進行的織入。
- 藉助好的IDE；IDEA可以幫我們做很多的事情，它的debug模式中的條件斷點、調用鏈（堆棧）會幫助到我們。
假設法源碼分析
debug模式StepInfo（F5）後，進入 AbstractApplicationContext.getBean方法，這個是Spring應用上下文中最重要的一個類，這個抽象類中提供了幾乎ApplicationContext的所有操作。這裏第一個語句返回void，我們可以直接忽略，看下面的關鍵性代碼。
繼續debug後，會進入到 DefaultListableBeanFactory 類中，看如下代碼
return new NamedBeanHolder<>(beanName, getBean
(beanName, requiredType, args));在該語句中，這個可以理解爲 DefaultListableBeanFactory 容器，幫我們獲取相應的Bean。
進入到AbstractBeanFactory類的doGetBean方法之後，我們運行完。
Object sharedInstance = getSingleton(beanName);語句之後，看到 sharedInstance 對象打印出&Proxyxxx ，說明在getSingleton 方法的時候就已經獲取到了對象，所以需要跟蹤進入到 getSingleton 方法中，繼續探究。
不方便不方便我們進行問題追蹤到這個步驟之後，我需要引入IDEA的條件斷點，不方便我們進行問題追蹤因爲Spring會初始化很多的Bean，我們再ObjectsharedInstance=getSingleton(beanName);加入條件斷點語句。
繼續debug進入到DefaultSingletonBeanRegistry的getSingleton方法。
我們觀察下執行完ObjectsingletonObject=this.singletonObjects.get(beanName); 之後的singletonObject已經變成爲&ProxyUserDao，這個時候Spring最關鍵的一行代碼出現了，請注意這個this.singletonObjects。
this.singletonObjects就是相當IOC容器，反之IOC容器就是一個線程安全的線程安全的HashMap，裏面存放着我們需要Bean。
我們來看下singletonObjects存放着的數據，裏面就有我們的UserDao類。
這就說明，我們的初始化的時期進行織入的，上圖也有整個Debug模式的調用鏈。
源碼深層次探索
通過上一個環節已經得知是在第一行進行初始化的，但是它在初始化的時候是什麼時候完成織入的，抱着求知的心態我們繼續求證。
還是那個問題，那麼多的代碼，我的切入點在哪裏？
既然singletonObjects是容器，存放我們的Bean，那麼找到關鍵性代碼在哪裏進行存放（put方法）就可以了。於是我們通過搜索定位到了。
我們通過debug模式的條件斷點和debug調用鏈模式，就可以進行探索。
這個時候藉助上圖中的調用鏈，我們把思路放到放到IDEA幫我定位到的兩個方法代碼上。
DefaultSingletonBeanRegistry.getSingleton
我們一步步斷點，得知，當運行完singletonObject=singletonFactory.getObject();之後，singletonObject已經獲得了代理。
至此我們知道，代理對象的獲取關鍵在於singletonFactory對象，於是又定位到了AbstractBeanFactorydoGetBean方法，發現singletonFactory參數是由createBean方法創造的。這個就是Spring中IOC容器最核心的地方了，這個代碼的模式也值得我們去學習。
sharedInstance = getSingleton(beanName, () -> {
try {
return createBean(beanName, mbd, args);
}
catch (BeansException ex) {
// Explicitly remove instance from singleton cache: It might have been put there
// eagerly by the creation process, to allow for circular reference resolution.
// Also remove any beans that received a temporary reference to the bean.
destroySingleton(beanName);
throw ex;
}
});這個第二個參數是用到了jdk8中的lambda，這一段的含義是就是爲了傳參，重點看下 createBean(beanName,mbd,args);代碼。隨着斷點，我們進入到這個類方法裏面。
AbstractAutowireCapableBeanFactory.createBean中的；
ObjectbeanInstance=doCreateBean(beanName,mbdToUse,args)方法；
doCreateBean方法中，做了簡化。
Initialize the bean instance.
Object exposedObject = bean;
try {
populateBean(beanName, mbd, instanceWrapper);
exposedObject = initializeBean(beanName, exposedObject, mbd);
}
...
return exposedObject;
當運行完 exposedObject=initializeBean(beanName,exposedObject,mbd);之後，我們看到exposedObject已經是一個代理對象，並執行返回。這一行代碼就是取判斷對象要不要執行代理，要的話就去初始化代理對象，不需要直接返回。後面的initializeBean方法是涉及代理對象生成的邏輯（JDK、Cglib），後續會有一個專門的章節進行詳細介紹。
總結
通過源碼分析，我們得知，Spring AOP的代理對象的織入時期是在運行Spring初始化的時候就已經完成的織入，並且也分析了Spring是如何完成的織入。
