如果获取到的 Annotation 如果不为 null，则就可以调用它们的属性方法了比如@TestAnnotation()publicclassTest{ public static void main(String[] args) { boolean hasAnnotation = Test。

.class.isAnnotationPresent(TestAnnotation.class);if ( hasAnnotation ) { TestAnnotation testAnnotation = Test

.class.getAnnotation(TestAnnotation.class); System.out.println("id:"+testAnnotation.id()); System.

out.println("msg:"+testAnnotation.msg()); } } } 程序的运行结果是：id:-1msg: 这个正是 TestAnnotation 中 id 和 msg 的默认值。

上面的例子中，只是检阅出了注解在类上的注解，其实属性、方法上的注解照样是可以的同样还是要假手于反射@TestAnnotation(msg="hello")publicclassTest{ @Check(value=

"hi") int a; @Performpublic void testMethod(){} @SuppressWarnings("deprecation")public void test1(){ Hero hero = new Hero(); hero.say(); hero.speak(); }

public static void main(String[] args) { boolean hasAnnotation = Test.class.isAnnotationPresent

(TestAnnotation.class);if ( hasAnnotation ) { TestAnnotation testAnnotation = Test.class.

getAnnotation(TestAnnotation.class);//获取类的注解 System.out.println("id:"+testAnnotation.id()); System.

out.println("msg:"+testAnnotation.msg()); } try { Field a = Test.class.getDeclaredField

("a"); a.setAccessible(true); //获取一个成员变量上的注解 Check check = a.getAnnotation(Check

.class);if ( check != null ) { System.out.println("check value:"+check.value()); } Method testMethod = Test

.class.getDeclaredMethod("testMethod"); if ( testMethod != null ) { // 获取方法中的注解

Annotation[] ans = testMethod.getAnnotations(); for( int i = 0;i < ans.length;i++) { System.

out.println("method testMethod annotation:"+ans[i].annotationType().getSimpleName()); } } }

catch (NoSuchFieldException e) { // TODO Auto-generated catch block e.printStackTrace(); System.

out.println(e.getMessage()); } catch (SecurityException e) { // TODO Auto-generated catch block

e.printStackTrace(); System.out.println(e.getMessage()); } catch (NoSuchMethodException e) {

// TODO Auto-generated catch block e.printStackTrace(); System.out.println(e.getMessage()); } } }

它们的结果如下：id:-1msg:hellocheckvalue:himethodtestMethodannotation:Perform需要注意的是，如果一个注解要在运行时被成功提取，那么 @Retention(RetentionPolicy.RUNTIME) 是必须的。

3.4注解的使用场景我相信博文讲到这里大家都很熟悉了注解，但是有不少同学肯定会问，注解到底有什么用呢？对啊注解到底有什么用？我们不妨将目光放到 Java 官方文档上来文章开始的时候，我用标签来类比注解但标签比喻只是我的手段，而不是目的。

为的是让大家在初次学习注解时能够不被那些抽象的新概念搞懵既然现在，我们已经对注解有所了解，我们不妨再仔细阅读官方最严谨的文档注解是一系列元数据，它提供数据用来解释程序代码，但是注解并非是所解释的代码本身的一部分。

注解对于代码的运行效果没有直接影响 注解有许多用处，主要如下：提供信息给编译器： 编译器可以利用注解来探测错误和警告信息编译阶段时的处理： 软件工具可以用来利用注解信息来生成代码、Html文档或者做其它相应处理。

运行时的处理： 某些注解可以在程序运行的时候接受代码的提取 值得注意的是，注解不是代码本身的一部分如果难于理解，可以这样看罗永浩还是罗永浩，不会因为某些人对于他“傻x”的评价而改变，标签只是某些人对于其他事物的评价，但是标签不会改变事物本身，标签只是特定人群的手段。

所以，注解同样无法改变代码本身，注解只是某些工具的的工具还是回到官方文档的解释上，注解主要针对的是编译器和其它工具软件(SoftWare tool)当开发者使用了Annotation 修饰了类、方法、Field 等成员之后，这些 Annotation 不会自己生效，必须由开发者提供相应的代码来提取并处理 Annotation 信息。

这些处理提取和处理 Annotation 的代码统称为 APT（Annotation Processing Tool)现在，我们可以给自己答案了，注解有什么用？给谁用？给 编译器或者 APT 用的如果，你还是没有搞清楚的话，我亲自写一个好了。

3.5亲手自定义注解完成项目我要写一个测试框架，测试程序员的代码有无明显的异常—— 程序员 A : 我写了一个类，它的名字叫做 NoBug，因为它所有的方法都没有错误 —— 我：自信是好事，不过为了防止意外，让我测试一下如何？ —— 程序员 A: 怎么测试？ —— 我：把你写的代码的方法都加上 @Jiecha 这个注解就好了。

—— 程序员 A: 好的package ceshi; import ceshi.Jiecha; publicclassNoBug{ @JiechapublicvoidsuanShu(){ System.out.println(

"1234567890"); } @Jiechapublicvoidjiafa(){ System.out.println("1+1="+1+1); }

@Jiechapublicvoidjiefa(){ System.out.println("1-1="+(1-1)); } @Jiechapublicvoidchengfa

(){ System.out.println("3 x 5="+ 3*5); } @Jiechapublicvoidchufa(){ System.out.println(

"6 / 0="+ 6 / 0); } publicvoidziwojieshao(){ System.out.println("我写的程序没有 bug!"); } }

上面的代码，有些方法上面运用了 @Jiecha 注解这个注解是我写的测试软件框架中定义的注解package ceshi; import java.lang.annotation.Retention; import

java.lang.annotation.RetentionPolicy; @Retention(RetentionPolicy.RUNTIME)public@interface Jiecha { }

然后，我再编写一个测试类 TestTool 就可以测试 NoBug 相应的方法了package ceshi; import java.lang.reflect.InvocationTargetException; 。

import java.lang.reflect.Method; publicclassTestTool {publicstaticvoidmain(String[] args){ // TODO Auto-generated method stub

NoBug testobj = new NoBug(); Class clazz = testobj.getClass(); Method[] method = clazz.getDeclaredMethods();

//用来记录测试产生的 log 信息 StringBuilder log = new StringBuilder(); // 记录异常的次数int errornum =

0; for ( Method m: method ) { // 只有被 @Jiecha 标注过的方法才进行测试if ( m.isAnnotationPresent( Jiecha.class )) {

try { m.setAccessible(true); m.invoke(testobj, null); }

catch (Exception e) { // TODO Auto-generated catch block//e.printStackTrace(); errornum++;

log.append(m.getName()); log.append(" "); log.append("has error:"

); log.append("\n\r caused by "); //记录测试过程中，发生的异常的名称log.append(e.getCause().getClass().getSimpleName());

log.append("\n\r"); //记录测试过程中，发生的异常的具体信息log.append(e.getCause().getMessage());

log.append("\n\r"); } } } log.append(clazz.getSimpleName());

log.append(" has "); log.append(errornum); log.append(" error."); // 生成测试报告 System.out.println(

log.toString()); } } 测试的结果是：12345678901+1=111-1=03x5=15chufa has error:causedbyArithmeticException

/byzeroNoBughas1error.提示 NoBug 类中的 chufa() 这个方法有异常，这个异常名称叫做 ArithmeticException，原因是运算过程中进行了除 0 的操作所以，NoBug 这个类有 Bug。

这样，通过注解我完成了我自己的目的，那就是对别人的代码进行测试所以，再问我注解什么时候用？我只能告诉你，这取决于你想利用它干什么用3.6注解应用实例注解运用的地方太多了，如： JUnit 这个是一个测试框架，典型使用方法如下：。

publicclassExampleUnitTest{ @Testpublicvoidaddition_isCorrect()throws Exception { assertEquals(

4, 2 + 2); } } @Test 标记了要进行测试的方法 addition_isCorrect().还有例如ssm框架等运用了大量的注解注解部分总结如果注解难于理解，你就把它类同于标签，标签为了解释事物，注解为了解释代码。

注解的基本语法，创建如同接口，但是多了个 @ 符号注解的元注解注解的属性注解主要给编译器及工具类型的软件用的注解的提取需要借助于 Java 的反射技术，反射比较慢，所以注解使用时也需要谨慎计较时间成本4.APT实现原理

4.1 SPI机制SPI是jdk内置的服务发现机制， 全称叫Service Provider Interface.SPI的工作原理， 就是ClassPath路径下的META-INF/services文件夹中， 以接口的全限定名来命名文件名， 文件里面写该接口的实现。

然后再资源加载的方式，读取文件的内容(接口实现的全限定名)， 然后再去加载类SPI可以很灵活的让接口和实现分离， 让api提供者只提供接口， 第三方来实现这一机制为很多框架的扩展提供了可能，比如在 Dubbo、JDBC、SpringBoot 中都使用到了SPI机制。

虽然他们之间的实现方式不同，但原理都差不多今天我们就来看看，SPI到底是何方神圣，在众多开源框架中又扮演了什么角色4.1.1 JDK中的SPI我们先从JDK开始，通过一个很简单的例子来看下它是怎么用的4.1.1.1、小栗子

首先，我们需要定义一个接口，SpiServicepackage com.dxz.jdk.spi; publicinterfaceSpiService{ voidprintln(); } 然后，定义一个实现类，没别的意思，只做打印。

package com.dxz.jdk.spi; ​ publicclassSpiServiceImplimplementsSpiService{ @Overridepublicvoidprintln

(){ System.out.println("------SPI DEMO-------"); } } 最后呢，要在resources路径下配置添加一个文件文件名字是接口的全限定类名，内容是实现类的全限定类名，多个实现类用换行符分隔。

文件内容就是实现类的全限定类名：4.1.1.2、测试然后我们就可以通过 ServiceLoader.load 方法拿到实现类的实例，并调用它的方法publicstaticvoidmain(String[] args)。

{ ServiceLoader load = ServiceLoader.load(SpiService.class); Iterator iterator = load.iterator();

while (iterator.hasNext()){ SpiService service = iterator.next(); service.println(); } }

4.1.1.3、源码分析首先，我们先来了解下 ServiceLoader，看看它的类结构publicfinalclassServiceLoader implementsIterable{//配置文件的路径

privatestaticfinal String PREFIX = "META-INF/services/"; //加载的服务类或接口privatefinal Class service;

//已加载的服务类集合private LinkedHashMap providers = new LinkedHashMap<>(); //类加载器privatefinal ClassLoader loader;

//内部类，真正加载服务类private LazyIterator lookupIterator; } 当我们调用 load 方法时，并没有真正的去加载和查找服务类而是调用了 ServiceLoader 的构造方法，在这里最重要的是实例化了内部类 LazyIterator ，它才是接下来的主角。

private ServiceLoader(Class svc, ClassLoadercl) { //要加载的接口 service = Objects.requireNonNull(svc,

"Service interface cannot be null"); //类加载器 loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;

//访问控制器 acc = (System.getSecurityManager() != null) ? AccessController.getContext() : null; //先清空

providers.clear(); //实例化内部类 LazyIterator lookupIterator = new LazyIterator(service, loader); }

查找实现类和创建实现类的过程，都在 LazyIterator 完成当我们调用 iterator.hasNext和iterator.next 方法的时候，实际上调用的都是 LazyIterator 的相应方法。

public Iterator iterator(){ ​ returnnew Iterator() { publicbooleanhasNext(){

return lookupIterator.hasNext(); } public S next(){ return lookupIterator.next(); } ....... }; }

所以，我们重点关注 lookupIterator.hasNext() 方法，它最终会调用到 hasNextServicez ，在这里返回实现类名称privateclassLazyIteratorimplements。

Iterator{ Class service; ClassLoader loader; Enumeration configs = null; Iterator pending =

null; String nextName = null; privatebooleanhasNextService(){ //第二次调用的时候，已经解析完成了，直接返回

if (nextName != null) { returntrue; } if (configs == null) {

//META-INF/services/ 加上接口的全限定类名，就是文件服务类的文件//META-INF/services/com.viewscenes.netsupervisor.spi.SPIService

String fullName = PREFIX + service.getName(); //将文件路径转成URL对象 configs = loader.getResources(fullName); }

while ((pending == null) || !pending.hasNext()) { //解析URL文件对象，读取内容，最后返回 pending = parse(service, configs.nextElement()); }

//拿到第一个实现类的类名 nextName = pending.next(); returntrue; } } 然后当我们调用 next() 方法的时候，调用到

lookupIterator.nextService 它通过反射的方式，创建实现类的实例并返回private S nextService() { //全限定类名 String cn = nextName; nextName = 。

null; //创建类的Class对象 Class c = Class.forName(cn, false, loader); //通过newInstance实例化 S p = service.cast(c.newInstance());

//放入集合，返回实例 providers.put(cn, p); return p; } 到这为止，已经获取到了类的实例4.1.2 JDBC中的应用我们开头说，SPI机制为很多框架的扩展提供了可能，其实JDBC就应用到了这一机制。

在以前，需要先设置数据库驱动的连接，再通过 DriverManager.getConnection 获取一个 Connection String url = "jdbc:mysql:///consult?serverTimezone=UTC"。

; String user = "root"; String passwor d = "r oot"; ​ Class.forName("com.mysql.jdbc.Driver"); Connection connection = DriverManager.getConnection(url, user, password);

而现在，设置数据库驱动连接，这一步骤就不再需要，那么它是怎么分辨是哪种数据库的呢？答案就在SPI4.1.2.1 加载下图mysql Driver的实例 com.mysql.cj.jdbc.Driver就是Driver的实现。

mysql驱动为例

mysql Driver实现类

Driver接口上的一段注释DriverManager将尝试加载尽可能多的驱动程序我们把目光回到 DriverManager 类，它在静态代码块里面做了一件比较重要的事很明显，它已经通过SPI机制， 把数据库驱动连接初始化了。

publicclassDriverManager{ static { loadInitialDrivers(); println("JDBC DriverManager initialized"

); } } 接下来我们去DriverManger上看看是如何加载Driver接口的实现类的publicclassDriverManager{ ​ /** * Load the initial JDBC drivers by checking the System property * jdbc.properties and then use the {。

@code ServiceLoader} mechanism */static { loadInitialDrivers(); println("JDBC DriverManager initialized"

); } ​ privatestaticvoidloadInitialDrivers(){ AccessController.doPrivileged(new PrivilegedAction() {

public Void run(){ ServiceLoader loadedDrivers = ServiceLoader.load(Driver.class

); Iterator driversIterator = loadedDrivers.iterator(); try{

while(driversIterator.hasNext()) { driversIterator.next(); } }

catch(Throwable t) { } returnnull; } }); }

在DriverManger类初始化的时候， 调用loadInitialDrivers方法具体过程还得看 loadInitialDrivers ，它在里面查找的是Driver接口的服务类，所以它的文件路径就是：。

META-INF/services/java.sql.Driver在loadInitialDrivers方法中，privatestaticvoidloadInitialDrivers(){ AccessController.doPrivileged(

new PrivilegedAction() { public Void run(){ //很明显，它要加载Driver接口的服务类，Driver接口的包为:java.sql.Driver

//所以它要找的就是META-INF/services/java.sql.Driver文件 ServiceLoader loadedDrivers = ServiceLoader.load(Driver

.class); Iterator driversIterator = loadedDrivers.iterator(); try{

//查到之后创建对象while(driversIterator.hasNext()) { driversIterator.next();//当调用next方法时，就会创建这个类的实例。

它就完成了一件事，向 DriverManager 注册自身的实例 } } catch(Throwable t) {

// Do nothing } returnnull; } }); } 这段代码是实现SPI的关键， 真是这个ServiceLoader类去实现SPI的。

那么下面就分析分析ServiceLoader的代码， 看看是如何实现SPI的package java.util; ​ publicfinalclassServiceLoader implements

Iterable { publicstatic ServiceLoader load(Class service) { ClassLoader cl = Thread.currentThread().getContextClassLoader();

return ServiceLoader.load(service, cl); } ​ //其中service就是要加载实现类对应的接口， loader就是用该加载器去加载对应的实现类public

static ServiceLoader load(Class service, ClassLoaderloader){ returnnew ServiceLoader<>(service, loader); } }

先调用ServiceLoader类的静态方法load， 然后根据当前线程的上下文类加载器，创建一个ServiceLoader实例privatestaticfinal String PREFIX = "META-INF/services/"

; ​ publicvoidreload(){ providers.clear(); lookupIterator = new LazyIterator(service, loader); }

privateServiceLoader(Class svc, ClassLoader cl){ service = Objects.requireNonNull(svc, "Service interface cannot be null"

); loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl; acc = (System.getSecurityManager() !=

null) ? AccessController.getContext() : null; reload(); } 创建ServiceLoader实例的时候，接着创建一个Iterator实现类。

接下来这个Iterator分析的重点基本所有的加载类的实现逻辑都在里面其中ServiceLoader类中一个常量的定义是关键的 前面说过，我们service的实现类在放在哪， 就是这里写死的常量路径//这里先介绍Iterator的变量，先大概有个印象。

privateclassLazyIteratorimplementsIterator { //service， loader前面介绍过了 Class service; ClassLoader loader; Enumeration configs = 。

null; Iterator pending = null; String nextName = null; ​ publicbooleanhasNext

(){ //省略权限相关代码return hasNextService(); } ​ privatebooleanhasNextService(){

//一开始nextName肯定为空if (nextName != null) { returntrue; } //一开始configs也肯定为空

if (configs == null) { try { //PREFIX = META-INF/services///以mysql为例，就是 META-INF/services/java.sql.Driver

String fullName = PREFIX + service.getName(); if (loader ==

null) configs = ClassLoader.getSystemResources(fullName); //loader去加载这个classpath下文件。

//这里很有可能返回的是多个文件的资源，//例如一个项目下既有mysql驱动， 也有sql server驱动等//所以返回的是一个枚举类型else configs = loader.getResources(fullName); } 。

catch (IOException x) { fail(service, "Error locating configuration files", x); } }

while ((pending == null) || !pending.hasNext()) { if (!configs.hasMoreElements()) {

returnfalse; } //然后根据加载出来的资源，解析一个文件中的内容放到Iterator实现类中 pending = parse(service, configs.nextElement()); } 。

//这里next返回的就是文件一行的内容，一般一行对应一个接口的实现类//一个接口放多行，就可以有多个接口实现类中 nextName = pending.next(); 。

returntrue; } } configs变量，就对应service文件 是个枚举， 就是说可以定义多个service文件pending 变量： 就对应configs中， service文件解析出来的一行有效内容，即一个实现类的全限定类名称。

parse方法就是简单，不是重点这里就略过了就是读取service文件中读取，一行就是一个nextName，然后遇到“#“就跳过“#”后面的内容所以service文件可以用“#”作为注释 直到遇到空行，解析结束。

LazyIterator类中的hasNext方法就分析完了 使用classLoader.getResources方法加载service文件我看了下getResources方法，并一定是加载classpath下的资源，得根据classLoader来解决。

不过绝大多数情况下，都是classpath的资源这里为了好理解，就理解成classpath下的资源接着分析LazyIterator#next方法public S next() { //删除权限相关代码。

return nextService(); } private S nextService() { if (!hasNextService())

thrownew NoSuchElementException(); //这个nextName前面分析过了 String cn = nextName; nextName =

null; Class c = null; try { //加载类，且不初始化 c = Class.forName(cn,

false, loader); } catch (ClassNotFoundException x) { fail(service,

"Provider " + cn + " not found"); } if (!service.isAssignableFrom(c)) { fail(service,

"Provider " + cn + " not a subtype"); } try { //类型判断 S p = service.cast(c.newInstance());

//最后放到ServiceLoader实例变量Map中，缓存起来，下次直接使用 providers.put(cn, p); return p; }

catch (Throwable x) { fail(service, "Provider " + cn + " could not be instantiated"

, x); } thrownew Error(); // This cannot happen

} next方法就比较简单了，根据前面解析出来的nextName（接口实现类的全限定名称），用Class.forName创建对应的Class对象4.1.2.2 创建Connection。

DriverManager.getConnection() 方法就是创建连接的地方，它通过循环已注册的数据库驱动程序，调用其connect方法，获取连接并返回privatestatic Connection 。

getConnection(String url, Properties info, Class caller)throws SQLException { //registeredDrivers中就包含com.mysql.cj.jdbc.Driver实例

for(DriverInfo aDriver : registeredDrivers) { if(isDriverAllowed(aDriver.driver, callerCL)) {

try { //调用connect方法创建连接 Connection con = aDriver.driver.connect(url, info);

if (con != null) { return (con); } }catch (SQLException ex) {

if (reason == null) { reason = ex; } } } else

{ println("skipping: " + aDriver.getClass().getName()); } } } 4.1.2.3 扩展既然我们知道JDBC是这样创建数据库连接的，我们能不能再扩展一下呢？如果我们自己也创建一个 java.sql.Driver 文件，自定义实现类MySQLDriver，那么，在获取连接的前后就可以动态修改一些信息。

还是先在项目resources下创建文件，文件内容为自定义驱动类 com.jcc.java.spi.domyself.MySQLDriver

我们的 MySQLDriver 实现类，继承自MySQL中的 NonRegisteringDriver ，还要实现 java.sql.Driver 接口这样，在调用connect方法的时候，就会调用到此类，但实际创建的过程还靠MySQL完成。

publicclassMySQLDriverextendsNonRegisteringDriverimplementsDriver{ static { try { DriverManager.registerDriver(

new MySQLDriver()); } catch (SQLException e) { e.printStackTrace(); } }

publicMySQLDriver()throws SQLException {} ​ @Overridepublic Connection connect(String url, Properties info)

throws SQLException { System.out.println("准备创建数据库连接.url:"+url); System.out.println("JDBC配置信息："

+info); //重置配置 info.setProperty("user", "root"); Connection connection = super

.connect(url, info); System.out.println("数据库连接创建完成!"+connection.toString()); return connection; } }

这样的话，当我们获取数据库连接的时候，就会调用到这里--------------------输出结果--------------------- 准备创建数据库连接.url:jdbc:mysql:///consult?serverTimezone=UTC。

JDBC配置信息：{user=root, password=root} 数据库连接创建完成!com.mysql.cj.jdbc.ConnectionImpl@7cf10a6f 4.1.3 SpringBoot中的应用

Spring Boot提供了一种快速的方式来创建可用于生产环境的基于Spring的应用程序它基于Spring框架，更倾向于约定而不是配置，并且旨在使您尽快启动并运行即便没有任何配置文件，SpringBoot的Web应用都能正常运行。

这种神奇的事情，SpringBoot正是依靠自动配置来完成说到这，我们必须关注一个东西： SpringFactoriesLoader，自动配置就是依靠它来加载的4.1.3.1 配置文件SpringFactoriesLoader 来负责加载配置。

我们打开这个类，看到它加载文件的路径是： META-INF/spring.factories

笔者在项目中搜索这个文件，发现有4个Jar包都包含它：List itemspring-boot-2.1.9.RELEASE.jarspring-beans-5.1.10.RELEASE.jarspring-boot-autoconfigure-2.1.9.RELEASE.jar

mybatis-spring-boot-autoconfigure-2.1.0.jar那么它们里面都是些啥内容呢？其实就是一个个接口和类的映射在这里笔者就不贴了，有兴趣的小伙伴自己去看看比如在SpringBoot启动的时候，要加载所有的 。

ApplicationContextInitializer ，那么就可以这样做：SpringFactoriesLoader.loadFactoryNames(ApplicationContextInitializer.class, classLoader)

4.1.3.2 加载文件loadSpringFactories 就负责读取所有的 spring.factories 文件内容private staticMap loadSpringFactories(@Nullable ClassLoader classLoader) { ​ MultiValueMap<

String, String> result = cache.get(classLoader); if (result != null) { return result; }

try { //获取所有spring.factories文件的路径 Enumeration urls = lassLoader.getResources("META-INF/spring.factories"

); result = new LinkedMultiValueMap<>(); while (urls.hasMoreElements()) { URL url = urls.nextElement();

//加载文件并解析文件内容 UrlResource resource = new UrlResource(url); Properties properties = PropertiesLoaderUtils.loadProperties(resource);

for (Map.Entry entry : properties.entrySet()) { String factoryClassName = ((String

) entry.getKey()).trim(); for (String factoryName : StringUtils.commaDelimitedListToStringArray((

String) entry.getValue())) { result.add(factoryClassName, factoryName.trim()); } } } cache.put(classLoader, result);

return result; } catch (IOException ex) { thrownew IllegalArgumentException("Unable to load factories from location ["

+ FACTORIES_RESOURCE_LOCATION + "]", ex); } } 可以看到，它并没有采用JDK中的SPI机制来加载这些类，不过原理差不多都是通过一个配置文件，加载并解析文件内容，然后通过反射创建实例。

4.1.3.3 参与其中假如你希望参与到 SpringBoot 初始化的过程中，现在我们又多了一种方式我们也创建一个 spring.factories 文件，自定义一个初始化器org.springframework.context.ApplicationContextInitializer=com.youyouxunyin.config.context.MyContextInitializer。

然后定义一个MyContextInitializer类publicclassMyContextInitializerimplementsApplicationContextInitializer{

@Overridepublicvoidinitialize(ConfigurableApplicationContext configurableApplicationContext){ System.out.println(configurableApplicationContext); } }

4.1.4 Dubbo中的应用我们熟悉的Dubbo也不例外，它也是通过 SPI 机制加载所有的组件同样的，Dubbo 并未使用 Java 原生的 SPI 机制，而是对其进行了增强，使其能够更好的满足需求。

在 Dubbo 中，SPI 是一个非常重要的模块基于 SPI，我们可以很容易的对 Dubbo 进行拓展它的使用方式同样是在 META-INF/services 创建文件并写入相关类名4.1.5 sentinel中的应用。

通过SPI机制将META-INFO/servcie下配置好的默认责任链构造这加载出来，然后调用其builder()方法进行构建调用链publicfinalclassSlotChainProvider{ ​

privatestaticvolatile SlotChainBuilder slotChainBuilder = null; ​ /** * The load and pick process is not thread-safe, but its okay since the method should be only invoked * via {

@code lookProcessChain} in {@link com.alibaba.csp.sentinel.CtSph} under lock. * * @return new created slot chain */

publicstatic ProcessorSlotChain newSlotChain(){ if (slotChainBuilder != null) { return

slotChainBuilder.build(); } ​ // Resolve the slot chain builder SPI. slotChainBuilder = SpiLoader.of(SlotChainBuilder

.class).loadFirstInstanceOrDefault(); ​ if (slotChainBuilder == null) { // Should not go through here.

RecordLog.warn("[SlotChainProvider] Wrong state when resolving slot chain builder, using default"

); slotChainBuilder = new DefaultSlotChainBuilder(); } else { RecordLog.info(

"[SlotChainProvider] Global slot chain builder resolved: {}", slotChainBuilder.getClass().getCanonicalName()); }

return slotChainBuilder.build(); } ​ privateSlotChainProvider(){} } SpiLoader.of()publicstatic

SpiLoader of(Class service){ AssertUtil.notNull(service, "SPI class cannot be null"

); AssertUtil.isTrue(service.isInterface() || Modifier.isAbstract(service.getModifiers()),

"SPI class[" + service.getName() + "] must be interface or abstract class"); ​ String className = service.getName(); SpiLoader spiLoader = SPI_LOADER_MAP.get(className);

if (spiLoader == null) { synchronized (SpiLoader.class) { spiLoader = SPI_LOADER_MAP.get(className);

if (spiLoader == null) { SPI_LOADER_MAP.putIfAbsent(className, new SpiLoader<>(service)); spiLoader = SPI_LOADER_MAP.get(className); } } } ​

return spiLoader; } @Spi(isDefault = true) publicclassDefaultSlotChainBuilderimplementsSlotChainBuilder

{ ​ @Overridepublic ProcessorSlotChain build(){ ProcessorSlotChain chain = new DefaultProcessorSlotChain(); ​ List sortedSlotList = SpiLoader.of(ProcessorSlot

.class).loadInstanceListSorted(); for (ProcessorSlot slot : sortedSlotList) { if (!(slot

instanceof AbstractLinkedProcessorSlot)) { RecordLog.warn("The ProcessorSlot(" + slot.getClass().getCanonicalName() +

") is not an instance of AbstractLinkedProcessorSlot, cant be added into ProcessorSlotChain");

continue; } ​ chain.addLast((AbstractLinkedProcessorSlot) slot); } ​

return chain; } } 责任链同样是由spi机制加载出来的，上面的加载只会在第一次使用的时候加载，然后缓存到内从后，以后直接取即可至此，SPI机制的实现原理就分析完了 虽然SPI我们日常开发中用的很少，但是至少了解了解还是有必要的。

例如： 一些框架实现中一般都会用到SPI机制

vert.x内部也是大量使用SPI4.2 APT注解处理器4.2.1 基础知识注解的保留时间分为三种：SOURCE——只在源代码中保留，编译器将代码编译成字节码文件后就会丢掉CLASS——保留到字节码文件中，但Java虚拟机将class文件加载到内存是不一定在内存中保留

RUNTIME——一直保留到运行时通常我们使用后两种，因为SOURCE主要起到标记方便理解的作用，无法对代码逻辑提供有效的信息时间解析性能影响RUNTIME运行时反射有CLASS编译期APT+JavaPoet。

无如上图，对比两种解析方式：运行时注解比较简单易懂，可以运用反射技术在程序运行时获取指定的注解信息，因为用到反射，所以性能会收到一定影响编译期注解可以使用APT(Annotation Processing Tool)技术，在编译期扫描和解析注解，并结合JavaPoet技术生成新的java文件，是一种更优雅的解析注解的方式，不会对程序性能产生太大影响。

下面以BindView为例，介绍两种方式的不同使用方法4.2.2 运行时注解运行时注解主要通过反射进行解析，代码运行过程中，通过反射我们可以知道哪些属性、方法使用了该注解，并且可以获取注解中的参数，做一些我们想做的事情。

首先，新建一个注解@Target({ElementType.FIELD}) @Retention(RetentionPolicy.RUNTIME) public @interface BindViewTo {

intvalue() default-1; //需要绑定的view id } 然后，新建一个注解解析工具类AnnotationTools，和一般的反射用法并无不同：publicclassAnnotationTools

{ ​ publicstaticvoidbindAllAnnotationView(Activity activity){ //获得成员变量 Field[] fields = activity.getClass().getDeclaredFields(); ​

for (Field field : fields) { try { if (field.getAnnotations() != null) {

//判断BindViewTo注解是否存在if (field.isAnnotationPresent(BindViewTo.class)) { //获取访问权限

field.setAccessible(true); BindViewTo getViewTo = field.getAnnotation(BindViewTo

.class); //获取View idint id = getViewTo.value(); //通过id获取View，并赋值该成员变量

field.set(activity, activity.findViewById(id)); } } }

catch (Exception e) { } } } } 在Activity中调用publicclassMainActivityextendsAppCompatActivity

{ ​ @BindViewTo(R.id.text) private TextView mText; ​ @OverrideprotectedvoidonCreate(Bundle savedInstanceState)

{ super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); ​

//调用注解绑定，当前Activity中所有使用@BindViewTo注解的控件将自动绑定 AnnotationTools.bindAllAnnotationView(this); ​

//测试绑定是否成功 mText.setTextColor(Color.RED); } ​ } 测试结果毫无意外，字体变成了红色，说明绑定成功4.2.3 编译期注解（APT+JavaPoet）。

编译期注解解析需要用到APT(Annotation Processing Tool)技术，APT是javac中提供的一种编译时扫描和处理注解的工具，它会对源代码文件进行检查，并找出其中的注解，然后根据用户自定义的注解处理方法进行额外的处理。

APT工具不仅能解析注解，还能结合JavaPoet技术根据注解生成新的的Java源文件，最终将生成的新文件与原来的Java文件共同编译APT实现流程如下：创建一个java lib作为注解解析库——如apt_processor

在创建一个java lib作为注解声明库——如apt_annotation搭建两个lib和主项目的依赖关系实现AbstractProcessor编译和调用整个流程是固定的，我们的主要工作是继承AbstractProcessor，并且实现其中四个方法。

下面一步一步详细介绍：4.2.3.１创建解析库apt_processorapply plugin: java-library ​ dependencies { implementation fileTree(dir:

libs, include: [*.jar]) compile com.squareup:javapoet:1.9.0// square开源的 Java 代码生成框架 compile com.google.auto.service:auto-service:1.0-rc2

//Google开源的用于注册自定义注解处理器的工具 implementation project(:apt_annotation) //依赖自定义注解声明库 } sourceCompatibility =

"7" targetCompatibility = "7"4.2.3.２ 创建注解库apt_annotation声明一个注解BindViewTo，注意@Retention不再是RUNTIME，而是CLASS。

@Target({ElementType.FIELD}) @Retention(RetentionPolicy.CLASS) public @interface BindViewTo { int

value() default-1; } 4.2.3.３ 搭建主项目依赖关系dependencies { implementationfileTree(dir: libs, include: [

*.jar]) implementationproject(:apt_annotation) //依赖自定义注解声明库annotationProcessorproject(:apt_processor

) //依赖自定义注解解析库（仅编译期） } 这里需要解释一下，因为注解解析库只在程序编译期有用，没必要打包进APK所以依赖解析库使用的关键字是annotationProcessor，这是google为gradle插件添加的特性，表示只在编译期依赖，不会打包进最终APK。

这也是为什么前面要把注解声明和注解解析拆分成两个库的原因因为注解声明是一定要编译到最终APK的，而注解解析不需要4.2.3.４ 实现AbstractProcessor这是最复杂的一步，也是完成我们期望工作的重点。

首先，我们在apt_processor中创建一个继承自AbstractProcessor的子类，重载其中四个方法：init()——此处初始化一个工具类getSupportedSourceVersion()——声明支持的Java版本，一般为最新版本

getSupportedAnnotationTypes()——声明支持的注解列表process()——编译器回调方法，apt核心实现方法具体代码如下： //@SupportedSourceVersion(SourceVersion.RELEASE_7)

//@SupportedAnnotationTypes("com.xibeixue.apt_annotation.BindViewTo")@AutoService(Processor.class) public

classBindViewProcessorextendsAbstractProcessor{ ​ private Elements mElementUtils; private HashMap mCreatorMap =

new HashMap<>(); ​ /** * init方法一般用于初始化一些用到的工具类，主要有 * processingEnvironment.getElementUtils(); 处理Element的工具类，用于获取程序的元素，例如包、类、方法。

* processingEnvironment.getTypeUtils(); 处理TypeMirror的工具类，用于取类信息 * processingEnvironment.getFiler(); 文件工具 * processingEnvironment.getMessager(); 错误处理工具 */。

@Overridepublicsynchronizedvoidinit(ProcessingEnvironment processingEnvironment){ super.init(processingEnvironment); mElementUtils = processingEnv.getElementUtils(); } ​

/** * 获取Java版本，一般用最新版本 * 也可以使用注解方式：@SupportedSourceVersion(SourceVersion.RELEASE_7) */

@Overridepublic SourceVersion getSupportedSourceVersion(){ return SourceVersion.latestSupported(); } ​

/** * 获取目标注解列表 * 也可以使用注解方式：@SupportedAnnotationTypes("com.xibeixue.apt_annotation.BindViewTo") */

@Overridepublic Set getSupportedAnnotationTypes(){ HashSet supportTypes = new

LinkedHashSet<>(); supportTypes.add(BindViewTo.class.getCanonicalName()); return supportTypes; } ​

/** * 编译期回调方法,apt核心实现方法 * 包含所有使用目标注解的元素(Element) */@Overridepublicbooleanprocess(Set set, RoundEnvironment roundEnvironment)

{ //扫描整个工程, 找出所有使用BindViewTo注解的元素 Set elements = roundEnvironment.getElementsAnnotatedWith(BindViewTo

.class); //遍历元素, 为每一个类元素创建一个Creatorfor (Element element : elements) { //BindViewTo限定了只能属性使用, 这里强转为变量元素VariableElement

VariableElement variableElement = (VariableElement) element; //获取封装属性元素的类元素TypeElement

TypeElement classElement = (TypeElement) variableElement.getEnclosingElement();

//获取简单类名 String fullClassName = classElement.getQualifiedName().toString(); BinderClassCreator creator = mCreatorMap.get(fullClassName);

//如果不存在, 则创建一个对应的Creatorif (creator == null) { creator = new BinderClassCreator(mElementUtils.getPackageOf(classElement), classElement); mCreatorMap.put(fullClassName, creator); ​ }

//将需要绑定的变量和对应的view id存储到对应的Creator中 BindViewTo bindAnnotation = variableElement.getAnnotation(BindViewTo

.class); int id = bindAnnotation.value(); creator.putElement(id, variableElement); } ​

//每一个类将生成一个新的java文件，其中包含绑定代码for (String key : mCreatorMap.keySet()) { BinderClassCreator binderClassCreator = mCreatorMap.get(key);

//通过javapoet构建生成Java类文件 JavaFile javaFile = JavaFile.builder(binderClassCreator.getPackageName(), binderClassCreator.generateJavaCode()).build();

try { javaFile.writeTo(processingEnv.getFiler()); } catch (IOException e) { e.printStackTrace(); } ​ }

returnfalse; } } 其中，BinderClassCreator是代码生成相关方法，具体代码如下：publicclassBinderClassCreator{ ​ public

staticfinal String ParamName = "rootView"; ​ private TypeElement mTypeElement; private String mPackageName;

private String mBinderClassName; private Map mVariableElements = new HashMap<>(); ​

/** * @param packageElement 包元素 * @param classElement 类元素 */publicBinderClassCreator

(PackageElement packageElement, TypeElement classElement){ this.mTypeElement = classElement; mPackageName = packageElement.getQualifiedName().toString(); mBinderClassName = classElement.getSimpleName().toString() +

"_ViewBinding"; } ​ publicvoidputElement(int id, VariableElement variableElement){ mVariableElements.put(id, variableElement); } ​

public TypeSpec generateJavaCode(){ return TypeSpec.classBuilder(mBinderClassName)

//public 修饰类 .addModifiers(Modifier.PUBLIC) //添加类的方法 .addMethod(generateMethod())

//构建Java类 .build(); ​ } ​ private MethodSpec generateMethod(){ //获取全类名

ClassName className = ClassName.bestGuess(mTypeElement.getQualifiedName().toString());

//构建方法--方法名return MethodSpec.methodBuilder("bindView") //public方法 .addModifiers(Modifier.PUBLIC)

//返回void .returns(void.class) //方法传参（参数全类名，参数名） .addParameter

(className, ParamName) //方法代码 .addCode(generateMethodCode()) .

build(); } ​ private String generateMethodCode(){ StringBuilder code = new StringBuilder();

for (int id : mVariableElements.keySet()) { VariableElement variableElement = mVariableElements.get(id);

//变量名称 String name = variableElement.getSimpleName().toString(); //变量类型 String type = variableElement.asType().toString();

//rootView.name = (type)view.findViewById(id), 注意原类中变量声明不能为private，否则这里是获取不到的 String findViewCode = ParamName +

"." + name + "=(" + type + ")" + ParamName + ".findViewById(" + id + ");\n"; code.append(findViewCode); ​ }

return code.toString(); } ​ public String getPackageName(){ return mPackageName; } }

4.2.3.５ 编译和调用在MainActivity中调用，这里需要强调的是待绑定变量不能声明为private，原因在上面代码注释中已经解释了publicclassMainActivityextends。

AppCompatActivity{ ​ @BindViewTo(R.id.text) public TextView mText; ​ @Overrideprotectedvoid

onCreate(Bundle savedInstanceState){ super.onCreate(savedInstanceState); setContentView(R.layout.activity_main);

//这里的MainActivity需要先编译生成后才能调用new MainActivity_ViewBinding().bindView(this); //测试绑定是否成功 mText.setTextColor(Color.RED); } }

此时，build或rebuild工程（需要先注掉MainActivity的调用），会看到在generatedJava文件夹下生成了新的Java文件。

上面的调用方式需要先编译一次才能使用，当有多个Activity时比较繁琐，而且无法做到统一我们也可以选择另一种更简便的方法，即反射调用新建工具类如下：publicclassMyButterKnife {

​ publicstaticvoidbind(Activity activity){ Class clazz = activity.getClass();

try { Class bindViewClass = Class.forName(clazz.getName() + "_ViewBinding"); Method method = bindViewClass.getMethod(

"bindView", activity.getClass()); method.invoke(bindViewClass.newInstance(), activity); }

catch (Exception e) { e.printStackTrace(); } } ​ } 调用方式改为：@Override

protectedvoidonCreate(Bundle savedInstanceState){ super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); ​

//通过反射调用 MyButterKnife.bind(this); ​ //测试绑定是否成功 mText.setTextColor(Color.RED); }

此方式虽然也会稍微影响性能，但依然比直接使用运行时注解高效得多4.2.4 APT注解处理器总结说到底，APT是一个编译器工具，是一个非常好的从源码到编译期的过渡解析工具虽然结合JavaPoet技术被各大框架使用，但是依然存在固有的缺陷，比如变量不能私有，依然要采用反射调用等，普通开发者可斟酌使用。

个人认为APT有如下优点：配置方式，替换文件配置方式，改为代码内配置，提高程序内聚性代码精简，一劳永逸，省去繁琐复杂的格式化代码，适合团队内推广以上优点同时也是缺点，因为很多代码都在后台生成，会对新同学造成理解困难，影响其对整体架构的理解，增加学习成本。

近期研究热修复和APT，发现从我们写完成代码，到代码真正执行，期间还真是有大把的“空子”可以钻啊，借图mark一下。

4.3 javac源码分析4.3.1 javac概述我们都知道 *.java 文件要首先被编译成 *.class 文件才能被 JVM 认识，这部分的工作主要由 Javac 来完成，类似于 Javac 这样的我们称之为前端编译器；

但是 *.class 文件也不是机器语言，怎么才能让机器识别呢？就需要 JVM 将 *.class 文件编译成机器码，这部分工作由JIT 编译器完成；除了这两种编译器，还有一种直接把 *.java 文件编译成本地机器码的编译器，我们称之AOT 编译器。

4.3.2 javac 的编译过程首先，我们先导一份 javac 的源码（基于 openjdk8）出来，下载地址：https://hg.openjdk.java.net/jdk8/jdk8/langtools/archive/tip.tar.gz，然后将

JDK_SRC_HOME/langtools/src/share/classes/com/sun 目录下的源文件全部复制到工程的源码目录中，生成的 目录如下：

我们执行 com.sun.tools.javac.Main 的 main 方法，就和我们在命令窗口中使用 javac 命令一样：

从 Sun Javac 的代码来看，编译过程大致可以分为三个步骤：解析和填充符号表过程插入式注解处理器的注解处理过程分析和字节码生成过程这三个步骤所做的工作内容大致如下：

这三个步骤之间的关系和交互顺序如下图所示，可以看到如果注解处理器在处理注解期间对语法树进行了修改，编译器将回到解析和填充符号表的过程进行重新处理，直到注解处理器没有再对语法树进行修改为止。

Javac 编译的入口是 com.sun.tools.javac.main.JavaCompiler 类，上述三个步骤的代码都集中在这个类的 compile() 和 compile2() 中：

4.3.3 javac编译器编译程序的步骤词法分析 首先是读取源代码，找出这些字节中哪些是我们定义的语法关键词，如Java中的if、else、for等关键词 语法分析的结果:从源代码中找出一些规范化的token流 注:token是一种认证机制 ​ 语法分析 检查关键词组合在一起是不是Java语言规范，如

if后面是不是紧跟着一个布尔表达式 语法分析的结果：形成一个符合Java语言规范的抽象语法树 ​ 语义分析 把一些难懂的、复杂的语法转化为更加简单的语法 语义分析的结果：完成复杂语法到简单语法的简化,如将。

foreach语句转化成for循环结果，还有注解等最后形成一个注解过后的抽象语法树，这颗语法树更接近目标语言的语法规则 ​ 生成字节码 通过字节码生成器生成字节码，根据经过注解的抽象语法树生成字节码，也就是将一个数据结构转化成另一个数据结构 代码生成器的结果：生成符合Java虚拟机规范的字节码 ​ 注：抽象语法树 在计算机科学中，抽象语法树是源代码语法结构的一种抽象表示。

它以树状的形式表现编程语言的语法结构，树上的每个节点都表示源代码中的一种结构